Unhelpful behaviour on Cygwin when "file" isn't installed
I tried to search for previous references to this issue, but it's pretty much impossible to usefully search for "file"! Sorry if this is rehashing old discussions. A user reported a problem trying to build my libtool-ed project on cygwin. The problem turned out to be that cygwin apparently doesn't install the "file" utility by default, but libtool tries to use it without checking if it is available (in func_win32_libid it seems). I'm using libtool 1.5.22. Here's the output in question: /bin/sh ../libtool --tag=CXX --mode=link g++ -Wall -Wno-unused -Wno-uninitialized -I/usr/local/include-o xapian.la -rpath /cygdrive/c/wamp/php/ext -L/cygdrive/c/wamp/php/ -lphp5apache2 -avoid-version -module -no-undefined -Wl,--enable-runtime-pseudo-reloc xapian_wrap.lo -Wl,--warn-unresolved-symbols -Wl,--enable-runtime-pseudo-reloc /usr/local/lib/libxapian.la -lstdc++ *** Warning: linker path does not have real file for library -lphp5apache2. *** 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 libphp5apache2 and none of the candidates passed a file format test *** using a file magic. Last file checked: /cygdrive/c/wamp/php//libphp5apache2.dll *** Warning: libtool could not satisfy all declared inter-library *** dependencies of module xapian. Therefore, libtool will create *** a static module, that should work as long as the dlopening *** application is linked with the -dlopen flag. ar cru .libs/xapian.a .libs/xapian_wrap.o ranlib .libs/xapian.a creating xapian.la If "file" isn't available on cygwin by default, I feel it would be better to say so rather than to say that a (probably valid) library failed the file magic test... Also, I have AC_DISABLE_STATIC in configure.ac, so I'm slightly suprised that libtool falls back to building a static library here. Is that supposed to happen? Cheers, Olly ___ http://lists.gnu.org/mailman/listinfo/libtool
exclusive static or shared
I have a number of directories most of which I ONLY want to build shared libraries from. There are a couple that I ONLY want static libraries. Is there a way to turn on/off shared/static libraries. I saw -static which would work IF both build_old_libs=yes. Is there any way to have -static set build_old_libs=yes? This is on cygwin with libtool 1.5.22. Is there a -shared equivelent to disable static and enable shared library building? Chris ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Unhelpful behaviour on Cygwin when "file" isn't installed
Hi Olly, * Olly Betts wrote on Tue, Feb 14, 2006 at 08:06:52PM CET: > I tried to search for previous references to this issue, but it's pretty much > impossible to usefully search for "file"! Sorry if this is rehashing old > discussions. It's not really, but there is a very similar bug report and patch outstanding (which I temporarily forgot about): http://sourceforge.net/mailarchive/forum.php?thread_id=9231830&forum_id=5119 Probably the issue can be solved to not use `file' at all, but I'd still need to think about that. > A user reported a problem trying to build my libtool-ed project on cygwin. > The problem turned out to be that cygwin apparently doesn't install the > "file" utility by default, but libtool tries to use it without checking > if it is available (in func_win32_libid it seems). I'm using libtool 1.5.22. > Here's the output in question: *snip* > If "file" isn't available on cygwin by default, I feel it would be better to > say so rather than to say that a (probably valid) library failed the file > magic > test... Yes. > Also, I have AC_DISABLE_STATIC in configure.ac, so I'm slightly suprised that > libtool falls back to building a static library here. Is that supposed to > happen? Yes, I think that is by design: if libtool doesn't know how to build a shared lib, it should fall back to what it knows instead. At least that seems to me one common reasoning in some libtool constructs. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: call AC_DISABLE_SHARED "conditionally" for a certain host
[ removing the autoconf list ] > * Florian Schricker wrote on Tue, Feb 14, 2006 at 11:03:50AM CET: > > > > AC_CANONICAL_HOST > > case "$host" in > > *-*-linux* | *-*-darwin*) > > ;; > > *-*-mingw32*) > > AC_DISABLE_SHARED > > ;; > > esac > > > > But I guess I am missing something; it does not work. Running this > > configure on GNU/Linux gives: > > > > checking whether to build shared libraries... > > checking whether to build static libraries... yes > > Confirmed with both branch-1-5 and HEAD. > I'm inclined to "fix" this by adjusting the documentation, not the > implementation of these macros. Hrmpf. CVS HEAD Libtool's new interface actually leaves less flexibility for the user there. This will not work: case $host in foo) set_shared=disable-shared ;; *) set_shared= ;; esac LT_INIT([$set_shared]) because the arguments to LT_INIT are interpreted at m4 time already. And this case $host in foo) LT_INIT([disable-shared]) ;; *) LT_INIT ;; esac will cause *major* breakage (thanks to AC_REQUIRE). :-/ Even this, broken as it is for other reasons: AS_IF([test "$host_os" = linux-gnu], [LT_INIT], [AS_IF([test "$host_os" = mingw32] [LT_INIT([disable-shared])])]) will not work: we make sure LT_INIT is expanded only once. Luckily we do have full backward compatible support for AC_DISABLE_SHARED and related macros, including their respective bugs. I'm just wondering whether we should reconsider obsoleting it: I regard the aforementioned use as quite suitable. Another lesson learned: There should be an AS_CASE. Cheers, Ralf ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: Unhelpful behaviour on Cygwin when "file" isn't installed
On Tue, 14 Feb 2006, Ralf Wildenhues wrote: * Olly Betts wrote on Tue, Feb 14, 2006 at 08:06:52PM CET: I tried to search for previous references to this issue, but it's pretty much impossible to usefully search for "file"! Sorry if this is rehashing old discussions. It's not really, but there is a very similar bug report and patch outstanding (which I temporarily forgot about): http://sourceforge.net/mailarchive/forum.php?thread_id=9231830&forum_id=5119 Probably the issue can be solved to not use `file' at all, but I'd still need to think about that. At one time Cygwin used 'objdump' rather than 'file'. Later it was improved to use 'file' since file returns more accurate results. For MSYS/MinGW 'objdump' is still used because 'file' does not come with MSYS. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
libtool (alpha)
I've installed the libtool alpha cvs build under MinGW.
Configuration and install was made under mSys (after replacing
config.{guess,sub}):
../alpha/configure --prefix=/usr
make
Of note: I configured and installed under mSys because under MinGW it
fails (undefined reference to `lt_libltdl_LTX_preloaded_symbols')
When I run a `libtool --help', I get :
host-triplet: powerpc-apple-darwin8.2.0
shell:/bin/sh
compiler: gcc
compiler flags: -g -O2
linker: /i686-pc-msys/bin/ld.exe (gnu? yes)
libtool: (GNU libtool 1.2268 2006/02/13 17:02:28) 2.1a
automake: automake (GNU automake) 1.9.6
autoconf: autoconf (GNU Autoconf) 2.59
How come the host-triplet is detected as *Darwin* ???
If I run `./config.sub `./config.guess`' in the 'libltdl/config'
directory, I get the normal 'i686-pc-msys' or 'i686-pc-mingw32'.
I also get the expected normal response in the ./configure output.
Cheers,
Julien
___
http://lists.gnu.org/mailman/listinfo/libtool
