libtool and mkoctfile

[John W. Eaton-3]

I would like to make the mkoctfile script use libtool to create .oct
files, the same as we will soon be using in the Makefiles that build
the .oct files that are part of Octave.  I think I have most of the
details worked out, but one problem remains.  Libtool is a Unix shell
script, so we will need to do something for Windows systems.  Is it
reasonable for Octave to require a Unix command shell and the
associated commands that libtool requires for building .oct files?

If not, then I suppose that when Octave is built, we could try to
extract from libtool the commands that it would run, and embed those
in the mkoctfile script/program, though I'm not sure how to do that in
a reliable way.  If we do go this route, then I would like to consider
again eliminating the mkoctfile script and keeping only the C++
program.  Having both seems like asking for trouble as the two are
likely to get out of sync.

It seems easier to me to just package a Unix shelland the necessary
commands for Windows systems, then eliminate the C++ version of
mkoctfile.

If you object to including a Unix shell, why?  Suppose that libtool
were written in Perl.  Would you also object to including perl in the
distribution so that Octave could run the libtool script?  Octave
already includes a perl function.  Do we distribute a copy of Perl
with Octave on Windows systems so that the perl function can work?

Comments?

jwe

[Thomas Weber-8]

On Mon, Nov 02, 2009 at 04:29:08PM -0500, John W. Eaton wrote:
> I would like to make the mkoctfile script use libtool to create .oct
> files, the same as we will soon be using in the Makefiles that build
> the .oct files that are part of Octave.  I think I have most of the
> details worked out, but one problem remains.  Libtool is a Unix shell
> script, so we will need to do something for Windows systems.  Is it
> reasonable for Octave to require a Unix command shell and the
> associated commands that libtool requires for building .oct files?

http://gnuwin32.sourceforge.net/packages/libtool.htm

Or is this the wrong program?

        Thomas

[John W. Eaton-3]

On  3-Nov-2009, Thomas Weber wrote:

| On Mon, Nov 02, 2009 at 04:29:08PM -0500, John W. Eaton wrote:
| > I would like to make the mkoctfile script use libtool to create .oct
| > files, the same as we will soon be using in the Makefiles that build
| > the .oct files that are part of Octave.  I think I have most of the
| > details worked out, but one problem remains.  Libtool is a Unix shell
| > script, so we will need to do something for Windows systems.  Is it
| > reasonable for Octave to require a Unix command shell and the
| > associated commands that libtool requires for building .oct files?
|
| http://gnuwin32.sourceforge.net/packages/libtool.htm
|
| Or is this the wrong program?

That version is too old.  But it still appears to be a Unix shell
script, which requires a Unix shell interpreter to work.

jwe

[Benjamin Lindner]

> I would like to make the mkoctfile script use libtool to create .oct
> files, the same as we will soon be using in the Makefiles that build
> the .oct files that are part of Octave.  I think I have most of the
> details worked out, but one problem remains.  Libtool is a Unix shell
> script, so we will need to do something for Windows systems.  Is it
> reasonable for Octave to require a Unix command shell and the
> associated commands that libtool requires for building .oct files?

Frankly, no. I'd like to return the question by asking is it *really* necessary to rely on a unix-sh-interpreter?
I see mkoctfile as an integral part of Octave an if mkoctfile requires a unix-layer to run, then, well, you won't have a native windows binary any more.
And I wouldn't see the point in providing mingw binaries with the additional necessity of a unix shell, when there's cygwin available which does exactly all this, and I guess much better.
And what about msvc? There are no 'official' binaries, but octave can still be built with ms compilers I guess and run as native binary.

What about the future development, what about e.g. x64 binaries?
I'm not sure about unix-shells-for-win64-which-are-not-cygwin. Possibly cygwin is the better choice as unix layer - and then I'll end up again at the question, why provide mingw32/64 along with a unix shell interpreter when there is cygwin?

Aside from the question of unix-sh-interpreter yes or no, I disagree to using libtool, at least for windows platform. Simply because libtool does not work properly for windows.
There are problems creating shared libs, there are problems with compiler flags, there are problems with libtool dropping libraries from the command line at own gusto, there are problems with shared libstdc++.
So I would most probably end up packaging a patched (i.e. hacked) version of libtool which I honestly could not support because i simply don't understand it myself.
Using libtool for building octave is using it in a controlled, and kind of encapsuled environment where one knows the odds and ends and where you have a bunch of workaround tricks in your pocket.
But distributing it and depending on it in open space, I believe will end up with many reports of "mkoctfile does not work for me" and us saying, "yes, we know, this is libtool".

> If not, then I suppose that when Octave is built, we could try to
> extract from libtool the commands that it would run, and embed those
> in the mkoctfile script/program, though I'm not sure how to do that in
> a reliable way.  If we do go this route, then I would like to consider
> again eliminating the mkoctfile script and keeping only the C++
> program.  Having both seems like asking for trouble as the two are
> likely to get out of sync.
>
> It seems easier to me to just package a Unix shelland the necessary
> commands for Windows systems, then eliminate the C++ version of
> mkoctfile.

I'd like to stick to the C++ version of mkoctfile and I would have no problem with having a (windows) C++ version alongside the (common) shell version. You are right about having two versions and them possibly diverging, but how much development in the future do you honstly see in mkoctfile? How much new features do you plan to add to mkoctfile? I think that the additional effort of keeping the C++ version in pace with the shell version small compared to forcing a shell/libtool version for windows and maintaining it.
I'd rather be one step behind with the C++ version than requiring a unix shell for it.

To me, the C++ interface is octave's biggest bonus aside of it being free software. And to be able to use the C++ interface natively with a free compiler available on windows, I wouldn't want to miss that.

