Re: LT_* equivalent to AC_CHECK_LIB?
Here are some links to the archive that you might find interesting: My suggestion for a LT_AC_CHECK_SHLIB: http://lists.gnu.org/archive/html/libtool/2004-10/msg00222.html Mind that there is a difference between linking a library against a library and linking a library against an application. When linking a library against a library you can not (portably) link a static library against a shared library. Since libtool is able to check for such things this was the reason that I wanted a special CHECK_SHLIB. Links about LT_OUTPUT: http://lists.gnu.org/archive/html/libtool/2004-11/threads.html#00372 http://lists.gnu.org/archive/html/libtool-patches/2005-08/msg00099.html Best regards, Sander On 3-jul-2006, at 20:52, Tim Mooney wrote: This seems like it should be an obvious question, but I'm not finding any obvious answers in either the libtool or autoconf documentation. Is there a libtool-aware equivalent to AC_CHECK_LIB? In other words, if I want to check for foo_amazing_func() in libfoo, and libfoo was built with libtool (and the libfoo.la is hopefully installed on the system), is there an extant macro something like LT_CHECK_LIB(foo,foo_amazing_func) that will try find foo_amazing_func() in libfoo *and* will pull in all the necessary dependencies for libfoo, automatically? The specific case I'm looking at is for a package that wants to check for libneon. Neon (which is a libtool library) might have been linked against OpenSSL (which might require pthread libraries and/or krb5 libraries), and definitely requires one of libxml2 (which might have requirements like zlib, pthread, libm, et. al.) or expat. If I want to check for libneon at configure time, using just AC_CHECK_LIB or AC_SEARCH_LIB will be extremely painful, because even with the fourth argument to either of those macros, I'll still have to write a battery of configure tests to figure out which particular combination of libraries is required to get libneon and its dependencies. If there's a libtool-aware equivalent macro, it would be so much easier. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ http://lists.gnu.org/mailman/listinfo/libtool ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Interix Shared Libraries
Hello Markus,
* Duft Markus wrote on Tue, Jul 04, 2006 at 08:43:59AM CEST:
>
> To bring some (good) news (i think ;o)). I wrote a little compiler
> wrapper you may have heard of -> wgcc
> (www.sourceforge.net/projects/interix-wgcc) which behaves like gcc and
> uses microsofts toolchain in the background. As of 0.6.0 the shared
> library support is quite stable. I also created a little patch for
> libtool 1.5.22 which allows building it shared with wgcc.
Is there interest in getting these changes merged into Libtool?
Support for newer interix major versions is interesting in any case.
Some of your changes look like they break the support for gcc, though,
especially these are problematic:
| diff -rubB libtool-1.5.22.orig/libtool.m4 libtool-1.5.22/libtool.m4
| --- libtool-1.5.22.orig/libtool.m42006-07-03 07:48:02.0 +0200
| +++ libtool-1.5.22/libtool.m4 2006-07-03 07:49:41.0 +0200
| @@ -2361,7 +2361,8 @@
|
| interix*)
|# PIC code is broken on Interix 3.x, that's why |\.a not |_pic\.a here
| - lt_cv_deplibs_check_method='match_pattern /lib[[^/]]+(\.so|\.a)$'
| + lt_cv_deplibs_check_method='pass_all'
| + #lt_cv_deplibs_check_method='match_pattern /lib[[^/]]+(\.so|\.a)$'
|;;
|
| irix5* | irix6* | nonstopux*)
| @@ -3245,7 +3246,7 @@
| _LT_AC_TAGVAR(hardcode_direct, $1)=no
| _LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
| _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-rpath,$libdir'
| -_LT_AC_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-E'
| +_LT_AC_TAGVAR(export_dynamic_flag_spec, $1)=''
| # Hack: On Interix 3.x, we cannot compile PIC because of a broken gcc.
| # Instead, shared libraries are loaded at an image base (0x1000 by
| # default) and relocated if they conflict, which is a slow very memory
| @@ -5542,7 +5543,7 @@
|_LT_AC_TAGVAR(hardcode_direct, $1)=no
|_LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
|_LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-rpath,$libdir'
| - _LT_AC_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-E'
| + _LT_AC_TAGVAR(export_dynamic_flag_spec, $1)=''
|# Hack: On Interix 3.x, we cannot compile PIC because of a broken gcc.
|# Instead, shared libraries are loaded at an image base (0x1000 by
|# default) and relocated if they conflict, which is a slow very memory
|
For the first hunk, you could probably try func_win32_libid (see Cygwin)
when using wgcc (maybe also with gcc), but you'll have to test that.
The other hunks would probably work when special-cased for wgcc only
(does the wrapper only handle C or also C++, Fortran, whatnot?).
I'd prefer to see test results for both wgcc and gcc (see README for how
to report failures) before applying anything, and we'd need a copyright
disclaimers (details off-list).
Cheers, and thanks for sharing this,
Ralf
___
http://lists.gnu.org/mailman/listinfo/libtool
AW: Interix Shared Libraries
Sure it would be great to see my changes incorporated in libtool! ;o)
I'll give func_win32_libid a try, although i'm not sure (after looking at it)
if this will really work ;o// we'l see...
For the other hunks i'll generate another patch to make the changes wgcc only,
and post that patch to sf.net again.
For results with wgcc:
./db/bin/libdb-4.3.so.dll
./glib/bin/libglib-2.0.so.0.800.3.dll
./glib/bin/libgmodule-2.0.so.0.800.3.dll
./glib/bin/libgobject-2.0.so.0.800.3.dll
./glib/bin/libgthread-2.0.so.0.800.3.dll
./interix-rpc/bin/librpc.so.0.0.0.dll
./libiconv/bin/libcharset.so.1.0.0.dll
./libiconv/bin/libiconv.so.2.2.0.dll
./libIDL/bin/libIDL-2.so.0.0.0.dll
./logtool/bin/liblogtool.so.0.0.0.dll
./mico/bin/idl2311.dll
./mico/bin/mico2311.dll
./mico/bin/micocoss2311.dll
./openldap/bin/liblber-2.3.so.0.2.12.dll
./openldap/bin/libldap-2.3.so.0.2.12.dll
./openldap/bin/libldap_r-2.3.so.0.2.12.dll
./openssl/bin/libcrypto.so.dll
./openssl/bin/libssl.so.dll
./ORBit2/bin/libORBit-2.so.0.0.0.dll
./ORBit2/bin/libORBit-imodule-2.so.0.0.0.dll
./ORBit2/bin/libORBitCosNaming-2.so.0.0.0.dll
./ORBit2/lib/bin/Everything_module.so.dll
./popt/bin/libpopt.so.0.0.0.dll
./pthreads-w32/bin/pthreadVC2d.dll
./readline/bin/history5.so.dll
./readline/bin/libhistory.so.dll
./readline/bin/libreadline.so.dll
./readline/bin/readline5.so.dll
./wgcc/bin/libpxwc.so.0.0.0.dll
./zlib/bin/libz.so.1.2.3.dll
All together it's exactly 162 dll's, but the rest is company internal stuff
;o). Although not all of them
(but all of the above) are built using libtool/wgcc combo, one can see that it
at least seems to work ;o)
I'll look into other tests, etc.
Regards, Markus
-Ursprüngliche Nachricht-
Von: Ralf Wildenhues [mailto:[EMAIL PROTECTED]
Gesendet: Dienstag, 4. Juli 2006 13:00
An: Duft Markus
Cc: libtool@gnu.org
Betreff: Re: Interix Shared Libraries
Hello Markus,
* Duft Markus wrote on Tue, Jul 04, 2006 at 08:43:59AM CEST:
>
> To bring some (good) news (i think ;o)). I wrote a little compiler
> wrapper you may have heard of -> wgcc
> (www.sourceforge.net/projects/interix-wgcc) which behaves like gcc and
> uses microsofts toolchain in the background. As of 0.6.0 the shared
> library support is quite stable. I also created a little patch for
> libtool 1.5.22 which allows building it shared with wgcc.
Is there interest in getting these changes merged into Libtool?
Support for newer interix major versions is interesting in any case.
Some of your changes look like they break the support for gcc, though,
especially these are problematic:
| diff -rubB libtool-1.5.22.orig/libtool.m4 libtool-1.5.22/libtool.m4
| --- libtool-1.5.22.orig/libtool.m42006-07-03 07:48:02.0 +0200
| +++ libtool-1.5.22/libtool.m4 2006-07-03 07:49:41.0 +0200
| @@ -2361,7 +2361,8 @@
|
| interix*)
|# PIC code is broken on Interix 3.x, that's why |\.a not |_pic\.a
| here
| - lt_cv_deplibs_check_method='match_pattern /lib[[^/]]+(\.so|\.a)$'
| + lt_cv_deplibs_check_method='pass_all'
| + #lt_cv_deplibs_check_method='match_pattern /lib[[^/]]+(\.so|\.a)$'
|;;
|
| irix5* | irix6* | nonstopux*)
| @@ -3245,7 +3246,7 @@
| _LT_AC_TAGVAR(hardcode_direct, $1)=no
| _LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
| _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-rpath,$libdir'
| -_LT_AC_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-E'
| +_LT_AC_TAGVAR(export_dynamic_flag_spec, $1)=''
| # Hack: On Interix 3.x, we cannot compile PIC because of a broken gcc.
| # Instead, shared libraries are loaded at an image base (0x1000 by
| # default) and relocated if they conflict, which is a slow very
| memory @@ -5542,7 +5543,7 @@
|_LT_AC_TAGVAR(hardcode_direct, $1)=no
|_LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
|_LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-rpath,$libdir'
| - _LT_AC_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-E'
| + _LT_AC_TAGVAR(export_dynamic_flag_spec, $1)=''
|# Hack: On Interix 3.x, we cannot compile PIC because of a broken gcc.
|# Instead, shared libraries are loaded at an image base (0x1000 by
|# default) and relocated if they conflict, which is a slow very
| memory
|
For the first hunk, you could probably try func_win32_libid (see Cygwin) when
using wgcc (maybe also with gcc), but you'll have to test that.
The other hunks would probably work when special-cased for wgcc only (does the
wrapper only handle C or also C++, Fortran, whatnot?).
I'd prefer to see test results for both wgcc and gcc (see README for how to
report failures) before applying anything, and we'd need a copyright
disclaimers (details off-list).
Cheers, and thanks for sharing this,
Ralf
___
http://lists.gnu.org/mailman/listinfo/libtool
AW: Interix Shared Libraries
Pfuh I ran some tests now ;o) The thing is, that i left libtool as it was (my patches applied) when i built it using wgcc (i normally use gcc to build it, since i don't need libltdl, so it doesn't really matter), so the configure used hadn't got My changes in it (it tried updating by itself, but it seems i'm missing the right autotools versions ;o)). Some tests failed, the first some with a segfault, and the latter ones, which try to exec something simply don't find their .dll file, because the path (really PATH on windows) has to be set to point to the dll. Then again some segfaults, but i'll look into this ;o) I'll tomorrow manually bootstrap libtool with itsself, so i get wgcc in... Maybe then more tests succeed. Testing wgcc on f77 is a little unfair ;o) wgcc is C and C++ (everything M$'s cl.exe can do)... Heres the output for wgcc: == mduft wgcc $ gmake check Making check in . gmake[1]: Nothing to be done for `check-am'. Making check in libltdl Making check in doc gmake[1]: Nothing to be done for `check'. Making check in tests gmake check-TESTS PASS: cdemo-static.test PASS: cdemo-make.test PASS: cdemo-exec.test PASS: demo-static.test PASS: demo-make.test PASS: demo-exec.test PASS: demo-inst.test PASS: demo-unst.test PASS: depdemo-static.test PASS: depdemo-make.test PASS: depdemo-exec.test PASS: depdemo-inst.test PASS: depdemo-unst.test PASS: mdemo-static.test PASS: mdemo-make.test PASS: mdemo-exec.test FAIL: mdemo-inst.test PASS: mdemo-unst.test PASS: cdemo-conf.test PASS: cdemo-make.test PASS: cdemo-exec.test PASS: demo-conf.test FAIL: demo-make.test FAIL: demo-exec.test FAIL: demo-inst.test PASS: demo-unst.test FAIL: deplibs.test PASS: depdemo-conf.test PASS: depdemo-make.test FAIL: depdemo-exec.test FAIL: depdemo-inst.test PASS: depdemo-unst.test PASS: mdemo-conf.test FAIL: mdemo-make.test SKIP: mdemo-exec.test SKIP: mdemo-inst.test PASS: mdemo-unst.test FAIL: dryrun.test PASS: demo-nofast.test FAIL: demo-make.test FAIL: demo-exec.test FAIL: demo-inst.test PASS: demo-unst.test PASS: demo-pic.test FAIL: demo-make.test FAIL: demo-exec.test PASS: demo-nopic.test FAIL: demo-make.test FAIL: demo-exec.test PASS: depdemo-nofast.test PASS: depdemo-make.test FAIL: depdemo-exec.test FAIL: depdemo-inst.test PASS: depdemo-unst.test PASS: cdemo-shared.test PASS: cdemo-make.test PASS: cdemo-exec.test PASS: demo-shared.test FAIL: demo-make.test FAIL: demo-exec.test FAIL: demo-inst.test SKIP: hardcode.test SKIP: build-relink.test SKIP: noinst-link.test PASS: demo-unst.test PASS: depdemo-shared.test PASS: depdemo-make.test FAIL: depdemo-exec.test FAIL: depdemo-inst.test FAIL: build-relink2.test PASS: depdemo-unst.test PASS: mdemo-shared.test FAIL: mdemo-make.test SKIP: mdemo-exec.test SKIP: mdemo-inst.test PASS: mdemo-unst.test PASS: assign.test PASS: link.test PASS: link-2.test PASS: nomode.test PASS: quote.test PASS: sh.test PASS: suffix.test PASS: pdemo-conf.test FAIL: pdemo-make.test FAIL: pdemo-exec.test FAIL: pdemo-inst.test PASS: mdemo-conf.test FAIL: mdemo-make.test PASS: mdemo2-conf.test FAIL: mdemo2-make.test SKIP: mdemo2-exec.test PASS: duplicate_members.test FAIL: link-order.test PASS: tagdemo-static.test FAIL: tagdemo-make.test SKIP: tagdemo-exec.test PASS: tagdemo-conf.test FAIL: tagdemo-make.test SKIP: tagdemo-exec.test PASS: tagdemo-shared.test FAIL: tagdemo-make.test SKIP: tagdemo-exec.test FAIL: f77demo-static.test SKIP: f77demo-make.test SKIP: f77demo-exec.test FAIL: f77demo-conf.test SKIP: f77demo-make.test SKIP: f77demo-exec.test FAIL: f77demo-shared.test SKIP: f77demo-make.test SKIP: f77demo-exec.test 37 of 95 tests failed (17 tests were not run) Please report to bug-libtool@gnu.org gmake[2]: *** [check-TESTS] Error 1 gmake[1]: *** [check-am] Error 2 gmake: *** [check-recursive] Error 1 And here goes the output for gcc, which still did a little better ;o): == mduft gcc $ gmake check Making check in . gmake[1]: Nothing to be done for `check-am'. Making check in libltdl gmake[1]: Nothing to be done for `check'. Making check in doc gmake[1]: Nothing to be done for `check'. Making check in tests gmake check-TESTS PASS: cdemo-static.test PASS: cdemo-make.test PASS: cdemo-exec.test PASS: demo-static.test PASS: demo-make.test PASS: demo-exec.test PASS: demo-inst.test PASS: demo-unst.test PASS: depdemo-static.test PASS: depdemo-make.test PASS: depdemo-exec.test PASS: depdemo-inst.test PASS: depdemo-unst.test PASS: mdemo-static.test PASS: mdemo-make.test PASS: mdemo-exec.test PASS: mdemo-inst.test PASS: mdemo-unst.test PASS: cdemo-conf.test PASS: cdemo-make.test PASS: cdemo-exec.test PASS: demo-conf.test PASS: demo-make.test PASS: demo-exec.test PASS: demo-inst.test PASS: demo-unst.test PASS: deplibs.test PASS: depdemo-conf.test PASS: depdemo-make.test PASS: depdemo-exec.test PASS: depdemo-inst.test PASS: depdemo-unst.
