Re: support AIX 6.1 in config.rpath
Hello,
Ralf Wildenhues wrote:
Hello Rainer,
please post whatever Libtool testsuite log of AIX 6.1 you have to
bug-libtool@gnu.org.
No problem. Is there a size limitation to the post ??
I will look into some of the issues, but it
is very important to have a public archive of these: that way others
can help, too, and yet others who find the same issues can avoid
sending a duplicate report because a web search finds this for them.
If you can do another testsuite run with
./configure LDFLAGS=-Wl,-brtl
OK here are the results of the testsuite (with the pathc to
tests/runpath-in-lalib.at):
command:
export LDFLAGS=-Wl,-brtl
export CC=cc_r
export CXX=xlC_r
gmake -k check VERBOSE=yes
restult:
## ##
## libtool 2.1a test suite. ##
## ##
testsuite: command line was:
$ /daten/source/libtool-HEAD/tests/testsuite MAKE=gmake CC=cc_r
-qlanglvl=extc89 CFLAGS=-g CPP=cc_r -qlanglvl=extc89 -E CPPFLAGS=
LD=/usr/bin/ld LDFLAGS=-Wl,-brtl LIBS= LN_S=ln -s NM=/usr/bin/nm -B
RANLIB=ranlib STRIP=strip OBJEXT=o EXEEXT= SHELL=/bin/sh
CONFIG_SHELL=/bin/sh CXX=xlC_r CXXFLAGS=-g CXXCPP=xlC_r -E F77= FFLAGS=
FC= FCFLAGS= GCJ= GCJFLAGS=-g -O2
_lt_pkgdatadir=/daten/source/libtool-HEAD
LIBTOOLIZE=/daten/source/libtool-HEAD/libtoolize
LIBTOOL=/daten/source/libtool-HEAD/libtool
tst_aclocaldir=/daten/source/libtool-HEAD/libltdl/m4
## --- ##
## ChangeLogs. ##
## --- ##
testsuite: ../ChangeLog:
| 2008-01-05 Rainer Tammer [EMAIL PROTECTED] (tiny change)
| Ralf Wildenhues [EMAIL PROTECTED]
|
| Support AIX 6.1.
| * libltdl/m4/libtool.m4 (_LT_SYS_DYNAMIC_LINKER)
| (_LT_CHECK_MAGIC_METHOD, _LT_COMPILER_PIC, _LT_LINKER_SHLIBS)
| (_LT_LANG_C_CONFIG, _LT_LANG_CXX_CONFIG, _LT_LANG_F77_CONFIG)
| (_LT_LANG_FC_CONFIG): Adjust case patterns to match AIX 6
| through 9 as well.
| * libltdl/m4/ltdl.m4 (LT_SYS_DLOPEN_DEPLIBS): Likewise.
## - ##
## Platform. ##
## - ##
hostname = aixdev01
uname -m = 0001F10AD200
uname -r = 1
uname -s = AIX
uname -v = 6
/usr/bin/uname -p = powerpc
/bin/uname -X = unknown
/bin/arch = unknown
/usr/bin/arch -k = unknown
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo = unknown
/bin/machine = unknown
/usr/bin/oslevel = 6.1.0.0
/bin/universe = unknown
PATH: /daten/source/libtool-HEAD/tests
PATH: /usr/bin
PATH: /etc
PATH: /usr/sbin
PATH: /usr/ucb
PATH: /usr/bin/X11
PATH: /sbin
PATH: /opt/freeware/bin
PATH: /usr/java5/jre/bin
PATH: /usr/java5/bin
PATH: /usr/vac/bin
PATH: /usr/vacpp/bin
PATH: /usr/local/bin
testsuite: atconfig:
| # Configurable variable values for building test suites.
| # Generated by ./config.status.
| # Copyright (C) 2000, 2001, 2003, 2004 Free Software Foundation, Inc.
|
| # The test suite will define top_srcdir=/../.. etc.
| at_testdir='tests'
| abs_builddir='/daten/source/libtool-HEAD/tests'
| at_srcdir='.'
| abs_srcdir='/daten/source/libtool-HEAD/tests'
| at_top_srcdir='..'
| abs_top_srcdir='/daten/source/libtool-HEAD'
| at_top_build_prefix='../'
| abs_top_builddir='/daten/source/libtool-HEAD'
|
| # Backward compatibility with Autotest = 2.59b:
| at_top_builddir=$at_top_build_prefix
|
| AUTOTEST_PATH='tests'
|
| SHELL=${CONFIG_SHELL-'/bin/sh'}
## ##
## Tested programs. ##
## ##
## -- ##
## Running the tests. ##
## -- ##
testsuite: starting at: Tue Jan 8 10:51:40 NFT 2008
1. libtoolize macro installation (libtoolize.at:79): ok(0m0.24s 0m0.32s)
2. libtoolize macro serial update (libtoolize.at:103): ok(0m1.37s
0m1.55s)
3. libtoolize config files serial update (libtoolize.at:194): ok
(0m1.95s 0m2.13s)
4. copy ltdl.m4 with shared macro directory (libtoolize.at:295): ok
(0m0.48s 0m0.61s)
5. upgrading verbatim style aclocal.m4 (libtoolize.at:368): ok
(0m3.51s 0m1.79s)
6. duplicate members in archive tests (duplicate_members.at:26): ok
(0m1.06s 0m1.11s)
7. duplicate convenience archive names (duplicate_conv.at:25): ok
(0m1.52s 0m1.65s)
8. preserve duplicate convenience deps (duplicate_deps.at:25): skipped
(duplicate_deps.at:66)
9. inherited_linker_flags (inherited_flags.at:26): ok(0m1.37s 0m1.66s)
10. C convenience archives (convenience.at:30): ok(0m1.73s 0m1.91s)
11. C++ convenience archives (convenience.at:69): ok(0m2.22s 0m2.42s)
12. F77 convenience archives (convenience.at:109): skipped
(convenience.at:110)
13. FC convenience archives (convenience.at:169): skipped
(convenience.at:170)
14. Java convenience archives (convenience.at:229): skipped
(convenience.at:230)
15. Link order test. (link-order.at:26): ok(0m2.07s 0m1.96s)
16. Link order of deplibs. (link-order2.at:46): ok(0m3.68s 0m3.89s)
17. Failure tests (fail.at:27): ok(0m0.63s 0m0.83s)
18. shlibpath_overrides_runpath (shlibpath.at:25): ok(0m0.86s 0m0.97s)
19. Runpath in libtool library files (runpath-in-lalib.at:25): ok
libtool ChangeLog libltdl/m4/libtool.m4
CVSROOT:/cvsroot/libtool Module name:libtool Changes by: Ralf Wildenhues rwild 08/01/08 19:43:29 Modified files: . : ChangeLog libltdl/m4 : libtool.m4 Log message: * libltdl/m4/libtool.m4 (LT_INIT): m4_require, not AC_REQUIRE _LT_CHECK_BUILDDIR, as it's m4_defun'ed, not AC_DEFUN'ed. Report by Peter O'Gorman. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/libtool/ChangeLog?cvsroot=libtoolr1=1.2545r2=1.2546 http://cvs.savannah.gnu.org/viewcvs/libtool/libltdl/m4/libtool.m4?cvsroot=libtoolr1=1.126r2=1.127 ___ Libtool-commit mailing list Libtool-commit@gnu.org http://lists.gnu.org/mailman/listinfo/libtool-commit
libtool ChangeLog libltdl/m4/ltdl.m4
CVSROOT:/cvsroot/libtool Module name:libtool Changes by: Ralf Wildenhues rwild 08/01/08 19:39:20 Modified files: . : ChangeLog libltdl/m4 : ltdl.m4 Log message: * libltdl/m4/ltdl.m4 (_LTDL_INSTALLABLE): Restore correct _LT_BUILD_PREFIX-using code. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/libtool/ChangeLog?cvsroot=libtoolr1=1.2544r2=1.2545 http://cvs.savannah.gnu.org/viewcvs/libtool/libltdl/m4/ltdl.m4?cvsroot=libtoolr1=1.38r2=1.39 ___ Libtool-commit mailing list Libtool-commit@gnu.org http://lists.gnu.org/mailman/listinfo/libtool-commit
Re: FYI: 333-gary-refactor-LTDL_INIT.patch
Hi Gary, * Gary V. Vaughan wrote on Tue, Jan 08, 2008 at 05:23:24AM CET: On 8 Jan 2008, at 04:40, Ralf Wildenhues wrote: With this patch, I see in the log of make distcheck that the libltdl subdirectory is being configured. This is wrong, as libltdl in the Libtool package should be in nonrecursive mode rather than in subproject mode. This causes distcheck to fail. Can you fix this? I noticed this yesterday when I started the alpha release process too. Yes, I'll figure this out before I go any further. It is because _LTDL_SETUP calls _LTDL_MODE_DISPATCH which calls AC_CONFIG_SUBDIRS. That's wrong, no? Is that because implicitly subproject-libltdl mode is assumed for the Libtool package? Cheers, Ralf
m4_require _LT_CHECK_BUILDDIR
Hello, Peter reported this a while ago. Applied as below. Cheers, Ralf 2008-01-08 Ralf Wildenhues [EMAIL PROTECTED] * libltdl/m4/libtool.m4 (LT_INIT): m4_require, not AC_REQUIRE _LT_CHECK_BUILDDIR, as it's m4_defun'ed, not AC_DEFUN'ed. Report by Peter O'Gorman. Index: libltdl/m4/libtool.m4 === RCS file: /cvsroot/libtool/libtool/libltdl/m4/libtool.m4,v retrieving revision 1.126 diff -u -r1.126 libtool.m4 --- libltdl/m4/libtool.m4 7 Jan 2008 21:13:23 - 1.126 +++ libltdl/m4/libtool.m4 8 Jan 2008 19:42:51 - @@ -69,7 +69,7 @@ AC_BEFORE([$0], [LT_LANG])dnl AC_BEFORE([$0], [LT_OUTPUT])dnl AC_BEFORE([$0], [LTDL_INIT])dnl -AC_REQUIRE([_LT_CHECK_BUILDDIR])dnl +m4_require([_LT_CHECK_BUILDDIR])dnl dnl Autoconf doesn't catch unexpanded LT_ macros by default: m4_pattern_forbid([^_?LT_[A-Z_]+$])dnl
Re: FYI: 337-gary-remember-to-use-_LT_BUILD_PREFIX.patch
Hello Gary,
* Gary V. Vaughan wrote on Tue, Jan 08, 2008 at 06:29:08AM CET:
* libltdl/m4/ltdl.m4 (LTDL_INSTALLABLE): Use _LT_BUILD_PREFIX
instead of ${top_builddir} for Autoconf-2.62.
Reported by Ralf Wildenhues [EMAIL PROTECTED]
[...]
--- libltdl/m4/ltdl.m4 8 Jan 2008 05:16:08 - 1.37
+++ libltdl/m4/ltdl.m4 8 Jan 2008 05:21:05 -
@@ -169,7 +169,7 @@
;;
*) enable_ltdl_install=yes
ac_configure_args=$ac_configure_args --enable-ltdl-install
- LIBLTDL='${top_builddir}'${lt_ltdl_dir+/$lt_ltdl_dir}/libltdl.la
+ LIBLTDL='_LT_BUILD_PREFIX'${lt_ltdl_dir+/$lt_ltdl_dir}/libltdl.la
LTDLINCL='-I${top_srcdir}'${lt_ltdl_dir+/$lt_ltdl_dir}
;;
I applied this fix to your code that really restores the old code.
This failure is exposed with a new-enough Autoconf and test 55
(installable libltdl).
Cheers,
Ralf
2008-01-08 Ralf Wildenhues [EMAIL PROTECTED]
* libltdl/m4/ltdl.m4 (_LTDL_INSTALLABLE): Restore correct
_LT_BUILD_PREFIX-using code.
Index: libltdl/m4/ltdl.m4
===
RCS file: /cvsroot/libtool/libtool/libltdl/m4/ltdl.m4,v
retrieving revision 1.38
diff -u -r1.38 ltdl.m4
--- libltdl/m4/ltdl.m4 8 Jan 2008 05:21:49 - 1.38
+++ libltdl/m4/ltdl.m4 8 Jan 2008 19:38:12 -
@@ -169,7 +169,7 @@
;;
*) enable_ltdl_install=yes
ac_configure_args=$ac_configure_args --enable-ltdl-install
- LIBLTDL='_LT_BUILD_PREFIX'${lt_ltdl_dir+/$lt_ltdl_dir}/libltdl.la
+ LIBLTDL='_LT_BUILD_PREFIX'${lt_ltdl_dir+$lt_ltdl_dir/}libltdl.la
LTDLINCL='-I${top_srcdir}'${lt_ltdl_dir+/$lt_ltdl_dir}
;;
esac
Re: FYI: 333-gary-refactor-LTDL_INIT.patch
Hi Gary,
* Gary V. Vaughan wrote on Tue, Jan 08, 2008 at 10:00:30AM CET:
On 8 Jan 2008, at 04:40, Ralf Wildenhues wrote:
There is code that checks $prefix/lib. I realize this has been that
way
before your patch, but shouldn't we test (expanded) $libdir instead,
so
that users of libdir='${prefix}/lib64' get what they want?
Hmm. Well, looking through the expanded testsuite, and the Makefile
rules that call it, libdir is not set. Some of our tests fake it by
setting it in the .at file (link-order.at f'rinstance), but that
won't help a user with libraries in lib64.
I think I'm not understanding what you're asking for here. Unless it is
fixing a bug, then I'd like to leave it until after the release.
We can well leave it until after the release.
What I meant is this: libdir is usually initialized near the beginning
of a configure script (by Autoconf boilerplate code) like this:
libdir='${prefix}/lib'
and it can be overridden by the user, e.g.:
./configure --prefix=/foo --libdir=/foo/lib64
in which case we'd be looking at /foo/lib. But that's not all that
important, users can always get what they want by specifying LIBLTDL
correctly.
Cheers,
Ralf
darwin patches for HEAD
Fails lt_dlopenadvise library loading on darwin6 (but that is not a
regression, fails without this patch too).
Ran the tests on i386-darwin9 and (very slowly on) ppc-darwin6.
Ok to apply?
2008-01-08 Peter O'Gorman [EMAIL PROTECTED]
* libltdl/m4/libtool.m4 [darwin]: Reorganize darwin support, use
dsymutil if it is available so that debugging is possible, check
for nmedit and dsymutil with AC_CHECK_TOOL, use the linker flag
-exported_symbols_list in preference to nmedit if it is available.
Drop support for xlc, it is probably broken.
* tests/template.at [darwin]: Skip this test, I can not find a way
to make it work on darwin9 with Xcode-3.0.
* NEWS: Note the dropping of xlc support.
Peter
--
Peter O'Gorman
http://pogma.com
Index: NEWS
===
RCS file: /sources/libtool/libtool/NEWS,v
retrieving revision 1.212
diff -u -r1.212 NEWS
--- NEWS 8 Jan 2008 05:11:14 - 1.212
+++ NEWS 9 Jan 2008 03:08:38 -
@@ -77,6 +77,7 @@
* Changes in supported systems or compilers:
+ - Removed bitrotted support for xlc on Mac OS X.
- Detection of compiler wrappers distcc/ccache and $host_alias prefix.
- Basic support for PIE (position-independent executables).
- Support for DragonFly BSD, improved support for FreeBSD.
Index: libltdl/m4/libtool.m4
===
RCS file: /sources/libtool/libtool/libltdl/m4/libtool.m4,v
retrieving revision 1.127
diff -u -r1.127 libtool.m4
--- libltdl/m4/libtool.m4 8 Jan 2008 19:43:29 - 1.127
+++ libltdl/m4/libtool.m4 9 Jan 2008 03:08:42 -
@@ -888,6 +888,112 @@
$RM -r conftest*
])# _LT_LINKER_BOILERPLATE
+# _LT_REQUIRED_DARWIN_TOOLS
+# -
+m4_defun([_LT_REQUIRED_DARWIN_TOOLS],[
+ AC_CHECK_TOOL([DSYMUTIL], [dsymutil], [:])
+ AC_CHECK_TOOL([NMEDIT], [nmedit], [:])
+ _LT_DECL([], [DSYMUTIL], [1],
+[])
+ _LT_DECL([], [NMEDIT], [1],
+[])
+])
+
+
+# _LT_DARWIN_LINKER_FEATURES
+# --
+# Checks for linker and compiler features on darwin
+m4_defun([_LT_DARWIN_LINKER_FEATURES],
+[
+m4_require([_LT_REQUIRED_DARWIN_TOOLS])
+m4_case([$1],
+ [C], [withGCC=$GCC],
+ [CXX], [withGCC=$GXX],
+ [F77], [withGCC=$G77],
+ [FC], [withGCC=$ac_cv_fc_compiler_gnu],
+ [GCJ], [withGCC=$GCC],
+ [], [withGCC=$GCC],
+ [withGCC=$GCC])
+ _LT_TAGVAR(archive_cmds_need_lc, $1)=no
+ _LT_TAGVAR(hardcode_direct, $1)=no
+ _LT_TAGVAR(hardcode_automatic, $1)=yes
+ _LT_TAGVAR(hardcode_shlibpath_var, $1)=unsupported
+ _LT_TAGVAR(whole_archive_flag_spec, $1)=''
+ _LT_TAGVAR(link_all_deplibs, $1)=yes
+ case $host_os in
+rhapsody* | darwin1.[[012]])
+ _LT_TAGVAR(allow_undefined_flag, $1)='${wl}-undefined ${wl}suppress'
+ ;;
+darwin*) # Darwin 1.3 on
+ # if running on 10.5 or later, the deployment target defaults
+ # to the OS version, if on x86, and 10.4, the deployment
+ # target defaults to 10.4. Don't you love it?
+ case ${MACOSX_DEPLOYMENT_TARGET-10.0},$host in
+ 10.0,i?86*-darwin8*|10.0,*-darwin[[91]]*)
+ _LT_TAGVAR(allow_undefined_flag, $1)='${wl}-undefined ${wl}dynamic_lookup' ;;
+ 10.[[012]]*)
+ _LT_TAGVAR(allow_undefined_flag, $1)='${wl}-flat_namespace ${wl}-undefined ${wl}suppress' ;;
+ 10.*)
+ _LT_TAGVAR(allow_undefined_flag, $1)='${wl}-undefined ${wl}dynamic_lookup' ;;
+ esac
+;;
+ esac
+
+ if test $withGCC = yes; then
+AC_CACHE_VAL([lt_cv_apple_cc_single_mod],
+ [lt_cv_apple_cc_single_mod=no
+ if test -z ${LT_MULTI_MODULE}; then
+ # By default we will add the -single_module flag. You can override
+ # by either setting the environment variable LT_MULTI_MODULE
+ # non-empty at configure time, or by adding -multi_module to the
+ # link flags.
+ echo int foo(void){return 1;} conftest.c
+ $LTCC $LTCFLAGS $LDFLAGS -o libconftest.dylib \
+ -dynamiclib ${wl}-single_module conftest.c
+ if test -f libconftest.dylib; then
+ lt_cv_apple_cc_single_mod=yes
+ rm -rf libconftest.dylib*
+ fi
+ rm conftest.c
+ fi])
+AC_CACHE_VAL([lt_cv_ld_exported_symbols_list],
+ [lt_cv_ld_exported_symbols_list=no
+ save_LDFLAGS=$LDFLAGS
+ echo _main conftest.sym
+ LDFLAGS=$LDFLAGS -Wl,-exported_symbols_list,conftest.sym
+ AC_LINK_IFELSE([AC_LANG_PROGRAM([],[])],
+ [lt_cv_ld_exported_symbols_list=yes],
+ [lt_cv_ld_exported_symbols_list=no])
+ LDFLAGS=$save_LDFLAGS
+])
+if test $lt_cv_apple_cc_single_mod = yes; then
+ _lt_dar_single_mod='$single_module'
+fi
+if test $lt_cv_ld_exported_symbols_list = yes; then
+ _lt_dar_export_syms=' ${wl}-exported_symbols_list,$output_objdir/${libname}-symbols.expsym'
+else
+ _lt_dar_export_syms='~$NMEDIT -s $output_objdir/${libname}-symbols.expsym ${lib}'
+fi
+if test $DSYMUTIL != :; then
+ _lt_dsymutil='~$DSYMUTIL $lib'
+else
+ _lt_dsymutil=
+fi
+output_verbose_link_cmd=echo
+_LT_TAGVAR(archive_cmds,
mingw install directory for shared lib
Hi, I have something like this, plugindir = $(libdir)/plugins plugin_LTLIBRARIES = and plugin_LTLIBRARIES += libfoo.la libfoo_la_SOURCES = foo.cc libfoo_la_LDFLAGS = -no-undefined Now when I do 'make install' with --prefix=install I see this, on linux, I get install/lib/plugins/libfoo.so on windows, I get install/lib/bin/libfoo-0.dll Any idea why the dll isn't going into the plugins dir and why it is going into lib/bin? Thanks, Bob Rossi ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: mingw install directory for shared lib
Hello Bob, * Bob Rossi wrote on Tue, Jan 08, 2008 at 08:18:56PM CET: plugindir = $(libdir)/plugins plugin_LTLIBRARIES = plugin_LTLIBRARIES += libfoo.la libfoo_la_SOURCES = foo.cc libfoo_la_LDFLAGS = -no-undefined Now when I do 'make install' with --prefix=install I see this, on linux, I get install/lib/plugins/libfoo.so on windows, I get install/lib/bin/libfoo-0.dll Any idea why the dll isn't going into the plugins dir and why it is going into lib/bin? I'd say that's a bug. Thanks for the report. It comes from the normal libdir libraries going into $libdir but the DLL into $libdir/../bin so that they are found automatically by the programs that are in $bindir. Obviously there are a few assumptions present here, namely that bindir is libdir/../bin, and that you don't do such reasonable things as above. ;-) General question before fixing this: on w32, should even plugins have their DLLs go to $bindir? Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: mingw install directory for shared lib
On Tue, Jan 08, 2008 at 09:53:24PM +0100, Ralf Wildenhues wrote: Hello Bob, * Bob Rossi wrote on Tue, Jan 08, 2008 at 08:18:56PM CET: plugindir = $(libdir)/plugins plugin_LTLIBRARIES = plugin_LTLIBRARIES += libfoo.la libfoo_la_SOURCES = foo.cc libfoo_la_LDFLAGS = -no-undefined Now when I do 'make install' with --prefix=install I see this, on linux, I get install/lib/plugins/libfoo.so on windows, I get install/lib/bin/libfoo-0.dll Any idea why the dll isn't going into the plugins dir and why it is going into lib/bin? I'd say that's a bug. Thanks for the report. It comes from the normal libdir libraries going into $libdir but the DLL into $libdir/../bin so that they are found automatically by the programs that are in $bindir. Obviously there are a few assumptions present here, namely that bindir is libdir/../bin, and that you don't do such reasonable things as above. ;-) General question before fixing this: on w32, should even plugins have their DLLs go to $bindir? I don't know. I can tell you that I'm successfully loading a plugin that is not in the $bindir using apr (apache portable runtime). I don't think that apr modifies the PATH or anything like that to get this to work. Bob Rossi ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: mingw install directory for shared lib
Shouldn't plug-in -type shared libraries be built with the -module -avoid-version libtool flags? I think with those flags, such libtool-built DLLs get installed in the libdir of the Makefile in question, not libdir/../bin like normal DLLs. --tml ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: mingw install directory for shared lib
On Tue, 8 Jan 2008, Ralf Wildenhues wrote: General question before fixing this: on w32, should even plugins have their DLLs go to $bindir? Plugin modules should be installed adjacent to the .la files in the directory the user specifies since the plugin module should be loaded directly without need to consult the PATH. Of course the .la file needs to correctly reference the location of the plugin module. Only general-purpose DLLs need to be installed in the executable search path. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: ld --rpath problem using libtool
Hi Ralf, Attached are the two logs that you have requested. I hope this helps you further. At least my assumption that libtool should get a library's path information from libx.la is not wrong. ;) Sorry for sending the logs unzipped previously. Many thanks for your help. - Richard config.log.gz Description: GNU Zip compressed data relink.log.gz Description: GNU Zip compressed data ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: ld --rpath problem using libtool
Hello Richard, * Richard Hacker wrote on Wed, Jan 09, 2008 at 07:40:57AM CET: Attached are the two logs that you have requested. I hope this helps you further. At least my assumption that libtool should get a library's path information from libx.la is not wrong. ;) Sorry for sending the logs unzipped previously. Thanks for the resend. I think the issue is this: libtool doesn't add a run path to /opt/etherlab/lib because it thinks the runtime linker will already search that by default. Your --config output shows that it is listed as such: | # Run-time system search path for libraries | sys_lib_dlsearch_path_spec=/lib /usr/lib /usr/X11R6/lib/Xaw3d /usr/X11R6/lib /usr/lib/Xaw3d /usr/i386-suse-linux/lib /usr/local/lib /opt/kde3/lib /opt/gnome/lib /opt/etherlab/lib This typically happens on GNU/Linux if the path is listed in /etc/ld.so.conf* (the Libtool configure macros try to parse that). I'm wondering, if it's listed there (could you please confirm that?), why doesn't the runtime linker find it then in your case? Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
RE: mingw install directory for shared lib
Hm, sorry, as i reread my mail, i realized that the text is in the wrong position ;) of course my comment is targeted ar bob's text, not ralf's question... Duft Markus wrote: Bob Friesenhahn wrote: On Tue, 8 Jan 2008, Ralf Wildenhues wrote: General question before fixing this: on w32, should even plugins have their DLLs go to $bindir? Yes, i'd agree to this... ;o) If you try to load a library by yourself, you will have to know what you're doing. If the DLL is linked to the executable, you have no (easy) way to influence what is done by the loader... Of course there may still be problems if there are dependencies between plugins, that are installed in different directories, since loading one plugin will load all libraries this dll is linked to. If those are plugins themselves, they will have to be in PATH to be found (or in the same directory, etc.). The easiest solution is using parity ;) but thats self-advertisement again, sorry... Cheers, Markus Plugin modules should be installed adjacent to the .la files in the directory the user specifies since the plugin module should be loaded directly without need to consult the PATH. Of course the .la file needs to correctly reference the location of the plugin module. Only general-purpose DLLs need to be installed in the executable search path. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool -- 19. - 21. Februar 2008 Salomon Automation auf der LogiMAT 2008, Neue Messe Stuttgart, Deutschland Halle 6, Stand 527 23. - 27. Februar 2008 MoveRetail auf der EuroShop 2008 in Dusseldorf, Deutschland Halle 6, Stand C50 Salomon Automation GmbH - Friesachstrasse 15 - A-8114 Friesach bei Graz Sitz der Gesellschaft: Friesach bei Graz UID-NR:ATU28654300 - Firmenbuchnummer: 49324 K Firmenbuchgericht: Landesgericht fur Zivilrechtssachen Graz ___ http://lists.gnu.org/mailman/listinfo/libtool