> If you object to including a Unix shell, why?  

I'd object to having a unix shell as runtime requirement for octave. It'd end up in a windows binary depending on a unix layer, and that's cygwin.

> Suppose that libtool
> were written in Perl.  Would you also object to including perl in the
> distribution so that Octave could run the libtool script?  

Possibly. I have no experience with perl distributions for windows, so I cannot estimate the amount of effort it would require to include it.
I'd probably stick to a C++ version of mkoctfile anyway.

This is also getting a bit philosophical.

At the current stage, windows binaries of octave do not require any privileges for installing a default user (who is not administrator) on windows doesn't have.
It even doesn't require being "installed" at all, you can just copy it and run it off a usb stick, if you like. It doesn't need to fiddle with windows registry and it can be cleanly uninstalled or removed by simply deleting the directory tree it was installed to.

Now beginning to add dependencies that don't follow this philosophy, may mean that octave is no longer portable, and octave must strictly be installed with administrative privileges. And this is IMO the wrong way to go.

> Octave
> already includes a perl function.  Do we distribute a copy of Perl
> with Octave on Windows systems so that the perl function can work?

No, perl's not included. Now I'm curious. Which octave function is that?

benjamin
--
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

[Jaroslav Hajek-2]

On Wed, Nov 4, 2009 at 9:50 AM, Benjamin Lindner <lindnerben@...> wrote:

>
>> I would like to make the mkoctfile script use libtool to create .oct
>> files, the same as we will soon be using in the Makefiles that build
>> the .oct files that are part of Octave.  I think I have most of the
>> details worked out, but one problem remains.  Libtool is a Unix shell
>> script, so we will need to do something for Windows systems.  Is it
>> reasonable for Octave to require a Unix command shell and the
>> associated commands that libtool requires for building .oct files?
>
> Frankly, no. I'd like to return the question by asking is it *really* necessary to rely on a unix-sh-interpreter?
> I see mkoctfile as an integral part of Octave an if mkoctfile requires a unix-layer to run, then, well, you won't have a native windows binary any more.
> And I wouldn't see the point in providing mingw binaries with the additional necessity of a unix shell, when there's cygwin available which does exactly all this, and I guess much better.
> And what about msvc? There are no 'official' binaries, but octave can still be built with ms compilers I guess and run as native binary.
>
> What about the future development, what about e.g. x64 binaries?
> I'm not sure about unix-shells-for-win64-which-are-not-cygwin. Possibly cygwin is the better choice as unix layer - and then I'll end up again at the question, why provide mingw32/64 along with a unix shell interpreter when there is cygwin?
>
> Aside from the question of unix-sh-interpreter yes or no, I disagree to using libtool, at least for windows platform. Simply because libtool does not work properly for windows.
> There are problems creating shared libs, there are problems with compiler flags, there are problems with libtool dropping libraries from the command line at own gusto, there are problems with shared libstdc++.
> So I would most probably end up packaging a patched (i.e. hacked) version of libtool which I honestly could not support because i simply don't understand it myself.
> Using libtool for building octave is using it in a controlled, and kind of encapsuled environment where one knows the odds and ends and where you have a bunch of workaround tricks in your pocket.
> But distributing it and depending on it in open space, I believe will end up with many reports of "mkoctfile does not work for me" and us saying, "yes, we know, this is libtool".
>
>> If not, then I suppose that when Octave is built, we could try to
>> extract from libtool the commands that it would run, and embed those
>> in the mkoctfile script/program, though I'm not sure how to do that in
>> a reliable way.  If we do go this route, then I would like to consider
>> again eliminating the mkoctfile script and keeping only the C++
>> program.  Having both seems like asking for trouble as the two are
>> likely to get out of sync.
>>
>> It seems easier to me to just package a Unix shelland the necessary
>> commands for Windows systems, then eliminate the C++ version of
>> mkoctfile.
>
> I'd like to stick to the C++ version of mkoctfile and I would have no problem with having a (windows) C++ version alongside the (common) shell version. You are right about having two versions and them possibly diverging, but how much development in the future do you honstly see in mkoctfile? How much new features do you plan to add to mkoctfile? I think that the additional effort of keeping the C++ version in pace with the shell version small compared to forcing a shell/libtool version for windows and maintaining it.
> I'd rather be one step behind with the C++ version than requiring a unix shell for it.
>
> To me, the C++ interface is octave's biggest bonus aside of it being free software. And to be able to use the C++ interface natively with a free compiler available on windows, I wouldn't want to miss that.
>
>> If you object to including a Unix shell, why?
>
> I'd object to having a unix shell as runtime requirement for octave. It'd end up in a windows binary depending on a unix layer, and that's cygwin.
>
>> Suppose that libtool
>> were written in Perl.  Would you also object to including perl in the
>> distribution so that Octave could run the libtool script?
>
> Possibly. I have no experience with perl distributions for windows, so I cannot estimate the amount of effort it would require to include it.
> I'd probably stick to a C++ version of mkoctfile anyway.
>
> This is also getting a bit philosophical.
>
> At the current stage, windows binaries of octave do not require any privileges for installing a default user (who is not administrator) on windows doesn't have.
> It even doesn't require being "installed" at all, you can just copy it and run it off a usb stick, if you like. It doesn't need to fiddle with windows registry and it can be cleanly uninstalled or removed by simply deleting the directory tree it was installed to.
>
> Now beginning to add dependencies that don't follow this philosophy, may mean that octave is no longer portable, and octave must strictly be installed with administrative privileges. And this is IMO the wrong way to go.
>
>> Octave
>> already includes a perl function.  Do we distribute a copy of Perl
>> with Octave on Windows systems so that the perl function can work?
>
> No, perl's not included. Now I'm curious. Which octave function is that?
>
> benjamin
> --

