Re: Installing DLLs on Cygwin
On 28/09/2014 03:51, Mike Gran wrote: Hello Libtool, I was lead to believe that if I use libtool to install a dll created on Cygwin using automake with a lib_LTLIBRARIES rule, that libtool would install the dll in /usr/bin and the linker and convenience libraries in /usr/lib. but I can't seem to get it to work. For example the libtool invocation below copies the dll into /usr/lib in the invocation below. This is with libtool 2.4.2. $ /usr/bin/libtool --mode=install install -c libguile-ncurses.la /usr/lib libtool: install: install -c .libs/libguile-ncurses.dll.a /usr/lib/libguile-ncurses.dll.a libtool: install: base_file=`basename libguile-ncurses.la` libtool: install: dlpath=`/bin/sh 21 -c '. .libs/'libguile-ncurses.la'i; echo cygguile-ncurses-8.dll'` libtool: install: dldir=/usr/lib/`dirname cygguile-ncurses-8.dll` libtool: install: test -d /usr/lib/. || mkdir -p /usr/lib/. libtool: install: install -c .libs/cygguile-ncurses-8.dll /usr/lib/./cygguile-ncurses-8.dll libtool: install: chmod a+x /usr/lib/./cygguile-ncurses-8.dll libtool: install: if test -n '' test -n 'strip --strip-unneeded'; then eval 'strip --strip-unneeded /usr/lib/./cygguile-ncurses-8.dll' || exit 0; fi libtool: install: install -c .libs/libguile-ncurses.lai /usr/lib/libguile-ncurses.la libtool: install: warning: remember to run `libtool --finish /usr/local/lib' The makefile for the code in question can be found here http://git.savannah.gnu.org/cgit/guile-ncurses.git/tree/ncurses/Makefile.am Any ideas? autoreconf -ifv before conf and make just to be sure the cygwin libtool is used -Mike Gran ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: libtool shouldn't switch to creating static library if it can't create the shared one under Windows
On 6/17/2011 5:49 PM, Charles Wilson wrote: On 6/17/2011 11:03 AM, Marco atzeri wrote: Sorry Chuck, but I can assure you that I am linking against shared dlls, but the detection is incorrect. Well, then that's a bug. Can you give an example of a foo.a, foo.dll.a, and foo-N.dll (plus the -lfoo incantation) you're using for which the detection fails? Maybe we can figure out why func_win32_libid() is failing. -- Chuck Hi Chuck, I guess func_win32_libid() is not failing but the gcc/linker is smarter than libtool expect; or that autoconf is misleading libtool. At configure stage for checking for Fortran 77 libraries of gfortran-4 configure:28653: result: -L/usr/lib/gcc/i686-pc-cygwin/4.3.4 -L/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../.. -lm -lgfortranbegin -lgfortran -lcygwin -luser32 -lkernel32 -ladvapi32 -lshell32 And on Makefile FLIBS = -L/usr/lib/gcc/i686-pc-cygwin/4.3.4 -L/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../.. -lm -lgfortranbegin -lgfortran -lcygwin -luser32 -lkernel32 -ladvapi32 -lshell32 Now in the gfortran package: /lib/gcc/i686-pc-cygwin/4.3.4/libgfortran.a /lib/gcc/i686-pc-cygwin/4.3.4/libgfortran.dll.a /lib/gcc/i686-pc-cygwin/4.3.4/libgfortran.la /lib/gcc/i686-pc-cygwin/4.3.4/libgfortranbegin.a /lib/gcc/i686-pc-cygwin/4.3.4/libgfortranbegin.la libgfortran is available as dynamic and static, while libgfortranbegin is only static libgfortranbegin.a is included as object in the build of the dll/exe, while libgfortran.dll.a is used for the linking with cyggfortran-3.dll Similar thing happens for the few libraries that are available only as static like SuiteSparse checking for ccolamd in -lccolamd result: yes so CCOLAMD_LIBS = -lccolamd But Suitesparse libs are only static: /usr/lib/libamd.a /usr/lib/libbtf.a /usr/lib/libcamd.a /usr/lib/libccolamd.a /usr/lib/libcholmod.a /usr/lib/libcolamd.a /usr/lib/libcsparse.a /usr/lib/libcxsparse.a /usr/lib/libklu.a /usr/lib/libspqr.a /usr/lib/libumfpack.a so they are included as objects in the dll build. For your notice, building octave with lt_cv_deplibs_check_method=pass_all works fine and the program pass all the tests, while without it the program is unusable. Regards Marco ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: libtool shouldn't switch to creating static library if it can't create the shared one under Windows
On 6/17/2011 2:10 AM, Bob Friesenhahn wrote: On Fri, 17 Jun 2011, Vadim Zeitlin wrote: Yes, sorry, I keep forgetting about auto-import feature, I guess I'm just too accustomed to the traditional Windows way and have trouble accepting auto-import magic. It's true that projects using auto-import could live with falling back to a static library. But consider that auto-importing is relatively new so there should be proportionally few projects using it, hence IMHO the risk of breakage remains reasonably small. Most projects using libtool come from Unix/Linux where auto-import is the default so it can be seen that most projects already depend on it (and the main issue for them is to use --no-undefined so libtool will build a DLL). Primarily programs which originated under Windows (or really care about Windows) use the dllexport/dllimport facilities. Bob Bob, Vadim, on cygwin lt_cv_deplibs_check_method=pass_all is my workaround at configure stage to bypass incorrect libtool detection of system capabilities and to allow shared libs building. It made me crazy building octave where the DLL dependency list is very very long. Regards Marco ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: libtool shouldn't switch to creating static library if it can't create the shared one under Windows
On 6/17/2011 4:14 PM, Charles Wilson wrote: On 6/17/2011 3:46 AM, Marco atzeri wrote: on cygwin lt_cv_deplibs_check_method=pass_all is my workaround at configure stage to bypass incorrect libtool detection of system capabilities and to allow shared libs building. It's not about system capabilities in this case. It's about the fact that this -- creating a shared library by linking against existing static libraries -- is a really bad idea. If any of those static libs (a) exports a data item, and (b) is used by more than one DLL in your stack, then you'll end up with two different copies of the data item, and one DLL will use the first copy while the other DLL will use the second copy. Sorry Chuck, but I can assure you that I am linking against shared dlls, but the detection is incorrect. I know that octave on cygwin is an extreme case due its number of dependencies, but it is not the only case. Of course my knowledge of libtool is limited and eventually there is another way but I never found it. -- Chuck Marco ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: bogus warning 'seems to be moved'
--- Ven 24/9/10, Ralf Wildenhues ha scritto: Hello Marco, thanks for the bug report. * Marco Atzeri wrote on Wed, Sep 22, 2010 at 10:49:56AM CEST: is this bogus warning avoidable in the next release ? libtool: link: warning: `/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../libfontconfig.la' seems to be moved libtool: link: warning: `/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../libexpat.la' seems to be moved ... as the files are /usr/lib/libfontconfig.la /usr/lib/libexpat.la .. the *.la files did not moved at all $ libtool --version libtool (GNU libtool 1.3260 2010-09-02) 2.2.11a on cygwin-1.7.x I agree that it is likely that the warning is bogus in your specific case. All other messages in this thread so far have been about slightly different cases; ignore them. To be sure however, please send the full 'libtool --mode=link' command that caused the above warnings, plus all of its output. I'll put fixing this on my TODO list then. Thanks, Ralf Ralf, here is make[3]: Entering directory `/pub/hg/octave_build/src' /bin/sh ../libtool --tag=CXX --mode=link g++-4 -g -O2 -DHAVE_CONFIG_H -mieee-fp -I/usr/include/freetype2 -Wall -W -Wshadow -Wold-style-cast -Wformat -g -O2 -g -O2 -module -no-undefined -o DLD-FUNCTIONS/rand.la -rpath /usr/local/lib/octave-3.3.52+ DLD-FUNCTIONS/rand.lo -no-undefined ./liboctinterp.la ../liboctave/liboctave.la ../libcruft/libcruft.la ../libcruft/libranlib.la ../libgnu/libgnu.la -lm -lwsock32 libtool: link: warning: `/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../libfftw3.la' seems to be moved I noticed that /bin/sh ../libtool --tag=CXX --mode=link g++-4 -g -O2 -DHAVE_CONFIG_H -mieee-fp -I/usr/include/freetype2 -Wall -W -Wshadow -Wold-style-cast -Wformat -g -O2 -g -O2 -release 3.3.52+ -bindir /usr/local/bin -no-und efined -o liboctinterp.la -rpath /usr/local/lib/octave-3.3.52+ liboctinterp_la-Cell.lo liboctinterp_la-bitfcn s.lo liboctinterp_la-c-file-ptr-stream.lo liboctinterp_la-comment-list.lo liboctinterp_la-cutils.lo liboctint erp_la-data.lo very very long liboctinterp_la-Quad-opts.lo ../liboctave/liboctave.la ../libcruft/libcruft.la ../libcruft/libranlib.la ../libgnu/libgnu.la -lfftw3 -lfftw3f -lfreetype -lz -lhdf5 -lz -lfontconfig -lexpat -lfreetype -lz -liconv -L/usr/X11R6/lib -lGL -lGLU -lX11 -lreadline -lncurses -llapack -lblas -lm -lwsock32 -L/usr/lib/gcc/i686-pc-cygwin/4.3.4 -L/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../.. -lm -lgfortranbegin -lgfortran -lcygwin -luser32 -lkernel32 -ladvapi32 -lshell32 -lm -lwsock32 produce a liboctinterp.la with # Libraries that this one depends upon. dependency_libs=' /pub/hg/octave_build/liboctave/liboctave.la -L/usr/lib -lcholmod -lumfpack -lamd -lcamd -lcolamd -lccolamd -lcxsparse /usr/lib/libarpack.la /usr/lib/libqrupdate.la /usr/lib/libfftw3.la /usr/lib/libfftw3f.la /usr/lib/liblapack.la /usr/lib/libncurses.la /usr/lib/libpcre.la /pub/hg/octave_build/libcruft/libcruft.la /usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../libfftw3.la /usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../libfftw3f.la /usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../libhdf5.la -lpthread /usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../libfontconfig.la /usr/lib/libiconv.la /usr/lib/libfreetype.la /usr/lib/libexpat.la /usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../libexpat.la /usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../libfreetype.la -lz /usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../libiconv.la -L/usr/X11R6/lib -lGL -lGLU /usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../libX11.la /usr/lib/libxcb.la /usr/lib/libXau.la /usr/lib/libXdmcp.la -lreadline /usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../libncurses.la /usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../liblapack.la /usr/lib/libblas.la /usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../libblas.la /usr/lib/gcc/i686-pc-cygwin/4.3.4/libgfortran.la -lwsock32 /usr/lib/gcc/i686-pc-cygwin/4.3.4/libstdc++.la' so I have both /usr/lib/libfftw3.la /usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../libfftw3.la that are the same file. Marco ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: bogus warning 'seems to be moved'
--- Ven 24/9/10, Charles Wilson ha scritto: On 9/24/2010 12:45 AM, Marco Atzeri wrote: I am not sure to follow your explanation. on cygwin $cd /usr/lib I'm cross building, using $build_os=cygwin, but $host_os=mingw32, and a cross compiler. I am *not* building natively. In this situation, and with the new sysroot support in libtool, .la files will have a magic marker like this: -L=/some/path, or libdir='=/some/path'. The extra '=' symbol is interpreted by (new) libtool, WHEN it too is told that sysroots are active, to mean: pretend /some/path is prefixed by whatever the sysroot of the current compiler is; e.g. 'i686-pc-mingw32-gcc -print-sysroot' might report: /usr/i686-pc-mingw32/sys-root So, if the .la file in /usr/i686-pc-mingw32/sys-root/mingw/lib/foo.la claims that its libdir should be =/mingw/lib, libtool will magically prepend the compiler's sysroot, and interpret the libdir specification AS IF it said libdir='/usr/i686-pc-mingw32/sys-root/mingw/lib' and not libdir='=/mingw/lib' Since that IS where the .la file is located, all is well and no warning is printed. However, WITHOUT sysroot support in libtool (or if the .la file doesn't have the magic '=' marker) none of this occurs, and libtool will print the warning. But...that's what it is supposed to do in this case. Now, I'm talking ONLY about a cross build situation. See (latest 2.4 libtool) info. There's a whole section about it. -- Chuck thanks for the explanation. I am not cross building, my case is a pure cygwin on cygwin with $ libtool --version libtool (GNU libtool 1.3260 2010-09-02) 2.2.11a and $ gcc --version gcc (GCC) 4.3.4 20090804 (release) 1 Marco ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: bogus warning 'seems to be moved'
--- Gio 23/9/10, Dave Korn ha scritto: On 22/09/2010 09:49, Marco Atzeri wrote: Dear developers, is this bogus warning avoidable in the next release ? libtool: link: warning: `/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../libfontconfig.la' seems to be moved libtool: link: warning: `/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../libexpat.la' seems to be moved ... as the files are /usr/lib/libfontconfig.la /usr/lib/libexpat.la .. the *.la files did not moved at all I see this warning re: libintl when I build libgcj. In that case, it happens because for some reason (I haven't established yet whether this is down to libtool or the libgcj makefile) something goes wrong with directory search paths, and /lib appears in the list ahead of /usr/lib. As a consequence, libtool finds the .la file via Cygwin's /lib mountpoint rather than the real /usr/lib path, all the relative paths are wrong and it looks like the control script has been moved. This shows up in the warning it issues: libtool: link: warning: `/lib/libiconv.la' seems to be moved I wonder if your problem has a similar cause underlying in some way? cheers, DaveK from what I can see the bogus warning is caused by test $absdir != $libdir \ func_warning \`$deplib' seems to be moved changing the warning in test $absdir != $libdir \ func_warning \`$absdir' \`$libdir' \`$deplib' seems to be moved I found: libtool: link: warning: `/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../..' `/usr/lib' `/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../libfftw3.la' seems to be moved so it seems that absdir is not a real absolute directory. and this case block seems the culprit # We need an absolute path. case $dir in [\\/]* | [A-Za-z]:[\\/]*) absdir=$dir ;; *) absdir=`cd $dir pwd` if test -z $absdir; then func_warning cannot determine absolute directory name of \`$dir' absdir=$dir fi ;; esac This assignement would be correct, but it is not applied absdir=`cd $dir pwd` Marco ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: bogus warning 'seems to be moved'
--- Ven 24/9/10, Marco Atzeri ha scritto:
--- Ven 24/9/10, Charles Wilson
ha scritto:
Just FYI...
I don't think the following scenario applies to either
of
you, but I ran
into the warning in the case described below -- and
the
warning is valid
(e.g. we shouldn't try to fix MY case).
I was using a cross compiler with sysroot support
(cygwin-mingw) to
build cygwin's setup.exe. I was linking against
some
pre-built
libraries (compression, gpg) built using that cross
compiler, but using
an older, pre-sysroot-support version of libtool.
(E.g. these libs are
NOT the mingw-libfoo packages currently available
from
cygwin.com).
Anyway, so what I had was:
/usr/i686-pc-mingw32/sys-root/mingw/lib/liblzma.la
etc, but -- because the lib was built using a
non-sysroot
libtool, the
.la file specifies
libdir='/mingw/lib'
NOT
libdir='=/mingw/lib'
So, when building setup.exe using a libtool that
supports
--with-sysroot, it (quite rightly) complains that
liblzma.la appears to
be moved -- because it (a) is NOT in /mingw/lib, and
(b)
doesn't have
the magic '=' sysroot marker.
This is as designed. The fix is for me to rebuild
liblzma et al using
a sysroot-capable libtool.
Just wanted to point out this scenario, which has
similar
symptoms as
those reported by Marco and Dave, but is NOT an
error.
--
Chuck
Charles,
I am not sure to follow your explanation.
on cygwin
$cd /usr/lib
$ grep libdir *.la
libFLAC++.la:libdir='/usr/lib'
libFLAC.la:libdir='/usr/lib'
libGraphicsMagick++.la:libdir='/usr/lib'
libGraphicsMagick.la:libdir='/usr/lib'
libGraphicsMagickWand.la:libdir='/usr/lib'
libICE.la:libdir='/usr/lib'
libMagick++.la:libdir='/usr/lib'
libMagickCore.la:libdir='/usr/lib'
libMagickWand.la:libdir='/usr/lib'
libMrm.la:libdir='/usr/lib'
libSM.la:libdir='/usr/lib'
libUil.la:libdir='/usr/lib'
libX11.la:libdir='/usr/lib'
libXau.la:libdir='/usr/lib'
libXaw7.la:libdir='/usr/lib'
and so on.
and nothing different
there is no libdir='=/...
and on my build
$ find . -name *.la -exec grep libdir \{\} \;
libdir='/usr/local/lib/octave-3.3.52+'
libdir=''
libdir='/usr/local/lib/octave-3.3.52+'
On my humble understanding
libdir is a variable with the name of the directory,
I never saw and not found in libtool documentation
libdir='=/...
could you point me to some documentation about it ?
Marco
___
http://lists.gnu.org/mailman/listinfo/libtool
bogus warning 'seems to be moved'
Dear developers, is this bogus warning avoidable in the next release ? libtool: link: warning: `/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../libfontconfig.la' seems to be moved libtool: link: warning: `/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../libexpat.la' seems to be moved ... as the files are /usr/lib/libfontconfig.la /usr/lib/libexpat.la .. the *.la files did not moved at all $ libtool --version libtool (GNU libtool 1.3260 2010-09-02) 2.2.11a on cygwin-1.7.x It is really annoying and filling one third of my building logs with a large project like octave Marco ___ http://lists.gnu.org/mailman/listinfo/libtool