The only perl script is octave/mk-opts.pl, and it is only used to
recreate the option handlers DASPK-opts and similar. I think that like
awk, bison, flex and gperf, perl is only needed to build from plain
repo, but not from the distribution tarball.

If libtool was only required for generating distrib tarballs, it would
make little difference, but making it a requirement for mkoctfile
would mean a significant change. Not just for Windows; unless I'm
missing something, it would mean that dependency on libtool would be
required for Octave packages in GNU/Linux distros as well.

Regarding the question alone (whether to do this or not) I'm yet
undecided. I need yet to read carefully John's rationale for the move
to gnulib.

--
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz

[John W. Eaton-3]

On  4-Nov-2009, Jaroslav Hajek wrote:

| The only perl script is octave/mk-opts.pl, and it is only used to
| recreate the option handlers DASPK-opts and similar. I think that like
| awk, bison, flex and gperf, perl is only needed to build from plain
| repo, but not from the distribution tarball.

There is also the perl function in the interpreter:

  `perl' is a function from the file /usr/share/octave/3.2.3/m/miscellaneous/perl.m

   -- Function File: [OUTPUT, STATUS] = perl (SCRIPTFILE)
   -- Function File: [OUTPUT, STATUS] = perl (SCRIPTFILE, ARGUMENT1,
            ARGUMENT2, ...)
       Invoke perl script SCRIPTFILE with possibly a list of command line
       arguments.  Returns output in OUTPUT and status in STATUS.

       See also: system

Other functions like tar/untar, zip/unzip, gzip/gunzip, etc. also
depend on external programs.  Are these all "native Windows" programs?
If you say yes, then what makes something a "native Windows" program?
A POSIX shell interpreter is just another program that interprets a
particular command language.  Isn't the Msys shell a "native Windows"
program?  Is a program written to depend on it not?  I guess I don't
understand where you draw the ine.

In any case, we would not be exposing libtool or the shell to the
Octave user.  So I don't see the problem as anything other than having
to distribute and install some additional programs with binary Octave
distributions.  People installing from source already have all of these
tools.  And you already need extra programs to be able to compile .oct
or .mex files.

| If libtool was only required for generating distrib tarballs, it would
| make little difference, but making it a requirement for mkoctfile
| would mean a significant change. Not just for Windows; unless I'm
| missing something, it would mean that dependency on libtool would be
| required for Octave packages in GNU/Linux distros as well.

Yes, but libtool is just shell script.

| Regarding the question alone (whether to do this or not) I'm yet
| undecided. I need yet to read carefully John's rationale for the move
| to gnulib.

We currently use an odd mixture of old and homegrown code to replace
missing functionality (things like fnmatch, glob, readdir, strftime,
etc.).  Mostly, we've picked up these functions from other packages at
random points in time and rarely update them.  The functions in gnulib
are at least maintained and updated, and mostly better than versions
that we might write ourselves.  By using gnulib, the portability and
replacement functions in Octave will be kept up to date automatically
with little effort on our part.  If there are bugs in these functions,
then we will fix them in gnulib, and then all the users of gnulib will
benefit, not just the users of Octave.

Using gnulib without automake and libtool is just too much effort, so
we really need to switch Octave's build system to use these tools.
There are other benefits to using automake and libtool.  First, we get
correct dependency generation, and it is done simultaneously when
compiling.  Obsolete dependencies are also handled properly, so that
will fix a longstanding bug in Octave's Makefiles.  We get dist and
clean targets in the Makefiles mostly for free.  Dependency tracking
for the configure script and Makefiles is handled correctly.  With a
little more effort, we could also have a build system that doesn't
depend on GNU Make, but I don't see that as a high priority.

Using libtool also has similar advantages to using gnulib.  Rather
than having to reinvent how to deal with shared libraries, we can take
advantage of the knowledge built in to libtool.

If mkoctfile does not use libtool, then we will still have to maintain
the code in Octave's configure script that deals with building shared
libraries.   I'd rather delete all that and avoid duplicating what is
already done by libtool.

jwe

[John W. Eaton-3]

On  4-Nov-2009, Benjamin Lindner wrote:

| Aside from the question of unix-sh-interpreter yes or no, I disagree
| to using libtool, at least for windows platform. Simply because
| libtool does not work properly for windows.

If there are problems with libtool, then I think we should report them
and try to get the problems fixed.  That way everyone using libtool
benefits.

| At the current stage, windows binaries of octave do not require any
| privileges for installing a default user (who is not administrator)
| on windows doesn't have.

Does installing the Msys shell and associated utilities (cp, mv, rm,
etc.) require administrator privileges?

| No, perl's not included. Now I'm curious. Which octave function is that?

The perl function.

jwe

[Søren Hauberg]

man, 02 11 2009 kl. 16:29 -0500, skrev John W. Eaton:
> I would like to make the mkoctfile script use libtool to create .oct
> files, the same as we will soon be using in the Makefiles that build
> the .oct files that are part of Octave.  I think I have most of the
> details worked out, but one problem remains.  Libtool is a Unix shell
> script, so we will need to do something for Windows systems.  Is it
> reasonable for Octave to require a Unix command shell and the
> associated commands that libtool requires for building .oct files?

I'm just following this from the side-line, so this is probably a stupid
question...  What is 'libtool' supposed to do here? Is it just supposed
generate a set of compiler and linker flags that ensures that the .oct
file can be generated? If so, are these flags the same every time
'mkoctfile' is called? If so, can't we just generate these flags when
Octave is compiled instead of generating them at run-time?

Søren

[Jaroslav Hajek-2]

On Wed, Nov 4, 2009 at 4:39 PM, John W. Eaton <jwe@...> wrote:

> On  4-Nov-2009, Jaroslav Hajek wrote:
>
> | The only perl script is octave/mk-opts.pl, and it is only used to
> | recreate the option handlers DASPK-opts and similar. I think that like
> | awk, bison, flex and gperf, perl is only needed to build from plain
> | repo, but not from the distribution tarball.
>
> There is also the perl function in the interpreter:
>
>  `perl' is a function from the file /usr/share/octave/3.2.3/m/miscellaneous/perl.m
>
>   -- Function File: [OUTPUT, STATUS] = perl (SCRIPTFILE)
>   -- Function File: [OUTPUT, STATUS] = perl (SCRIPTFILE, ARGUMENT1,
>            ARGUMENT2, ...)
>       Invoke perl script SCRIPTFILE with possibly a list of command line
>       arguments.  Returns output in OUTPUT and status in STATUS.
>
>       See also: system
>
> Other functions like tar/untar, zip/unzip, gzip/gunzip, etc. also
> depend on external programs.  Are these all "native Windows" programs?
> If you say yes, then what makes something a "native Windows" program?
> A POSIX shell interpreter is just another program that interprets a
> particular command language.  Isn't the Msys shell a "native Windows"
> program?  Is a program written to depend on it not?  I guess I don't
> understand where you draw the ine.
>

Still, I daresay mkoctfile is usually much more important for most
people. People won't expect "zip" to work unless zip is installed.

>
> In any case, we would not be exposing libtool or the shell to the
> Octave user.  So I don't see the problem as anything other than having
> to distribute and install some additional programs with binary Octave
> distributions.  People installing from source already have all of these
> tools.  And you already need extra programs to be able to compile .oct
> or .mex files.
>
> | If libtool was only required for generating distrib tarballs, it would
> | make little difference, but making it a requirement for mkoctfile
> | would mean a significant change. Not just for Windows; unless I'm
> | missing something, it would mean that dependency on libtool would be
> | required for Octave packages in GNU/Linux distros as well.
>
> Yes, but libtool is just shell script.
>
> | Regarding the question alone (whether to do this or not) I'm yet
> | undecided. I need yet to read carefully John's rationale for the move
> | to gnulib.
>
> We currently use an odd mixture of old and homegrown code to replace
> missing functionality (things like fnmatch, glob, readdir, strftime,
> etc.).  Mostly, we've picked up these functions from other packages at
> random points in time and rarely update them.  The functions in gnulib
> are at least maintained and updated, and mostly better than versions
> that we might write ourselves.  By using gnulib, the portability and
> replacement functions in Octave will be kept up to date automatically
> with little effort on our part.  If there are bugs in these functions,
> then we will fix them in gnulib, and then all the users of gnulib will
> benefit, not just the users of Octave.
>
> Using gnulib without automake and libtool is just too much effort, so
> we really need to switch Octave's build system to use these tools.
> There are other benefits to using automake and libtool.  First, we get
> correct dependency generation, and it is done simultaneously when
> compiling.  Obsolete dependencies are also handled properly, so that
> will fix a longstanding bug in Octave's Makefiles.  We get dist and
> clean targets in the Makefiles mostly for free.  Dependency tracking
> for the configure script and Makefiles is handled correctly.  With a
> little more effort, we could also have a build system that doesn't
> depend on GNU Make, but I don't see that as a high priority.
>
> Using libtool also has similar advantages to using gnulib.  Rather
> than having to reinvent how to deal with shared libraries, we can take
> advantage of the knowledge built in to libtool.
>
> If mkoctfile does not use libtool, then we will still have to maintain
> the code in Octave's configure script that deals with building shared
> libraries.   I'd rather delete all that and avoid duplicating what is
> already done by libtool.
>

If thanks to these changes Octave's code will become cleaner and more
portable, then I suppose that justifies them well. I never knew of
gnulib before, so I can't justify that. I hope it's no problem use
libtool and gnulib with other compilers.

One problem I see with gnulib is that it is C-centric rather than C++-centric.
Have you also considered Boost? FSF recognizes the Boost software
license as free and GPL compatible.
Boost likewise provides portable I/O and memory facilities, special
functions etc...
Boost is extensively developed and maintained, and very portable. Some
portions of Boost made it into the C++ standard, and some are planned
in the future. Maybe Boost would be a better option for Octave?

--
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz

[John W. Eaton-3]

On  4-Nov-2009, Søren Hauberg wrote:

| I'm just following this from the side-line, so this is probably a stupid
| question...  What is 'libtool' supposed to do here? Is it just supposed
| generate a set of compiler and linker flags that ensures that the .oct
| file can be generated? If so, are these flags the same every time
| 'mkoctfile' is called? If so, can't we just generate these flags when
| Octave is compiled instead of generating them at run-time?

I don't know the reasoning behind the design choices that resulted in
rules like

  LTCOMPILE = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
          --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
          $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)

  .c.lo:
          depbase=`echo $@ | sed 's|[^/]*$$|$(DEPDIR)/&|;s|\.lo$$||'`;\
          $(LTCOMPILE) -MT $@ -MD -MP -MF $$depbase.Tpo -c -o $@ $< &&\
          $(am__mv) $$depbase.Tpo $$depbase.Plo

etc., and embedding the logic for precisely how to compile a source
file or assemble a library inside the libtool script instead of
exposing that logic directly in the Makefile (via apropriate
automake/autoconf macros, for example).  I don't see that this
question is directly answered in the libtool documentation.  Maybe
this question should be directed tothe autoconf/automake/libtool
developers?

However, consider the alternative of eliminating the libtool script in
favor of having the logic of the libtool script exposed in the
Makefile itself.  Then to use that logic in the mkoctfile script, we
would have to duplicate it.  But the Makefile rules would not be
exactly what we need.  This is the situation we have now with Octave's
current build system.  So it makes some sense to avoid the duplication
and just put the logic in a single script that can be called from a
Makefile or some other script.

jwe

[John W. Eaton-3]

On  4-Nov-2009, Jaroslav Hajek wrote:

| If thanks to these changes Octave's code will become cleaner and more
| portable, then I suppose that justifies them well. I never knew of
| gnulib before, so I can't justify that. I hope it's no problem use
| libtool and gnulib with other compilers.

As far as I know, libtool and gnulib are not aimed only at GCC.

| One problem I see with gnulib is that it is C-centric rather than
| C++-centric.

What I'm looking for is something that will handle replacing the core
POSIX functions on systems that don't have them, or that have broken
versions.  Most often these days, that is Windows, isn't it?  And
these are relatively low-level functions defined with C language
interfaces.  So I don't see this as a problem.

| Have you also considered Boost? FSF recognizes the Boost software
| license as free and GPL compatible.
| Boost likewise provides portable I/O and memory facilities, special
| functions etc...
| Boost is extensively developed and maintained, and very portable. Some
| portions of Boost made it into the C++ standard, and some are planned
| in the future. Maybe Boost would be a better option for Octave?

I suppose Boost would be OK for higher level things.  But it doesn't
aim to provide replacements for readdir or strftime on systems that
lack them, does it?

jwe

[Tatsuro MATSUOKA-2]

Hello

--- "John W. Eaton"wrote:

> Does installing the Msys shell and associated utilities (cp, mv, rm,
> etc.) require administrator privileges?

Installing Msys with Msys1.0.11.exe requires administrator privileges.
However this is perhaps for clean uninstalling by windows control panel.

Msys+MinGW (with GCC) can work in a USB stick, if the drive name of USB drive is properly set in the
..../etc/fstab setting.

I sometimes use Msys+MinGW in usb for use unixy commands and GCC in other computer.  It requires to
modify drive name in ..../etc/fstab

e:/MinGW/ /mingw
,
f:/MinGW /mingw
or
g:/MinGW /mingw
:
:

I always set the above manually. It is possible to get current drive with small program and modify it
by sed of non-msys version.
However I did not try it.

Regards

Tatsuro

Regards

Tatsuro

--------------------------------------
GyaO! - Anime, Dramas, Movies, and Music videos [FREE]
http://pr.mail.yahoo.co.jp/gyao/

[Benjamin Lindner]

John W. Eaton wrote:

> On  4-Nov-2009, Søren Hauberg wrote:
>
> | I'm just following this from the side-line, so this is probably a stupid
> | question...  What is 'libtool' supposed to do here? Is it just supposed
> | generate a set of compiler and linker flags that ensures that the .oct
> | file can be generated? If so, are these flags the same every time
> | 'mkoctfile' is called? If so, can't we just generate these flags when
> | Octave is compiled instead of generating them at run-time?
>
> I don't know the reasoning behind the design choices that resulted in
> rules like
>
>   LTCOMPILE = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
>  --mode=compile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
>  $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
>
>   .c.lo:
>  depbase=`echo $@ | sed 's|[^/]*$$|$(DEPDIR)/&|;s|\.lo$$||'`;\
>  $(LTCOMPILE) -MT $@ -MD -MP -MF $$depbase.Tpo -c -o $@ $< &&\
>  $(am__mv) $$depbase.Tpo $$depbase.Plo
>
> etc., and embedding the logic for precisely how to compile a source
> file or assemble a library inside the libtool script instead of
> exposing that logic directly in the Makefile (via apropriate
> automake/autoconf macros, for example).  I don't see that this
> question is directly answered in the libtool documentation.  Maybe
> this question should be directed tothe autoconf/automake/libtool
> developers?

With all due respect, but at this point I'd like to re-raise the
question, why are you trying to switch to libtool in the first place?
What's so complex about compiling a source file and linking a library
supposing for simplicity one is using the gnu compiler/linker suite?
(Does libtool even support different compilers?)

You have to tell libtool which additional libraries to link to, you have
to tell libtool which {C|CPP|CXX|LD}FLAGS to use, you have to tell
libtool via -I and -L where to search for files. So it does not ease
your work here, and instead of a makefile rule like

%.c : %.o
        $(CC) $(CFLAGS) $(CPPFLAGS) -c -o $@ $<

foo.dll : $(FOO_OBJ)
        $(CC) -shared $(LDFLAGS) $(LIBS) -o $@ $^

you end up with makefile rules which are fairly more complex and hard to
  reason.

Besides, did you actually take a look at the code in libtool?
I find it utterly confusing, complex, hard to understand and even harder
to use. If I compare it to octave's current makefiles, then these are
much cleaner, clearer and easier to adapt and maintain. They do not
require any of the confusing logic embedded in libtool. And - most
important of all - they work!

> However, consider the alternative of eliminating the libtool script in
> favor of having the logic of the libtool script exposed in the
> Makefile itself.  Then to use that logic in the mkoctfile script, we
> would have to duplicate it.  But the Makefile rules would not be
> exactly what we need.  This is the situation we have now with Octave's
> current build system.  So it makes some sense to avoid the duplication
> and just put the logic in a single script that can be called from a
> Makefile or some other script.

Ok, my view is surely limited to windows platform, but I don't see the
necessity to use all the logic that libtool uses (logic? what logic?),
so there's no need in duplicating it, so that is not really a good
argument to promote the use of libtool, IMO.
Libtool actually complicates matters, not simplifies them.
The mingw port of the gnu compiler is resposible for taking care of
providing the correct flags to GNU ld, collecting the right crt
libraries and system-specific object files.
There is no extra compiler flag necesary to build a shared library, and
there is no extra link flag execpt for "-shared". The gcc/binutils suite
  does a good job at this.
libtool does not add anything there so I fail to see the gain in its use.

benjamin

[Benjamin Lindner]

John W. Eaton wrote:

> On  4-Nov-2009, Jaroslav Hajek wrote:
>
> | The only perl script is octave/mk-opts.pl, and it is only used to
> | recreate the option handlers DASPK-opts and similar. I think that like
> | awk, bison, flex and gperf, perl is only needed to build from plain
> | repo, but not from the distribution tarball.
>
> There is also the perl function in the interpreter:
>
>   `perl' is a function from the file /usr/share/octave/3.2.3/m/miscellaneous/perl.m
>
>    -- Function File: [OUTPUT, STATUS] = perl (SCRIPTFILE)
>    -- Function File: [OUTPUT, STATUS] = perl (SCRIPTFILE, ARGUMENT1,
>    ARGUMENT2, ...)
>        Invoke perl script SCRIPTFILE with possibly a list of command line
>        arguments.  Returns output in OUTPUT and status in STATUS.
>
>        See also: system

Well, it's a wrapper for "system". I cannot really expect octave to
include a binary of every program a user might call using "system", can I?

> Other functions like tar/untar, zip/unzip, gzip/gunzip, etc. also
> depend on external programs.  Are these all "native Windows" programs?

That depends on which flavor of tar you have installed.
Cygwin tar? Msys Tar? No these are not native versions.
gnuwin32 tar? (don't know if such a thing exists) This would be a native
version.

> If you say yes, then what makes something a "native Windows" program?
> A POSIX shell interpreter is just another program that interprets a
> particular command language.  Isn't the Msys shell a "native Windows"
> program?  Is a program written to depend on it not?  I guess I don't
> understand where you draw the ine.

If an executable does not call native windows api but instead calls e.g.
a posix intermediate layer which translates these calls to windows api
calls, then this executable is not native.
Cygwin provides a posix layer for windows, so a cygwin application is
not native in this sense.
Msys provides a posix layer for windows, so a msys application is again
not native in this sense.

Wine is a native unix application, but the application requiring wine to
run isn't.

> In any case, we would not be exposing libtool or the shell to the
> Octave user.  So I don't see the problem as anything other than having
> to distribute and install some additional programs with binary Octave
> distributions.  People installing from source already have all of these
> tools.  And you already need extra programs to be able to compile .oct
> or .mex files.

No you don't. You need a compiler/linker, but you cannot get past that.
But you don't need anything else.
And creating an oct file is basically a simple one-line statement, which
  - given the experience - a user can call himself. mkoctfile.exe adds
some convenience, as adding octave's include and library directories and
provides octave's numerical libraries if you need them, and supports you
when creating mex files. So it makes life a bit easier for the user.

> | If libtool was only required for generating distrib tarballs, it would
> | make little difference, but making it a requirement for mkoctfile
> | would mean a significant change. Not just for Windows; unless I'm
> | missing something, it would mean that dependency on libtool would be
> | required for Octave packages in GNU/Linux distros as well.
>
> Yes, but libtool is just shell script.

Yes, but to execute it, you need a shell interpreter, which you don't
have in the first place in windows.
If I distribute a batch script, then it's also "just a batch script",
but you won't be able to execute it on a *nix system unless you get a
window command line interpreter.

> | Regarding the question alone (whether to do this or not) I'm yet
> | undecided. I need yet to read carefully John's rationale for the move
> | to gnulib.
>
> We currently use an odd mixture of old and homegrown code to replace
> missing functionality (things like fnmatch, glob, readdir, strftime,
> etc.).  Mostly, we've picked up these functions from other packages at
> random points in time and rarely update them.  The functions in gnulib
> are at least maintained and updated, and mostly better than versions
> that we might write ourselves.  By using gnulib, the portability and
> replacement functions in Octave will be kept up to date automatically
> with little effort on our part.  If there are bugs in these functions,
> then we will fix them in gnulib, and then all the users of gnulib will
> benefit, not just the users of Octave.

 >

> Using gnulib without automake and libtool is just too much effort, so
> we really need to switch Octave's build system to use these tools.
> There are other benefits to using automake and libtool.  First, we get
> correct dependency generation, and it is done simultaneously when
> compiling.  Obsolete dependencies are also handled properly, so that
> will fix a longstanding bug in Octave's Makefiles.  We get dist and
> clean targets in the Makefiles mostly for free.  Dependency tracking
> for the configure script and Makefiles is handled correctly.  With a
> little more effort, we could also have a build system that doesn't
> depend on GNU Make, but I don't see that as a high priority.

But none of these points are necessary for mkoctfile, are they?

Isn't it rather sarcastic, that a library as gnulib which aims at
portability requires you to use libtool to get it built, which is
anyting but portable?

We are always assuming that one builds octave with a gcc compiler. How
about msvc or e.g. the intel compilers? Are they supported by libtool?

benjamin

[Benjamin Lindner]

>
> | One problem I see with gnulib is that it is C-centric rather than
> | C++-centric.
>
> What I'm looking for is something that will handle replacing the core
> POSIX functions on systems that don't have them, or that have broken
> versions.  Most often these days, that is Windows, isn't it?  And
> these are relatively low-level functions defined with C language
> interfaces.  So I don't see this as a problem.

If you aim octave to rely on a posix base, then I guess at the end of
the day, the only reasonable choice for windows platform is cygwin.

benjamin

[Marco atzeri-3]

--- Mer 4/11/09, Benjamin Lindner <lindnerben@...> ha scritto:

> Da: Benjamin Lindner <lindnerben@...>
> Oggetto: Re: libtool and mkoctfile
> A: "John W. Eaton" <jwe@...>
> Cc: maintainers@...
> Data: Mercoledì 4 novembre 2009, 22:44
> >
> > | One problem I see with gnulib is that it is
> C-centric rather than
> > | C++-centric.
> >
> > What I'm looking for is something that will handle
> replacing the core
> > POSIX functions on systems that don't have them, or
> that have broken
> > versions.  Most often these days, that is
> Windows, isn't it?  And
> > these are relatively low-level functions defined with
> C language
> > interfaces.  So I don't see this as a problem.
>
> If you aim octave to rely on a posix base, then I guess at
> the end of the day, the only reasonable choice for windows
> platform is cygwin.
>
> benjamin
>

I start to be worried...to much stress on the windows horizon.

Just for your info I have not yet succeded to build octave
with the new libtool stuff.
I am currently investigating on:
-------------------------------------------------------
*** Warning: This system can not link to static lib archive /bin/../lib/gcc/i686-pc-cygwin/4.3.4/libgfortranbegin.la.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have.
libtool: link: rm -fr  .libs/liboctave.la.lnkscript

*** Warning: linker path does not have real file for library -lcholmod.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libcholmod and none of the candidates passed a file format test
*** using a file magic. Last file checked: /usr/lib/libcholmod.a
----------------------------------------------------------

Any other platform with similar issue ?
It looks that libtool is wrongly guessing what to do.

Marco


     

[Benjamin Lindner]

John W. Eaton wrote:
> On  4-Nov-2009, Benjamin Lindner wrote:
>
> | Aside from the question of unix-sh-interpreter yes or no, I disagree
> | to using libtool, at least for windows platform. Simply because
> | libtool does not work properly for windows.
>
> If there are problems with libtool, then I think we should report them
> and try to get the problems fixed.  That way everyone using libtool
> benefits.

I don't know what expereriences other developers have had, but I am
tending to the other solution: don't use it, if it doesn't *really* help
you and you can get where you want to anyway without it.

For windows it simply doesn't make any sense to use it, just to get
source code compiled and linked. Creating an oct file is a one-liner
with the gnu compiler, and using a nearly-300K sized shell script to do
the job seems - well - strange?

As I said, requiring it for building octave is one thing, I wouldn't
choose it as tool, but I respect your decision, and I think I can get it
working somehow. Not OOTB, but with some hacking.
But I don't see any reasonable point in having it a runtime requirement.

> | At the current stage, windows binaries of octave do not require any
> | privileges for installing a default user (who is not administrator)
> | on windows doesn't have.
>
> Does installing the Msys shell and associated utilities (cp, mv, rm,
> etc.) require administrator privileges?

No, because they do not need to be "installed" in the windows-sense, but
are distributed as binary archives which you can simply unzip and copy.
There is also an installer available which might require administrative
privileges, but I confess I never used it. I download the parts I need,
unpack them and there you are.

benjamin

[John W. Eaton-3]

On  4-Nov-2009, Benjamin Lindner wrote:

| With all due respect, but at this point I'd like to re-raise the
| question, why are you trying to switch to libtool in the first
| place?

In part because it makes it simpler to use gnulib, and I think that
replacing parts of Octave with gnulib equivalents will be helpful and
make Octave more portable and more reliable.

| What's so complex about compiling a source file and linking a library
| supposing for simplicity one is using the gnu compiler/linker suite?

If we were only using GCC on say, GNU/Linux x86 systems, the task
would be far simpler.  But we are not, and I think using libtool is
better than rediscovering all the possible options and methods for
building share libraries on all the systems Octave can run on.

| (Does libtool even support different compilers?)

Yes.  One of the points of libtool is to hide the complexity of
building shared libraries on different systems.

| You have to tell libtool which additional libraries to link to, you have
| to tell libtool which {C|CPP|CXX|LD}FLAGS to use,

The only options I think that you need to specify are the -L, -I, and
-l options (i.e., where are the header files and libraries, and what
are the names of the libraries).  You don't have to know whether the
compiler taks +Z or -fPIC or -Bshareable or -bundle -bundle_loader
or wether the libraries are named .dll or .so or .sl or whatever.
Libtool hides all of those details.  I think that's a good thing.

| you end up with makefile rules which are fairly more complex and hard to
|   reason.

But I shouldn't need to look at those because they are generated by
automake.  The files I edit are the input files for automake, which
are somewhat simpler.

| don't need to lo
| Besides, did you actually take a look at the code in libtool?
| I find it utterly confusing, complex, hard to understand and even harder
| to use. If I compare it to octave's current makefiles, then these are
| much cleaner, clearer and easier to adapt and maintain. They do not
| require any of the confusing logic embedded in libtool. And - most
| important of all - they work!

I'm sorry that you have such a negative attitude about this change.

I have offered to help with the transition, but to do that, I will
need some precise instructions about how to construct the same build
environment that you have on a Windows system.  So far, no one has
posted any instructions that would help me do that, or pointed me to
an existing document that clearly describes how to build Octave on a
Windows system.

| Libtool actually complicates matters, not simplifies them.

>From my point of view, it does simplify things, because it will allow
us to remove some fragile code from Octave's configuration script.

| The mingw port of the gnu compiler is resposible for taking care of
| providing the correct flags to GNU ld, collecting the right crt
| libraries and system-specific object files.

All the compiler front ends I know of do this job.

| There is no extra compiler flag necesary to build a shared library, and
| there is no extra link flag execpt for "-shared". The gcc/binutils suite
|   does a good job at this.

Yet we still have

  *-*-mingw*)
    CPICFLAG=
    CXXPICFLAG=
    FPICFLAG=
    SHLEXT=dll
    SHLLIB=dll.a
    SHLBIN=dll
    DL_LDFLAGS="-shared -Wl,--export-all-symbols -Wl,--enable-auto-import -Wl,--enable-runtime-pseudo-reloc"
    SH_LDFLAGS="-shared -Wl,--export-all-symbols -Wl,--enable-auto-import -Wl,--enable-auto-image-base"
    SONAME_FLAGS='-Wl,--out-implib=$@.a'
    library_path_var=PATH
    SCRIPTS_EXE_SUFFIX='$(EXEEXT)'
  ;;

and

  *-*-msdosmsvc)
    DL_LDFLAGS="-shared"
    CPICFLAG=
    CXXPICFLAG=
    FPICFLAG=
    SHLEXT=dll
    SHLLIB=lib
    SHLBIN=dll
    LIBPRE=
    SHLPRE=
    SHLLIBPRE=
    SHLBINPRE=
    SH_LDFLAGS="-shared"
      if test -n "`echo $CFLAGS | grep -e '-g'`" -o -n "`echo $CXXFLAGS | grep -e '-g'`"; then
      DL_LDFLAGS="$DL_LDFLAGS -g"
      SH_LDFLAGS="$SH_LDFLAGS -g"
    fi
    NO_OCT_FILE_STRIP=true
    library_path_var=PATH
    NO_OCT_FILE_STRIP=true
    ## Extra compilation flags.
    CRUFT_DLL_DEFS="-DCRUFT_DLL"
    OCTAVE_DLL_DEFS="-DOCTAVE_DLL"
    OCTINTERP_DLL_DEFS="-DOCTINTERP_DLL"
    OCTGRAPHICS_DLL_DEFS="-DOCTGRAPHICS_DLL"
    SCRIPTS_EXE_SUFFIX='$(EXEEXT)'

in the Octave configure script.  All of this complexity would be gone.

In a recent message, you said that you were able to build some parts
of Octave with libtool, but that some things were still not working.
What is not working?

Again, I am willing to help with the transition, but I need to have
some precise directions for setting up a build environment that is the
same as yours so I can try to build Octave and see what the problems
are.

jwe

[Benjamin Lindner]

Marco Atzeri wrote:

> --- Mer 4/11/09, Benjamin Lindner <lindnerben@...> ha scritto:
>
>> Da: Benjamin Lindner <lindnerben@...>
>> Oggetto: Re: libtool and mkoctfile
>> A: "John W. Eaton" <jwe@...>
>> Cc: maintainers@...
>> Data: Mercoledì 4 novembre 2009, 22:44
>>> | One problem I see with gnulib is that it is
>> C-centric rather than
>>> | C++-centric.
>>>
>>> What I'm looking for is something that will handle
>> replacing the core
>>> POSIX functions on systems that don't have them, or
>> that have broken
>>> versions.  Most often these days, that is
>> Windows, isn't it?  And
>>> these are relatively low-level functions defined with
>> C language
>>> interfaces.  So I don't see this as a problem.
>> If you aim octave to rely on a posix base, then I guess at
>> the end of the day, the only reasonable choice for windows
>> platform is cygwin.
>>
>> benjamin
>>
>
> I start to be worried...to much stress on the windows horizon.
>
> Just for your info I have not yet succeded to build octave
> with the new libtool stuff.
> I am currently investigating on:
> -------------------------------------------------------
> *** Warning: This system can not link to static lib archive /bin/../lib/gcc/i686-pc-cygwin/4.3.4/libgfortranbegin.la.
> *** I have the capability to make that library automatically link in when
> *** you link to this library.  But I can only do this if you have a
> *** shared version of the library, which you do not appear to have.
> libtool: link: rm -fr  .libs/liboctave.la.lnkscript
>
> *** Warning: linker path does not have real file for library -lcholmod.
> *** I have the capability to make that library automatically link in when
> *** you link to this library.  But I can only do this if you have a
> *** shared version of the library, which you do not appear to have
> *** because I did check the linker path looking for a file starting
> *** with libcholmod and none of the candidates passed a file format test
> *** using a file magic. Last file checked: /usr/lib/libcholmod.a
> ----------------------------------------------------------
>
> Any other platform with similar issue ?
> It looks that libtool is wrongly guessing what to do.

:)

(sorry for me grinning - it's just I see that I am not the only one
having problems with libtool)

Yes I see the same issue. Only for me libtool is mocking about gcc's
-liberty.

I found the following ml thread
http://lists.cairographics.org/archives/cairo/2009-July/017683.html
and I also find, that patching (hacking?) libtool according to the
answer here
http://lists.cairographics.org/archives/cairo/2009-July/017684.html
helps around this issue.

benjamin

[John W. Eaton-3]

On  4-Nov-2009, Benjamin Lindner wrote:

| If you aim octave to rely on a posix base, then I guess at the end of
| the day, the only reasonable choice for windows platform is cygwin.

No, I don't see it that way.  It makes sense to me to write things
like

  strftime (...);

and then provide an strftime function on systems that do not have it
rather than do something like

  #if defined (_MSVC)
    MSVC-spefic code here
  #elif defined (VMS)
    ...
  #elif defined (AMIGA)
    ...
  #elif defined (HAVE_STRFTIME)
    strftime ();
  #else
  #error BARF
  #endif

everywhere the functionality of strftime is needed.  Or even to
encapsulate this myself.  Why reinvent these interfaces?

jwe