Re: Introducing a new maintainer of libtool
2024-01-17
Thread
Simon Josefsson via Discussion list for the GNU libtool shared library maintenance tool
Ileana Dumitrescu writes: >> On 16/01/2024 22:59, Simon Josefsson wrote: >> If what's on git master passes self checks, I would package it and >> prepare an alpha release and announce that to pretesters mailing list. >> Assuming there is nothing in git master that really upsets you and needs >> to be backed out. Don't look at more patches until a first pretest >> release is out, IMHO, as I'm sure one can go mad pondering implications >> of a libtool patch forever... > > Thanks, it seems like the general consensus is to get a release out > soon. I went through older emails on the mailing list when Alex Ameen > was named as maintainer, and there were similar opinions on getting a > release out quickly. > > I'll need some time figuring out the release process, but otherwise I > should be able to get an alpha release out soon. Mike has been helpful > and has merged in many patches over the past few days. Looking at that, it seems the bootstrap and bootstrap.conf scripts are really old. Can we switch to latest gnulib tools for release and package management? I am doing that for many projects already, with several different ways of using gnulib, so I can assist with that if you want. Do we have any GitLab CI/CD testing for libtool? I can assist with setting that up too, otherwise I won't have a lot of confidence in modifying bootstrap scripts. I suggest not putting .gitlab-ci.yml into libtool itself, but maintain that outside of libtool, to avoid contaminating libtool with gitlab-specific stuff. /Simon signature.asc Description: PGP signature
Re: Introducing a new maintainer of libtool
2024-01-16
Thread
Simon Josefsson via Discussion list for the GNU libtool shared library maintenance tool
Welcome Ileana! Mike Frysinger writes: > On 13 Jan 2024 14:49, Ileana Dumitrescu wrote: >> My short term plans are to review the numerous mailing list patches and >> get them merged in. This will be an easy and productive first step for >> me and libtool. I will also look at the various distro patches and see >> if any of them are fit to be upstreamed as I have noticed some of the >> distros have been accruing a lot of patches as well. > > i think we should aim to kick out something new sooner rather than later. +1 If what's on git master passes self checks, I would package it and prepare an alpha release and announce that to pretesters mailing list. Assuming there is nothing in git master that really upsets you and needs to be backed out. Don't look at more patches until a first pretest release is out, IMHO, as I'm sure one can go mad pondering implications of a libtool patch forever... /Simon signature.asc Description: PGP signature
Re: Q: Forcing a -Wl,-rpath arg to static lib users
2022-11-17
Thread
Howard Chu via Discussion list for the GNU libtool shared library maintenance tool
Bob Friesenhahn wrote: > On Wed, 16 Nov 2022, Oleg Smolsky wrote: >> >> Leaving it here for posterity. Perhaps someone will do this with a bit more >> finesse and turn it into a proper feature. > > Are you using libtool as originally distributed by the FSF or are you using a > libtool provided by a Linux system package? > > The libtool provided as part of a Linux distribution often hacks libtool so > that it does not include full dependency information in the library.la files. > They > do this in order to avoid "excessive linkage" because they do not want the > program/library to retain full linkage details in case the OS changes the > libraries. > > Shared libraries often/usually only need to know the libraries that they > immediately link with, but static libraries need to know everything, and the > library.la > files are intended to fill that gap. You can now build static libraries that only need to know as much as dynamic libraries need to know, using GNU binutils. The feature was merged ~2 years ago already and is supported by ar, ld, and gold. https://sourceware.org/pipermail/binutils/2020-December/114536.html > > I am thinking that you may be trying to fix something which should already be > working with the original FSF libtool. > > Bob -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
libtool.m4 bug (spaces detection in compiler's output after -L/-R)
Hi!
There is probaby a bug in 'm4/libtool.m4' that prevents correct
detection of all the library paths provided by compiler (comparison is
always FALSE). Here is a small patch:
diff -ruN orig/m4/libtool.m4 patched/m4/libtool.m4
--- orig/m4/libtool.m4 2019-04-18 16:57:12.487507441 +0300
+++ patched/m4/libtool.m4 2019-04-18 16:57:29.503424063 +0300
@@ -7537,8 +7537,8 @@
-L* | -R* | -l*)
# Some compilers place space between "-{L,R}" and the path.
# Remove the space.
- if test x-L = "$p" ||
- test x-R = "$p"; then
+ if test x-L = "x$p" ||
+ test x-R = "x$p"; then
prev=$p
continue
fi
Regards,
Igor.
_______
https://lists.gnu.org/mailman/listinfo/libtool
Re: shared object not being created when building with QNX toolchain
I managed to solve my problem. It was deep in libtools.m4. It turns out that they run $LD --help to scan it for "supported targets.*elf". My $LD had some flags baked in which prevented --help from outputting the correct message. This resulted in archive_cmds not being set, which made shared object linking impossible. Thanks anyway. s1341 On 18 February 2016 at 15:09, s1341-libtool wrote: > Replying to my own question, as I've refined the test case. > > This is the updated Makefile.am: https://ghostbin.com/paste/9wj6d. > > Note that now the libfrida-agent-glue.so and libfrida-agent-container.so > are not expected to be generated. It seems that they were not generated > with the previous makefile, there were just some symlinks created in .libs. > > The libfrida-agent.so is expected to be generated and installed into the > lib directory, but it is not generated. The install target fails with this > output: > > ``` > libtool: install: /usr/bin/install -p .libs/libfrida-agent.so > /home/srubenst/github/frida/build/frida-qnx-arm/lib/libfrida-agent.so > /usr/bin/install: cannot stat '.libs/libfrida-agent.so': No such file or > directory > ``` > > The full output with V=1 is available here: > https://ghostbin.com/paste/37zpz > > Why is the libfrida-agent.so not generated!?! > > Please help me as I am tearing out my hair in frustration here. > > Thanks > s1341 > > On 18 February 2016 at 13:55, s1341-libtool wrote: > >> Hi all, >> >> I'm trying to build this (https://ghostbin.com/paste/ksjht) Makefile.am. >> Unfortunately, for some reason the libfrida-agent.so file is not being >> generated. >> >> The libfrida-agent-container.so and libfrida-agent-glue.so are being >> generated. The files are located in the .libs directory. There is a >> libfrida-agent.la, but no .so. >> >> Note that this same build file works as expected when building using a >> linux-arm toolchain, but fails when using a qnx-arm toolchain. I'm building >> on the same machine, so the only difference between the builds should be >> the toolchain bits themselves (gcc, ld, ar, nm, ...). >> >> I've been struggling with this for a few days now, and I can't seem to >> get it to work. >> >> I'd appreciate any insight or suggestions, as I don't really know how to >> proceed with this. >> >> Thanks >> s1341 >> > > ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: shared object not being created when building with QNX toolchain
Replying to my own question, as I've refined the test case. This is the updated Makefile.am: https://ghostbin.com/paste/9wj6d. Note that now the libfrida-agent-glue.so and libfrida-agent-container.so are not expected to be generated. It seems that they were not generated with the previous makefile, there were just some symlinks created in .libs. The libfrida-agent.so is expected to be generated and installed into the lib directory, but it is not generated. The install target fails with this output: ``` libtool: install: /usr/bin/install -p .libs/libfrida-agent.so /home/srubenst/github/frida/build/frida-qnx-arm/lib/libfrida-agent.so /usr/bin/install: cannot stat '.libs/libfrida-agent.so': No such file or directory ``` The full output with V=1 is available here: https://ghostbin.com/paste/37zpz Why is the libfrida-agent.so not generated!?! Please help me as I am tearing out my hair in frustration here. Thanks s1341 On 18 February 2016 at 13:55, s1341-libtool wrote: > Hi all, > > I'm trying to build this (https://ghostbin.com/paste/ksjht) Makefile.am. > Unfortunately, for some reason the libfrida-agent.so file is not being > generated. > > The libfrida-agent-container.so and libfrida-agent-glue.so are being > generated. The files are located in the .libs directory. There is a > libfrida-agent.la, but no .so. > > Note that this same build file works as expected when building using a > linux-arm toolchain, but fails when using a qnx-arm toolchain. I'm building > on the same machine, so the only difference between the builds should be > the toolchain bits themselves (gcc, ld, ar, nm, ...). > > I've been struggling with this for a few days now, and I can't seem to get > it to work. > > I'd appreciate any insight or suggestions, as I don't really know how to > proceed with this. > > Thanks > s1341 > ___ https://lists.gnu.org/mailman/listinfo/libtool
shared object not being created when building with QNX toolchain
Hi all, I'm trying to build this (https://ghostbin.com/paste/ksjht) Makefile.am. Unfortunately, for some reason the libfrida-agent.so file is not being generated. The libfrida-agent-container.so and libfrida-agent-glue.so are being generated. The files are located in the .libs directory. There is a libfrida-agent.la, but no .so. Note that this same build file works as expected when building using a linux-arm toolchain, but fails when using a qnx-arm toolchain. I'm building on the same machine, so the only difference between the builds should be the toolchain bits themselves (gcc, ld, ar, nm, ...). I've been struggling with this for a few days now, and I can't seem to get it to work. I'd appreciate any insight or suggestions, as I don't really know how to proceed with this. Thanks s1341 ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: v1.5.27a 'syntax error' in numerous packages
looks like you were correct about a straggler from other installs ... whereas my 'usual' cd /usr/local rm -rf include/ltdl.h lib/libltdl* share/libtool share/aclocal-1.10/ltdl.m4 lib/libdl* (rebuild libtool from src) was not sufficiently 'cleansing', a cd /usr/local rm -rf include/ltdl.h lib/libltdl* share/libtool share/aclocal-1.10/ltdl.m4 lib/libdl* rm -rf share/aclocal* rm -rf share/automake* rm -rf share/autoconf* (rebuild libtool from src) certainly was. downstream packages now glibtoolize & build, using 1.5.27a, with no errors. i'm guessing the nomially required rm-ing is somewhere inbetween the two actions; likely at least (just?) the aforementioned 'ltoptions.m4'? but, i'm up-n-running again. thanks. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: v1.5.27a 'syntax error' in numerous packages
> Since _LT_DECL does not appear in the stable branch, except for in a > ChangeLog entry, I believe that aclocal is getting confused and bringing > in bits of libtool-2.2 as well as bits of libtool-1.5. ltoptions.m4 from > libtool-2.2 has this line. that would imply that i did not clean-house properly after downgrading from 22x to 1.5.27a. thought i'd done that sufficiently ... i'll back up to a clean reinstall of autofoo prior to libtool, which (per my notes) is a bit more complete at that, and report back ... thanks. ___ http://lists.gnu.org/mailman/listinfo/libtool
v1.5.27a 'syntax error' in numerous packages
after upgrading from libtool 1.5.25a to 1.5.27a on osx, i'm seeing the same libtool-related error in multiple packages. e.g., building both NEON & SWIG, after a recommended (by them, not me) glibtoolize ./autogen.sh using 1.5.25a, then ./configure ... make install completes without error. using 1.5.27a, and the same steps, ./configure ... dies with the same error for both packages, ./configure: line 4350: syntax error near unexpected token `build_libtool_libs,' ./configure: line 4350: `_LT_DECL(build_libtool_libs, enable_shared, 0,' any suggestions as to what to change/fix? or, drop back again to 1.5.25a? thanks. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: branch-2-2?
what? who? git? (off to dig through archive ...) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: branch-2-2?
thanks for the reply. > maintaining multiple branches needlessly is not worth the time. fair enough. in the interim prior to the creation of that 'real' branch, might be helpful to simply alias head to branch-2-2 ... i could likely be reading it wrong (it's rather, er, involved ...), but it might be (more?) consistent with the cvs numbering instructions. it would make life a little easier for those users that choose to stick with the stable branch -- even after y'all split off a 23x-head, & would not require any of the aforementioned 'needless' branch maintenance. just a thought. ___ http://lists.gnu.org/mailman/listinfo/libtool
branch-2-2?
hi, following threads abt release-2-2 here, i see patches being applied. reading here http://www.gnu.org/software/libtool/contribute.html seems to imply that they'd be applied to release-2-2 in a new branch, branch-2-2 checking here, http://cvs.savannah.gnu.org/viewvc/libtool/?root=libtool i see no such 'sticky tag' defined ... i *do* see MAIN branch-2-0 so, which branch do we use to keep up to date with 2-2 fixes? ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: what's recommended if tests are failing?
np at all! just responding to da man's suggestion :-) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: what's recommended if tests are failing?
hi, > 2.2 has *much* better test coverage. Probably, 1.5x would also fail > the better tests... and more of them than 2.2! that's a good point. thx. > > 2.2x is 'ok', but the tests are problematic? or, drop back to stable > > 15x? > > Use 2.2 given the above pt, clear. > and report any failures you see in the new improved tests to > [EMAIL PROTECTED], so that we can fix them in time for 2.2.2 next > month. already done the other day. pending ... :-) _______ http://lists.gnu.org/mailman/listinfo/libtool
what's recommended if tests are failing?
hi, as they're both 'release versions' now, if 1.5x tests are passing 100%, but 2.2x is showing numerous failures, what's the general consensus on which to use? 2.2x is 'ok', but the tests are problematic? or, drop back to stable 15x? ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 2.2 released.
hi, > db's configuration requires it to know the shared library extension at > configure time, it does this by running the generated libtool script. > It is possible to generate one > during configure, but it does not do so by default. yup. from my own, long-ago email from sleepycat support: "the procedure for updating Berkeley DB's version of libtool is slightly different from just running libtoolize and aclocal" and, they instructed me to do this (which i'm still doing, per my earlier posts): rehash cd /build/db-4.6.21/dist glibtoolize --force --copy cp /usr/local/share/aclocal/libtool.m4 aclocal/libtool.ac sh s_config > Why do you relibtoolize every package prior to building it? not every package, but ... generally, i do since i've been flogged so many times to do so when things don't work. it's become an established habit :-) i've rec'd the "must be consistent with your env" speech more times than i can count. in db's case, as per the aforementioned support email (yes, there were 'problems'), i was told to do it by sleepycat "back when". i also rely a bit on the re-autofoo/re-libtool to give insight as to the 'awareness' (for lack of a better term) of an app's development. a 'red-flag' does get raised for me when something *used* to work with autofoo/libtool, then behavior changes. usually worth some investigation, i find, which is why i raised it here. now, it's still somewhat voudou-ish, imho, so i'm certainly willing to be re-educated ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 2.2 released.
hi, a new *build* of libtool (Build: 1.2599 2008/03/02 00:05:01) 2.2 from cvs seems ok (no noticed errors) on OSX 10.5.2, Darwin Kernel Version 9.2.0: Tue Feb 5 16:15:19 PST 2008; root:xnu-1228.3.13~1/RELEASE_PPC w/ automake --version automake (GNU automake) 1.10.1 autoconf --version autoconf (GNU Autoconf) 2.61 a, make -k check is currently chugging slowly along (test #25 & counting ...) a subsequent build of libtool-2.1-ized libidn, re-glibtoolize'd & autoreconf'd with new 2.2 is also problem-free. but, an attempt @ berkeley-db-4.6.21, after "the age-old way" of, rehash cd /build/db-4.6.21/dist glibtoolize --force --copy cp /usr/local/share/aclocal/libtool.m4 aclocal/libtool.ac sh s_config then ./configure ... complains but doesn't die @, ... checking JMODSUFFIX from libtool... .jnilib ./libtool: line 456: CDPATH: command not found /build/db-4.6.21/build_unix/libtool: line 456: CDPATH: command not found ./libtool: line 456: CDPATH: command not found /build/db-4.6.21/build_unix/libtool: line 456: CDPATH: command not found checking for javac... javac ... however, a subsequent 'make' does die @, ... /bin/sh ./libtool --mode=compile gcc -c -I. -I../dist/.. -I/Library/Frameworks/Tcl.framework/Headers -I/System/Library/Frameworks/JavaVM.framework/Versions/Current/Headers -O3 ../dist/../mutex/mut_tas.c ./libtool: line 456: CDPATH: command not found /build/db-4.6.21/build_unix/libtool: line 456: CDPATH: command not found /build/db-4.6.21/build_unix/libtool: line 1259: func_opt_split: command not found libtool: Version mismatch error. This is libtool 2.2, but the libtool: definition of this LT_INIT comes from an older release. libtool: You should recreate aclocal.m4 with macros from libtool 2.2 libtool: and run autoconf again. make: *** [mut_tas.lo] Error 63 checking fresh bdb src prior to glibtoolize, there are instances of 'CDPATH', grep -rln CDPATH . ./db-4.6.21/dist/aclocal/libtool.m4 ./db-4.6.21/dist/configure ./db-4.6.21/dist/ltmain.sh ./db-4.6.21/mod_db4/configure so, Im not immediately clear whether the complaint originates with new libtool, or db src given an earlier comment you'd made in another thread, > We've tried to maintain full backwards compatibility with 1.5.x, > ... If autoupdate doesn't migrate ... then that's a bug in the libtool > release... i re-tried the bdb build by adding rehash cd /build/db-4.6.21/dist glibtoolize --force --copy cp /usr/local/share/aclocal/libtool.m4 aclocal/libtool.ac sh s_config + autoupdate but, doesn't seem to make a difference, in that I still see, ... ./libtool: line 456: CDPATH: command not found /build/db-4.6.21/build_unix/libtool: line 456: CDPATH: command not found ... during configure, and 'make' still fails as above. is this a libtool or bdb problem? or, am i again missing a new/required step? thoughts? ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: 'make' w/ latest 1.5-branch (1.5.27a) fails @ "X--tag=CC: command not found"
> If you wait just 24 hours or so, I'll release 2.2 proper. and that sounds like a plan! thx. > We've tried to maintain full backwards compatibility with 1.5.x, > ... If autoupdate doesn't migrate ... then that's a bug in the libtool > release... clear. thx again! ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: 'make' w/ latest 1.5-branch (1.5.27a) fails @ "X--tag=CC: command not found"
> Looks like libidn includes libtool-2.1b. honestly, it never dawned on me to check -- 1st time i've ever come across an app that has *newer* libtool than my self built. > rm m4/lt* m4/libtool.m4 build-aux/ltmain.sh > Then retry your glibtoolize autoreconf. that did the trick! thx! i *thought* that forcing gibtoolize with "-f" would overwrite / make consistent all files with local env's versions -- i thought that was the purpose in the 1st place. apparently not always ... so, as i've now seen libtool 2.x "in the wild", is it time to update to the 2x branch? how's backward compat / breakage of older, still-using-15x stuff, in general? thx again. _______ http://lists.gnu.org/mailman/listinfo/libtool
Re: 'make' w/ latest 1.5-branch (1.5.27a) fails @ "X--tag=CC: command not found"
> ltmain.sh is from libtool-2.1b, aclocal.m4 has libtool.m4 from 1.5.27, > and then later ,via m4_include, includes libtool.m4 from 2.1b. You have > created a monster! heh, well, ok then! :-) i'm honestly confused though, as to what/why/how ... e.g., where is 2.1b coming from? am i just lucky that no other apps i've autofoo'd have had a similar prob? checking around, `locate glibtoolize | grep bin` --version /Developer/usr/bin/glibtoolize /usr/bin/glibtoolize /usr/local/bin/glibtoolize /Developer/usr/bin/glibtoolize --version | grep GNU libtoolize (GNU libtool) 1.5.22 /usr/bin/glibtoolize --version | grep GNU libtoolize (GNU libtool) 1.5.22 /usr/local/bin/glibtoolize --version | grep GNU libtoolize (GNU libtool) 1.5.27a > Ensuring that glibtoolize, autoconf and automake are all installed in > the same prefix will usually fix problems like this. which glibtoolize autoconf automake aclocal /usr/local/bin/glibtoolize /usr/local/bin/autoconf /usr/local/bin/automake /usr/local/bin/aclocal > Also ensure that > there is only one libtool.m4 in that prefix/share/aclocal* ls -ald /usr/local/share/aclocal* lrwxr-xr-x 1 root wheel 29 Feb 25 20:19 /usr/local/share/aclocal -> /usr/local/share/aclocal-1.10 drwxr-xr-x 77 root wheel 2618 Feb 27 20:56 /usr/local/share/aclocal-1.10/ lrwxr-xr-x 1 root wheel 29 Feb 25 20:19 /usr/local/share/aclocal-1.7 -> /usr/local/share/aclocal-1.10 lrwxr-xr-x 1 root wheel 29 Feb 25 20:19 /usr/local/share/aclocal-1.8 -> /usr/local/share/aclocal-1.10 lrwxr-xr-x 1 root wheel 29 Feb 25 20:19 /usr/local/share/aclocal-1.9 -> /usr/local/share/aclocal-1.10 find /usr/local/share | grep libtool\.m4 /usr/local/share/aclocal-1.10/libtool.m4 i *thought* i had all the "t's crossed & i's dotted" but, apparently not. given the above, suggestions where to look for the problem? _______ http://lists.gnu.org/mailman/listinfo/libtool
'make' w/ latest 1.5-branch (1.5.27a) fails @ "X--tag=CC: command not found"
hi,
i've
glibtool --version
ltmain.sh (GNU libtool) 1.5.27a (1.1220.2.497 2008/02/14 23:48:55)
installed on
uname -v
Darwin Kernel Version 9.2.0: Tue Feb 5 16:15:19 PST 2008;
root:xnu-1228.3.13~1/RELEASE_PPC
atm, i'm building latest IDN,
ftp://alpha.gnu.org/pub/gnu/libidn/libidn-1.5.tar.gz
from src. out of the box,
./configure
make
completes without error. but, if i first,
glibtoolize -f -c
autoreconf -f -i
then again,
./configure
make
it dies @,
...
mv unistd.h-t unistd.h
make all-am
/bin/sh ../libtool --tag=CC --mode=compile gcc -std=gnu99
-DHAVE_CONFIG_H -I. -I.. -I/usr/local/include -g -O2 -MT
progname.lo -MD -MP -MF .deps/progname.Tpo -c -o progname.lo
progname.c
../libtool: line 821: X--tag=CC: command not found
../libtool: line 854: libtool: ignoring unknown tag : command not found
../libtool: line 821: X--mode=compile: command not found
../libtool: line 988: *** Warning: inferring the mode of operation
is deprecated.: command not found
../libtool: line 989: *** Future versions of Libtool will require
--mode=MODE be specified.: command not found
../libtool: line 1132: Xgcc: command not found
../libtool: line 1132: X-std=gnu99: command not found
../libtool: line 1132: X-DHAVE_CONFIG_H: command not found
../libtool: line 1132: X-I.: command not found
../libtool: line 1132: X-I..: command not found
../libtool: line 1132: X-I/usr/local/include: No such file or directory
../libtool: line 1132: X-g: command not found
../libtool: line 1132: X-O2: command not found
../libtool: line 1132: X-MT: command not found
../libtool: line 1132: Xprogname.lo: command not found
../libtool: line 1132: X-MD: command not found
../libtool: line 1132: X-MP: command not found
../libtool: line 1132: X-MF: command not found
../libtool: line 1132: X.deps/progname.Tpo: No such file or directory
../libtool: line 1132: X-c: command not found
../libtool: line 1185: Xprogname.lo: command not found
../libtool: line 1190: libtool: compile: cannot determine name of
library object from `': command not found
make[3]: *** [progname.lo] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
searching on ("X--tag=CC: command not found"), there's _one_ recent
(Feb 5 '08) result. Tho my italian's not so good ;-) seems like a
libtool bug suspect.
is it? any workaround atm?
thanks.
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: [cygwin] Analysis for new testsuite failures 33,34.35
On Mon, 26 Mar 2007 20:39:24 +0200, "Ralf Wildenhues" said: > Hi Charles, > > Thanks for the bug report. > > * Charles Wilson wrote on Fri, Mar 23, 2007 at 07:32:12AM CET: > > > > ../../libtool-HEAD/tests/subproject.at:56: $MAKE all $tst_dist > > + make all dist > [...] > > mkdir: cannot create directory > > `/usr/src/libtool/cvs/_build/tests/testsuite.dir/33/subproject-demo-2.1a/sub/ltdl': > > > > File exists > > make[2]: *** [distdir] Error 1 > > AFAICS, this can only happen if libltdl was treated with automake-1.9 > and the tests run with automake-1.10 in place, so that the toplevel > package (named subproject-demo-2.1a) is treated with 1.10. I'm not so sure; I believe I first encountered the problem using 1.9.6 exclusively, but I will rebootstrap explicitly with (unpatched) 1.9 and make sure. > Alexandre said he did not want to continue 1.9. That's what I thought. If I am right (above), then this is bad, and libtool/libltdl from HEAD/2.0 will require 1.10 (if one cares about the facilities tested by 33,34,35: subproject libltdl). I hope I'm wrong... -- Chuck ___ http://lists.gnu.org/mailman/listinfo/libtool
Build shared library with shared libraries and static libraries on HP-UX
Hello, I would like compile a shared library of PHP for loading it into apache on the HP-UX os. The problem is that i cannot because : - one of the different libraries used by php for compiling is c-client (imap) who is only available as a static library. - and libtool doesn't accept mixed static and shared library the final result in this case is always a static library. This situation occured on HP-UX but not on Linux. My question are : - Why it's not possible to mix libraries on HP-UX ? - Is there a way to resolve this situation ? Thanks a lot for any answer @++ JC ___ http://lists.gnu.org/mailman/listinfo/libtool
The results of your email commands
The results of your email command are provided below. Attached is your original message. - Results: Ignoring non-text/plain MIME parts - Unprocessed: No credit card required http://ace.casino.cls2.org/iwin.html James - Done. --- Begin Message --- Here is a casino giving away $25 Free when you sign up an account. No credit card required http://ace.casino.cls2.org/iwin.html James --- End Message --- ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Your message to Libtool-commit awaits moderator approval
Your mail to 'Libtool-commit' with the subject Sat, 26 Jun 2004 13:25:15 -0600 Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: http://lists.gnu.org/mailman/confirm/libtool-commit/ad515839a0ca0ddb725d7d606a72f003c295b26c _______ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
The results of your email commands
The results of your email command are provided below. Attached is your original message. - Results: Ignoring non-text/plain MIME parts - Unprocessed: No credit card required http://acecasino.cls2.org/iwin.html James - Done. --- Begin Message --- Here is a casino giving away $25 Free when you sign up an account. No credit card required http://acecasino.cls2.org/iwin.html James --- End Message --- ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Your message to Libtool-commit awaits moderator approval
Your mail to 'Libtool-commit' with the subject
Libtool
Is being held until the list moderator can review it for approval.
The reason it is being held:
Post by non-member to a members-only list
Either the message will get posted to the list, or you will receive
notification of the moderator's decision. If you would like to cancel
this posting, please visit the following URL:
http://lists.gnu.org/mailman/confirm/libtool-commit/106b19942944a1ac380a2dc7ce035c5e691b2f85
_______
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool
The results of your email commands
The results of your email command are provided below. Attached is your original message. - Results: Ignoring non-text/plain MIME parts - Done. --- Begin Message --- Here is a casino giving away $25 Free when you sign up an account. No credit card required http://cas.ino.rli3.org/iwin.html B.Dawn Howell --- End Message --- ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Your message to Libtool-commit awaits moderator approval
Your mail to 'Libtool-commit' with the subject Affiliate Marketers Needed Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: http://lists.gnu.org/mailman/confirm/libtool-commit/a2670b4cdee9c6693e1fdbdd25fb75511dca9800 _______ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
[no subject]
From: Lee Secora <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Date: Tue, 18 May 2004 11:10:44 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: plain Message-Id: <[EMAIL PROTECTED]> Subject: Momentum On The Rise For CGHI.clwpeu X-BeenThere: [EMAIL PROTECTED] X-Mailman-Version: 2.1.4 Precedence: list Reply-To: [EMAIL PROTECTED] List-Id: Discussion list for the GNU libtool shared library maintenance tool List-Unsubscribe: <http://mail.gnu.org/mailman/listinfo/libtool>, <mailto:[EMAIL PROTECTED]> List-Archive: <http://mail.gnu.org/pipermail/libtool> List-Post: <mailto:[EMAIL PROTECTED]> List-Help: <mailto:[EMAIL PROTECTED]> List-Subscribe: <http://mail.gnu.org/mailman/listinfo/libtool>, <mailto:[EMAIL PROTECTED]> Sender: [EMAIL PROTECTED] Errors-To: [EMAIL PROTECTED] f5(366fxam_w62a INVESTORS WEEKLY UPDATE - GET CGHI.OB ASAP SPECIAL-ALERT- Centurion Gold Holdings, Inc CGHI (OTC:BB) is located in Johannesburg, South Africa, started three years ago to identify and acquire promising ore-bearing properties. In the past six months, it has acquired four properties: the Primrose Gold Mine; the Omaruru Gold Mine; the Sallies Mine and a chrome bearing operation. The Company is positioning itself to become a major producer in this market by acquiring mineral bearing properties and mineral rights. The worlds largest producer of gold, South Africas enormous gold ore reserves represent more than 40% of global reserves. On April 22nd the Company announced that it had submitted its application to move to the AMEX. CGHI (OTC:BB) has progressed nicely and is now poised to break out to all new highs on the strength of news coming out soon on some major acquisitions. Watch it move this next week on this news. Check out the gains from our recent recommendations. MACE at 2.11 (NASDQ) High 14.80701% Gain! MAGS at 9.74 (NASDQ) High 40.35414% Gain! GTVCF (OTC:BB) at .52 High 1.02.100% in five days NOW CGHI (OTC:BB) at 1.75 RECORD SETTING HIGH PREDICTED ON NEWS! Centurion Gold Holdings, Inc: CGHI (OTC:BB) Current-Price:2.40 - Up Almost 1.00 And Going Much Higher! Short-Term Target:3.75 12-month target 15.00 on AMEX Shares-Outstanding: 47.8 Million / Float 5 million Revenue/Net Income Projections on Current Holdings YearRevenue ($ millions)Net ($ millions) 2004 5,80 2,270 2005 9,35 3,565 2006 9,90 3,785 200710,40 4,010 200822,40 8,510 Centurion Gold Holdings fiscal year ends March 31. The Company expects to show revenue and net income for its fourth-quarter, when it reports for the period ending March 31. Reasons to buy CGHI: After acquisitions, CGHI annual revenue will be $45.71 million in 2004, with reserves valued at approximately $1.4 billion at 10% of current metal values. With the full development of all assets, by 2008, revenue will be $200 million at current commodity prices in US dollars. OUR ADVICE: GET CGHI.OB TODAY! 1.00 Gain In Less Than 2 Days And Going Much Higher Get It Immediately. It will get much higher on AMEX! +++ 38O 4 13 And he said in answer to me, Have you no knowledge what these are? And I said, No, my lord..txt ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
[no subject]
From: Robena Karshner <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Date: Sun, 16 May 2004 00:02:27 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: plain Message-Id: <[EMAIL PROTECTED]> Subject: Get In On CGHI.OB Today, Don't Miss It wweaup X-BeenThere: [EMAIL PROTECTED] X-Mailman-Version: 2.1.4 Precedence: list Reply-To: [EMAIL PROTECTED] List-Id: Discussion list for the GNU libtool shared library maintenance tool List-Unsubscribe: <http://mail.gnu.org/mailman/listinfo/libtool>, <mailto:[EMAIL PROTECTED]> List-Archive: <http://mail.gnu.org/pipermail/libtool> List-Post: <mailto:[EMAIL PROTECTED]> List-Help: <mailto:[EMAIL PROTECTED]> List-Subscribe: <http://mail.gnu.org/mailman/listinfo/libtool>, <mailto:[EMAIL PROTECTED]> Sender: [EMAIL PROTECTED] Errors-To: [EMAIL PROTECTED] f5(366fxam_w62a INVESTORS WEEKLY UPDATE - GET CGHI.OB ASAP SPECIAL-ALERT- Centurion Gold Holdings, Inc CGHI (OTC:BB) is located in Johannesburg, South Africa, started three years ago to identify and acquire promising ore-bearing properties. In the past six months, it has acquired four properties: the Primrose Gold Mine; the Omaruru Gold Mine; the Sallies Mine and a chrome bearing operation. The Company is positioning itself to become a major producer in this market by acquiring mineral bearing properties and mineral rights. The worlds largest producer of gold, South Africas enormous gold ore reserves represent more than 40% of global reserves. On April 22nd the Company announced that it had submitted its application to move to the AMEX. CGHI (OTC:BB) has progressed nicely and is now poised to break out to all new highs on the strength of news coming out soon on some major acquisitions. Watch it move this next week on this news. Check out the gains from our recent recommendations. MACE at 2.11 (NASDQ) High 14.80701% Gain! MAGS at 9.74 (NASDQ) High 40.35414% Gain! GTVCF (OTC:BB) at .52 High 1.02.100% in five days NOW CGHI (OTC:BB) at 1.75 RECORD SETTING HIGH PREDICTED ON NEWS! Centurion Gold Holdings, Inc: CGHI (OTC:BB) Current-Price:1.58 Short-Term Target:3.75 12-month target 15.00 on AMEX Shares-Outstanding: 47.8 Million / Float 5 million Revenue/Net Income Projections on Current Holdings YearRevenue ($ millions)Net ($ millions) 2004 5,80 2,270 2005 9,35 3,565 2006 9,90 3,785 200710,40 4,010 200822,40 8,510 Centurion Gold Holdings fiscal year ends March 31. The Company expects to show revenue and net income for its fourth-quarter, when it reports for the period ending March 31. Reasons to buy CGHI: After acquisitions, CGHI annual revenue will be $45.71 million in 2004, with reserves valued at approximately $1.4 billion at 10% of current metal values. With the full development of all assets, by 2008, revenue will be $200 million at current commodity prices in US dollars. OUR ADVICE: GET CGHI.OB TODAY! +++ malaprop nought philadelphian jerkin prohibit concerning harder negligence fray ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
The results of your email commands
The results of your email command are provided below. Attached is your original message. No commands were found in this message. To obtain instructions, send a message containing just the word "help". - Done. --- Begin Message --- --- End Message --- _______ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Your message to Libtool-patches awaits moderator approval
Your mail to 'Libtool-patches' with the subject (no subject) Is being held until the list moderator can review it for approval. The reason it is being held: Message has implicit destination Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: http://mail.gnu.org/mailman/confirm/libtool-patches/8c707668a2a173bb48e96b6fdf3d09c436d61d53 _______ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
:)
Argh, i don't like the plaintext :) 71074 -- archive password <> _______ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
The results of your email commands
The results of your email command are provided below. Attached is your original message. - Results: Ignoring non-text/plain MIME parts - Unprocessed: password: 78524 - Done. --- Begin Message --- Looking forward for a response :P password: 78524 <> --- End Message --- ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: DESTDIR installs
==> "pw" == Philip Willoughby <[EMAIL PROTECTED]> writes:
pw> I have the following in a Makefile.am:
pw> pkglib_LTLIBRARIES=libapttlog.la
pw> libapttlog_la_SOURCES=aptt/log/log.c AM_CPPFLAGS=@INCLTDL@
pw> -I$(top_srcdir)/src -I$(top_builddir)/src
pw> libapttlog_la_LIBADD=@LIBLTDL@
pw> lib_LTLIBRARIES=libaptttest.la
pw> libaptttest_la_SOURCES=aptt/test/test.c
pw> libaptttest_la_LIBADD=libapttlog.la @LTLIBINTL@
pw> If I run:
pw> ./configure [Configure args] make make install
pw> everything installs OK, however, if I run:
pw> ./configure [Configure args] make make
pw> DESTDIR=/var/tmp/aptt-0.0.1-1-root/ install
pw> which I need to work to build an rpm cleanly, I get:
I've always felt that this is a deficiency in the way libtool does
its installs. Then again, I use a very old version of libtool,
and this may have been fixed by now...
The problem is, the target install directory in libapptlog.la
(${pkglibdir}, I suppose) is used to link libapptest.la, but at
install time, libtool looks in
${pkglibdir}
only, and not in
$DESTDIR${pkglibdir}
also, like it should.
I see two solutions here. One is to fix libtool so that it
adds -L$DESTDIR${dir} for each -L${dir} found in a dependent
LTLIBRARY. I'm a little wary of patching libtool, so I usually
use a shell script that pretends to be 'gcc', but adds the
desired $DESTDIR link path support.
The other solution, that I use in RPM spec files, is to seed
the environment from within the spec file:
%install
LIBRARY_PATH=${LIBRARY_PATH+":"}$DESTDIR${libdir}
# add other directories as appropriate
export LIBRARY_PATH
make DESTDIR=$RPM_BUILD_ROOT install
Carl
_______
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: Intel icc and shared libs
==> "bw" == Bill Wendling <[EMAIL PROTECTED]> writes: bw> # How to pass a linker flag through the compiler. wl="" bw> to: bw> # How to pass a linker flag through the compiler. wl="-Wl," bw> That might help things... On the version of icc that I use, it's more like wl="-Qoption,ld," Carl ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: version mismatching with ltconfig when building oaf-0.6.5 from src.rpm
On Wed, Dec 19, 2001 at 03:52:33PM +, Alien Daycare wrote: > Don't know if this belongs here or not, but I just got around this > compilation issue. > When executing the command 'rpm -bb --target=i586 oaf.spec' it eventually > winds up telling me > "ltconfig version `' does not match ltmain.sh version `1.3.5'" > After reading through your fine archive and attempting to build this > manually, I figured out that if you suspend the rpm build after seeing the > creation of libtool, and run (from the top level) > './ltconfig ./ltmain.sh', then continue the rpm build, it builds properly. > Funny that... This means the version of libtool provided by oaf and the version of libtool on your system do not match. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
hardcode_into_libs=yes for Tru64 UNIX, IRIX, AIX 4.x
Any objection to setting hardcode_into_libs=yes (currently hardcode_into_libs=no) on Tru64 UNIX 4.x, 5.x, IRIX 6.x, and AIX 4.x, 5.x? -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: ltdl.c thinks it's psychic (another SEGFAULT bug).
On Sat, Nov 10, 2001 at 12:32:46PM -0500, Paul Davis wrote: > >Because ltdl.h already states that libltdl relies on a featureful > >realloc, let's just set lt_dlrealloc = realloc and test for a > >featureful realloc in ltdl.m4. Let's recommend that if anyone changes > >at least one of lt_dlmalloc, lt_dlrealloc, or lt_dlfree, then they > >should also change them all. Let the client worry about malloc/free > >and ltdl be somewhat stupid to the choices of the client. > > what is any of this for in the first place? You mean why do we allos someone to define lt_dlmalloc, lt_dlrealloc, and lt_dlfree? I don't know :) -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: ltdl.c thinks it's psychic (another SEGFAULT bug).
On Wed, Nov 07, 2001 at 12:39:32AM -0600, Rob Browning wrote: > [EMAIL PROTECTED] writes: > > So, if we replace malloc, we then need a table of pointers and their > > size. Worth it? > > If we're going to be using it for anything substantial, I tend to > think this would be *extremely* unwise. Writing a good allocator is > *hard*. > > If the performance is critical, then I suspect we should use the > system realloc if/when we can determine (via configure.in) that it's > reliable, and otherwise, we should be using more explicit means. > Using gnu libc's realloc certainly would have worked better in my > case. > > Anyway from a quick glance, it looks like we're only using realloc for > strings, which you can easily determine the length of, and for > lt_caller_data which could be easily augmented to include a size > field. > > So as one approach, we could just have str_realloc() and > realloc_caller_data(), and then these could use the system realloc > internally on platforms where that's considered beneficial. According to ltdl.h, /* By default, the realloc function pointer is set to our internal realloc implementation which iself uses lt_dlmalloc and lt_dlfree. libltdl relies on a featureful realloc, but if you are sure yours has the right semantics then you can assign it directly. Generally, it is safe to assign just a malloc() and a free() function. */ And, in ltdl.c: /* These are the pointers that can be changed by the caller: */ LT_GLOBAL_DATA lt_ptr (*lt_dlmalloc)LT_PARAMS((size_t size)) = (lt_ptr (*) LT_PARAMS((size_t))) malloc; LT_GLOBAL_DATA lt_ptr (*lt_dlrealloc) LT_PARAMS((lt_ptr ptr, size_t size)) = (lt_ptr (*) LT_PARAMS((lt_ptr, size_t))) rpl_realloc; LT_GLOBAL_DATA void (*lt_dlfree) LT_PARAMS((lt_ptr ptr)) = (void (*) LT_PARAMS((lt_ptr))) free; Because ltdl.h already states that libltdl relies on a featureful realloc, let's just set lt_dlrealloc = realloc and test for a featureful realloc in ltdl.m4. Let's recommend that if anyone changes at least one of lt_dlmalloc, lt_dlrealloc, or lt_dlfree, then they should also change them all. Let the client worry about malloc/free and ltdl be somewhat stupid to the choices of the client. -- albert chin ([EMAIL PROTECTED]) _______ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool 1.4 not passing linker directives
On Fri, Oct 05, 2001 at 01:14:52AM -0400, Ian Peters wrote: > An application I work on has been calling libtool (through automake) > with linker directives on the libtool line, around many of the libraries > specified, like so (apologies if this wraps strangely, it's all one > line): > > /bin/sh ../libtool --mode=link gcc -g -O2 -Wall -Wunused > -Wmissing-prototypes -Wmissing-declarations -o installer > installer-distro.o installer-page.o installer-page-install.o > installer-page-deps.o installer-page-finish.o installer-page-gdm.o > installer-page-method.o installer-page-mirror.o > installer-page-more-deps.o installer-page-proxy.o > installer-page-select.o installer-page-start.o installer-state-machine.o > installer-ui.o ../libredcarpet/src/libredcarpet.a > ../libgnometransfer/src/libgnometransfer.a -Wl,-Bstatic -rdynamic > -L/usr/lib -L/usr/X11R6/lib -L/usr/lib/lib -lgtkhtml -lgal -lgnomeprint > -lglade-gnome -lglade -lxml -lz -lgnomeui -lart_lgpl -lSM -lICE -lgtk > -lgdk -lgmodule -lXi -lXext -lX11 -lgnome -lgnomesupport -lesd > -laudiofile -lm -ldb1 -lglib -ldl -lgnet -rdynamic -lgmodule -lglib -ldl > /home/itp/gdk-pixbuf-0.11.0//gdk-pixbuf/.libs/libgdk_pixbuf.a -lgtk > -lgdk -rdynamic -lgmodule -lglib -ldl -lXi -lXext -lX11 -lm > /home/itp/gdk-pixbuf-0.11.0//gdk-pixbuf/.libs/libgnomecanvaspixbuf.a > /home/itp/imlib-1.9.10//gdk_imlib/.libs/libgdk_imlib.a -ljpeg -ltiff > -lungif -lpng -lz -lm -lgtk -lgdk -rdynamic -lgmodule -lglib -ldl -lXi > -lXext -lX11 -lm -luuid -lcrypt -lz -lutil -Wl,-Bdynamic I see -Wl,-Bstatic -rdynamic -Wl,-Bdynamic > With libtool 1.3.x, this resulted in the following call to gcc: > > gcc -g -O2 -Wall -Wunused -Wmissing-prototypes -Wmissing-declarations -o > installer installer-distro.o installer-page.o installer-page-install.o > installer-page-deps.o installer-page-finish.o installer-page-gdm.o > installer-page-method.o installer-page-mirror.o > installer-page-more-deps.o installer-page-proxy.o > installer-page-select.o installer-page-start.o installer-state-machine.o > installer-ui.o ../libredcarpet/src/libredcarpet.a > ../libgnometransfer/src/libgnometransfer.a -Wl,-Bstatic -rdynamic > -L/usr/lib -L/usr/X11R6/lib -L/usr/lib/lib -lgtkhtml -lgal -lgnomeprint > -lglade-gnome -lglade -lxml -lz -lgnomeui -lart_lgpl -lSM -lICE -lgtk > -lgdk -lgmodule -lXi -lXext -lX11 -lgnome -lgnomesupport -lesd > -laudiofile -lm -ldb1 -lglib -ldl -lgnet -rdynamic -lgmodule -lglib -ldl > /home/itp/gdk-pixbuf-0.11.0/gdk-pixbuf/.libs/libgdk_pixbuf.a -lgtk -lgdk > -rdynamic -lgmodule -lglib -ldl -lXi -lXext -lX11 -lm > /home/itp/gdk-pixbuf-0.11.0/gdk-pixbuf/.libs/libgnomecanvaspixbuf.a > /home/itp/imlib-1.9.10/gdk_imlib/.libs/libgdk_imlib.a -ljpeg -ltiff > -lungif -lpng -lz -lm -lgtk -lgdk -rdynamic -lgmodule -lglib -ldl -lXi > -lXext -lX11 -lm -luuid -lcrypt -lz -lutil -Wl,-Bdynamic Ditto. > Unfortunately, with libtool 1.4.x, I get this instead (after a much, > much longer time): > > gcc -g -O2 -Wall -Wunused -Wmissing-prototypes -Wmissing-declarations -o > installer installer-distro.o installer-page.o installer-page-install.o > installer-page-deps.o installer-page-finish.o installer-page-gdm.o > installer-page-method.o installer-page-mirror.o > installer-page-more-deps.o installer-page-proxy.o > installer-page-select.o installer-page-start.o installer-state-machine.o > installer-ui.o -Wl,-Bstatic -rdynamic -rdynamic -rdynamic -rdynamic > -Wl,-Bdynamic ../libredcarpet/src/libredcarpet.a ^ > ../libgnometransfer/src/libgnometransfer.a -L/usr/lib -L/usr/X11R6/lib > -L/usr/lib/lib /usr/lib/libgtkhtml.so /usr/lib/libgnomecanvaspixbuf.so > /usr/lib/libbonobo.so /usr/lib/liboaf.so /usr/lib/libORBitCosNaming.so > /usr/lib/libORBit.so /usr/lib/libIIOP.so /usr/lib/libORBitutil.so > /usr/lib/libbonobox.so -lz -lXi -lXext -lX11 -lm -ldl /usr/lib/libgal.so > /usr/lib/libgnomeprint.so /usr/lib/libgdk_pixbuf.so -ldl -lXi -lXext > -lX11 -lm -lz /usr/lib/libglade-gnome.so -lXi -lXext -lX11 -lm -ldl -lz > /usr/lib/libglade.so -ldl -lXi -lXext -lX11 -lm -lz /usr/lib/libxml.so > -lz -lz -lz /usr/lib/libgnomeui.so -lm -lm -ldl /usr/lib/libgdk_imlib.so > -ldl -lXi -lXext -lX11 -lm -ldl -lXi -lXext -lX11 -lm -lz -lm > /usr/lib/libart_lgpl.so -lSM -lICE -ldl -lXi -lXext -lX11 -lm -ldl -lXi > -lXext -lX11 -lm -ldl -lXi -lXext -lX11 /usr/lib/libgnome.so -lm -ldl > -lz -lm /usr/lib/libgnomesupport.so -lz -lm /usr/lib/libesd.so -lm -lm > /usr/lib/libaudiofile.so -lm -lm -lm -ldb1 -ldl /usr/lib/libgnet.so > -lresolv -lnsl -ldl -ldl > /home/itp/gdk-pixbuf-0.11.0//gdk-pixbuf/.libs/libgdk_pixbuf.a -ldl -lXi > -lXext -lX11 -lm -ldl -lXi -lXext -lX11 -lm -ldl -ldl -lXi -lXext -lX11 > -lm /home/itp/gdk-pixbuf-0.11.0//gdk-pixbuf/.libs/libgnomecanvaspixbuf.
Re: C++ exceptions fail, CVS libtool, gcc 3.0.1, Solaris 2.6
On Thu, Oct 04, 2001 at 09:06:35AM -0500, Bob Friesenhahn wrote: > On Thu, 4 Oct 2001 [EMAIL PROTECTED] wrote: > > > Has anyone else seen this problem? Is it due to libtool? > > > > Have you tried generating a small test program with exceptions to > > determine if GCC is the culprit? I cannot imagine anything inherent in > > libtool that would cause a problem. Are both versions of GCC built the > > same (i.e. with GNU as/ld)? > > Both versions use Solaris 'as' and Solaris 'ld'. Tests with simple > exceptions in a small stand-alone program show that exceptions do > work. A somewhat larger test program crashes in libstdc++ > (libsupc++/vec.cc:52) so perhaps this is a compiler library issue > unrelated to libtool. Sorry, cannot be of much additional help. You might want to try the 3.0 branch from CVS for GCC (3.0.2 will be released soon) or examine how libtool builds with 2.95 and 3.0 to determine if it does anything differently (I'm not aware that it does). If it is a bug in GCC 3.0.1, then it's a regression against 2.95.x and will most likely get high priority. -- albert chin ([EMAIL PROTECTED]) _______ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: C++ exceptions fail, CVS libtool, gcc 3.0.1, Solaris 2.6
On Wed, Oct 03, 2001 at 09:27:41PM -0500, Bob Friesenhahn wrote: > ImageMagick has been using CVS libtool. With gcc 2.95.2, C++ > exceptions work fine under Solaris 2.6. With gcc 3.0.1, C++ > exceptions are not being caught, causing the program to core dump. > > Has anyone else seen this problem? Is it due to libtool? Have you tried generating a small test program with exceptions to determine if GCC is the culprit? I cannot imagine anything inherent in libtool that would cause a problem. Are both versions of GCC built the same (i.e. with GNU as/ld)? -- albert chin ([EMAIL PROTECTED]) _______ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: _LT_AC_TAGCONFIG versus Cray sed
On Thu, Oct 04, 2001 at 09:05:18AM +1000, Kevin Ryde wrote: > On an sv1-cray-unicos10.0.0.X with the cvs libtool I noticed the > following error, > > configure: creating libtool > sed: 1: "s/[-_ABCDEFGHIJKLMNOPQR ...": RE error: [ ] imbalance or syntax >error > appending configuration tag "CXX" to libtool > > which I think might be from _LT_AC_TAGCONFIG, > > case `$echo "X$tagname" | $Xsed -e >'s/[[-_ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890,/]]//g'` in > > There was a discussion not so long ago about using "/" in a character > range when it's also the delimiter, but I forget what the theory was. If you replace the delimiter with a character other than "/", does the sed command work? -- albert chin ([EMAIL PROTECTED]) _______ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libltdl & 64-bit lint
On Sun, Sep 30, 2001 at 11:04:35AM -0500, Bob Friesenhahn wrote:
> Here is the output from Sun's 64-bit lint tool when run on libltdl
> current as of September 29. You will notice that there are a number of
> type down-conversions going on when the code is 64-bit. In order to
> be safe, these types should jive for both the ILP32 and LP64 data type
> models.
>
> (390) warning: suspicious comparison of unsigned with 0: op "<="
static lt_ptr
realloc (ptr, size)
lt_ptr ptr;
size_t size;
{
if (size <= 0)
Is size_t always unsigned?
> (1994) warning: cast from 64-bit integer to 32-bit integer
sprintf (filename, "%.*s/%s", (int) dirname_len, dirname, dlname);
According to sprintf(3) on a Linux box, when using %*, the field width
must be of type int.
> (2167) warning: assignment of 64-bit integer to 32-bit integer
intlenbase= LT_STRLEN (base_name);
Should be size_t as return type of strlen is size_t (at least on the
platforms I checked).
> (2184) warning: argument #3 is incompatible with prototype:
> prototype: pointer to unsigned long : "ltdl.c", line 2125
> argument : pointer to int
?
> (2191) warning: assignment of 64-bit integer to 32-bit integer
int lendir = LT_STRLEN (dir_name);
Should be size_t
> (2502) warning: assignment of 64-bit integer to 32-bit integer
int len = LT_STRLEN (str);
Should be size_t
> (2643) warning: comparing 32-bit integer with 64-bit integer
for (i = 0; i < ext - base_name; ++i)
ext and base_name are char *. Should we make i a size_t?
> (2718) warning: passing 64-bit integer arg, expecting 32-bit integer: fgets(arg 2)
if (!fgets (line, line_len, file))
line_len is size_t. fgets expects second argument to be int.
> (2728) warning: passing 64-bit integer arg, expecting 32-bit integer: fgets(arg 2)
Ditto.
> (2960) warning: assignment of 64-bit integer to 32-bit integer
len = LT_STRLEN (filename);
len should be size_t
> (3235) warning: argument #4 is incompatible with prototype:
> prototype: pointer to void : "ltdl.c", line 2159
> argument : pointer to function(pointer to const char, pointer to void)
>returning int
> (3241) warning: argument #4 is incompatible with prototype:
> prototype: pointer to void : "ltdl.c", line 2159
> argument : pointer to function(pointer to const char, pointer to void)
>returning int
> (3245) warning: argument #4 is incompatible with prototype:
> prototype: pointer to void : "ltdl.c", line 2159
> argument : pointer to function(pointer to const char, pointer to void)
>returning int
> (3252) warning: argument #4 is incompatible with prototype:
> prototype: pointer to void : "ltdl.c", line 2159
> argument : pointer to function(pointer to const char, pointer to void)
>returning int
> (3259) warning: argument #4 is incompatible with prototype:
> prototype: pointer to void : "ltdl.c", line 2159
> argument : pointer to function(pointer to const char, pointer to void)
>returning int
We've already discussed this. No clear solution.
> (3358) warning: assignment of 64-bit integer to 32-bit integer
lensym = LT_STRLEN (symbol) + LT_STRLEN (handle->loader->sym_prefix)
+ LT_STRLEN (handle->info.name);
lensym should be size_t
--
albert chin ([EMAIL PROTECTED])
-- snip snip
2001-09-30 Albert Chin-A-Young <[EMAIL PROTECTED]>
* ltdl.c: change some types to size_t from int because
strlen() returns size_t. argz_len changed to size_t in
foreach_dirinpath() because argzize_path() takes 3rd
argument as size_t, not int. Based on lint run from
Bob Friesenhahn <[EMAIL PROTECTED]>.
Index: libltdl/ltdl.c
===
RCS file: /cvsroot/libtool/libtool/libltdl/ltdl.c,v
retrieving revision 1.159
diff -u -3 -p -r1.159 ltdl.c
--- libltdl/ltdl.c 2001/09/21 17:38:39 1.159
+++ libltdl/ltdl.c 2001/10/01 03:59:41
@@ -2164,8 +2164,8 @@ foreach_dirinpath (search_path, base_nam
{
int result = 0;
int filenamesize = 0;
- int lenbase= LT_STRLEN (base_name);
- int argz_len= 0;
+ size_t lenbase = LT_STRLEN (base_name);
+ size_t argz_len = 0;
char *argz = 0;
char *filename = 0;
char *canonical = 0;
@@ -2188,7 +2188,7 @@ foreach_dirinpath (search_path, base_nam
char *dir_name = 0;
while ((dir_name = argz_next (argz, argz_len, dir_name)))
{
- int lendir = LT_STRLEN (dir_name);
+ size_t lendir = LT_STRLEN (dir_name);
if (lendir +1 +lenbase >= filenamesize)
{
@@ -2499,7 +2499,7 @@ trim (dest, str)
/* remove the le
Re: libltdl crashes under Solaris LP64 64-bit model
On Sat, Sep 29, 2001 at 10:56:13PM -0500, Bob Friesenhahn wrote: > The problem with libltdl in the Solaris LP64 64-bit model is due to a > mismatch with sizes. argzize_path requires size_t. Under 64-bits > size_t is 8 bytes and int is 4 bytes. Here is a patch which should > resolve the problem. Then why not make argz_len size_t? Nothing else in foreach_dirinpath uses argz_len so it would seem more correct. > Index: ltdl.c > === > RCS file: /home/cvs/libtool/libltdl/ltdl.c,v > retrieving revision 1.159 > diff -u -r1.159 ltdl.c > --- ltdl.c2001/09/21 17:38:39 1.159 > +++ ltdl.c2001/09/30 03:53:19 > @@ -2165,7 +2165,7 @@ >int result = 0; >int filenamesize = 0; >int lenbase= LT_STRLEN (base_name); > - intargz_len= 0; > + long argz_len= 0; >char *argz = 0; >char *filename = 0; >char *canonical= 0; > > > > ___ > Libtool mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/libtool -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Different linkers at different times?
On Fri, Sep 21, 2001 at 02:57:21PM -0500, Kenneth Pronovici wrote: > I'm cross-posting this to the autoconf and libtool lists, because I'm not > sure whose "jurisdiction" this is. > > I accidentally found this while trying to compile libxml2-2.4.5 under Solaris. > I say "accidentally" because was compiling without /usr/local/lib in my > $LD_LIBRARY_PATH, which was probably silly. However, I think this might > still be a legitimate concern. > > The problem is with the AC_CHECK_LIB(z, gzread) call in libxml's configure.in. > What happens is that the configure script uses gcc and finds -lz successfully, > and everything moves on as if libz is available. However, libtool uses > /usr/ccs/bin/ld when attempting to link the library, and is unable to find > -lz at that point. > > I guess this is because gcc always looks in /usr/local/lib by default and the > Solaris build tools don't. I can work around this by specifying the exact > location of zlib (--with-zlib=/usr/local) or by forcing use of the Solaris > C compiler (export CC="/usr/ccs/bin/cc")... but it seems like it's not good > that I can get myself into a situation where the configure script will succeed > but the build will always fail. > > I've rebuilt the configure script with autoconf 2.52, and I still see the > problem. It looks like libxml was developed with libtool 1.4. > > Is this worth worrying about, or does this fall into the "well, the silly > user [me] should set up $LD_LIBRARY_PATH properly" category? Only plausible solution is setting LDFLAGS before ./configure or using --with-zlib. BTW, libxml is not the only app where you'll run into this problem. You should also look into LD_RUN_PATH. We build libxml: LDFLAGS="-R[zlib path]/lib" ./configure --with-zlib=[zlib path] -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: HEAD and different C, C++ compilers
On Fri, Sep 21, 2001 at 12:33:22AM -0500, [EMAIL PROTECTED] wrote:
> Does HEAD support *different* a different C and C++ compiler (e.g.
> native vendor C and GNU C++)?
Well, HEAD passes all tests with AIX 4.3.2 and CC=xlc, CXX=g++. HP-UX
10.20 does not. Tru64 UNIX 4.0D with CC=cc, CXX=g++ works too.
Ok. This patch works. Basically, switch $GXX and $GCC. I've also
included some indentation fixes. Most tests on HP-UX 10.20 pass (well,
the same tests that passed before the patch pass with the patch):
CC=cc CXX=g++
CC=gcc CXX=g++
And, on HP-UX 11.00, all tests pass with:
CC=cc CXX=aCC
CC=cc CXX=g++
CC=gcc CXX=g++
--
albert chin ([EMAIL PROTECTED])
-- snip snip
2001-09-21 Albert Chin-A-Young <[EMAIL PROTECTED]>
* libtool.m4: When setting archive_cmds for CC, don't
test for $GXX but for $GCC on HP-UX. Indentation fixes.
Index: libtool.m4
===
RCS file: /cvsroot/libtool/libtool/libtool.m4,v
retrieving revision 1.233
diff -u -3 -p -r1.233 libtool.m4
--- libtool.m4 2001/09/21 03:06:40 1.233
+++ libtool.m4 2001/09/21 06:32:49
@@ -2558,8 +2558,9 @@ case $host_os in
else
_LT_AC_TAGVAR(hardcode_direct, $1)=yes
fi
-_LT_AC_TAGVAR(hardcode_minus_L, $1)=yes # Not in the search PATH, but as the
default
-# location of the library.
+_LT_AC_TAGVAR(hardcode_minus_L, $1)=yes # Not in the search PATH,
+ # but as the default
+ # location of the library.
case $cc_basename in
CC)
@@ -2569,9 +2570,9 @@ case $host_os in
aCC)
case $host_os in
hpux9*)
-_LT_AC_TAGVAR(archive_cmds, $1)='$rm $output_objdir/$soname~$CC -b
${wl}+b ${wl}$install_libdir -o $output_objdir/$soname $predep_objects $libobjs
$deplibs $postdep_objects $compiler_flags~test $output_objdir/$soname = $lib || mv
$output_objdir/$soname $lib'
+ _LT_AC_TAGVAR(archive_cmds, $1)='$rm $output_objdir/$soname~$CC -b ${wl}+b
+${wl}$install_libdir -o $output_objdir/$soname $predep_objects $libobjs $deplibs
+$postdep_objects $compiler_flags~test $output_objdir/$soname = $lib || mv
+$output_objdir/$soname $lib'
;;
- *)
+*)
if test "$host_cpu" = ia64; then
_LT_AC_TAGVAR(archive_cmds, $1)='$LD -b +h $soname -o $lib $linker_flags
$libobjs $deplibs'
else
@@ -2594,15 +2595,15 @@ case $host_os in
if test $with_gnu_ld = no; then
case $host_os in
hpux9*)
-_LT_AC_TAGVAR(archive_cmds, $1)='$rm $output_objdir/$soname~$CC
-shared -nostdlib -fPIC ${wl}+b ${wl}$install_libdir -o $output_objdir/$soname
$predep_objects $libobjs $deplibs $postdep_objects $compiler_flags~test
$output_objdir/$soname = $lib || mv $output_objdir/$soname $lib'
-;;
- *)
-if test "$host_cpu" = ia64; then
- _LT_AC_TAGVAR(archive_cmds, $1)='$LD -b +h $soname -o $lib
$linker_flags $libobjs $deplibs'
-else
- _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib -fPIC
${wl}+h ${wl}$soname ${wl}+b ${wl}$install_libdir -o $lib $predep_objects $libobjs
$deplibs $postdep_objects $compiler_flags'
-fi
-;;
+ _LT_AC_TAGVAR(archive_cmds, $1)='$rm $output_objdir/$soname~$CC -shared
+-nostdlib -fPIC ${wl}+b ${wl}$install_libdir -o $output_objdir/$soname
+$predep_objects $libobjs $deplibs $postdep_objects $compiler_flags~test
+$output_objdir/$soname = $lib || mv $output_objdir/$soname $lib'
+ ;;
+*)
+ if test "$host_cpu" = ia64; then
+_LT_AC_TAGVAR(archive_cmds, $1)='$LD -b +h $soname -o $lib
+$linker_flags $libobjs $deplibs'
+ else
+_LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib -fPIC ${wl}+h
+${wl}$soname ${wl}+b ${wl}$install_libdir -o $lib $predep_objects $libobjs $deplibs
+$postdep_objects $compiler_flags'
+ fi
+ ;;
esac
fi
else
@@ -4721,12 +4722,12 @@ EOF
;;
hpux9* | hpux10* | hpux11*)
- if test "$GXX" = yes; then
+ if test "$GCC" = yes; then
case $host_os in
hpux9*)
_LT_AC_TAGVAR(archive_cmds, $1)='$rm $output_objdir/$soname~$CC -shared
-fPIC ${wl}+b ${wl}$install_libdir -o $output_objdir/$soname $libobjs $deplibs
$compiler_flags~test $output_objdir/$soname = $lib || mv $output_objdir/$soname $lib'
;;
-*)
+ *)
if test "$host_cpu" = ia64; then
_LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared ${wl}+h ${wl}$soname -o
$lib $libobjs $deplibs $compiler_flags'
else
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: AC_LTDL_DLLIB in HEAD/ltdl.m4
On Wed, Sep 19, 2001 at 07:58:14PM -0500, [EMAIL PROTECTED] wrote: > We've modified libtool.m4 to perfer shl_load on HP-UX *even* if dlopen > is available. The rationale for this is because dlopen() requires a > patch which all users might not have (we're running into this problem > now). Unfortunately, ltdl calls AC_LTDL_DLLIB which searches for > *every* possible loader and defines them all in libtldl/ltdl.c. Why? > Why not just pick the first we find? The current behaviour uses > shl_load and dlopen on HP-UX by default. I'd like to get this changed > to shl_load only. Patch below. Tested on HP-UX 10.20 and 11.00. -- albert chin ([EMAIL PROTECTED]) -- snip snip 2001-09-21 Albert Chin-A-Young <[EMAIL PROTECTED]> * ltdl.m4: Even though HP-UX 10.20 and 11.00 support shl_load *and* dlopen, dlopen works correctly only with a patch. Because we want to avoid the situation where we build on a system with the patch but deploy on a system without, use shl_load exclusively if found. Index: ltdl.m4 =========== RCS file: /cvsroot/libtool/libtool/ltdl.m4,v retrieving revision 1.36 diff -u -3 -p -r1.36 ltdl.m4 --- ltdl.m4 2001/09/13 19:47:02 1.36 +++ ltdl.m4 2001/09/21 06:32:49 @@ -250,39 +250,37 @@ AC_DEFUN([AC_LTDL_DLLIB], [LIBADD_DL= AC_SUBST(LIBADD_DL) AC_LANG_PUSH([C]) -AC_CHECK_LIB([dl], [dlopen], - [AC_DEFINE([HAVE_LIBDL], [1], - [Define if you have the libdl library or equivalent.]) - LIBADD_DL="-ldl"], - [AC_TRY_LINK([#if HAVE_DLFCN_H -# include -#endif -], -[dlopen(0, 0);], -[AC_DEFINE(HAVE_LIBDL, 1, - [Define if you have the libdl library or equivalent.])], -[AC_CHECK_LIB(svld, dlopen, - [AC_DEFINE(HAVE_LIBDL, 1, -[Define if you have the libdl library or equivalent.]) - LIBADD_DL="-lsvld" - ]) -]) - ]) - AC_CHECK_FUNC(shl_load, [AC_DEFINE([HAVE_SHL_LOAD], [1], [Define if you have the shl_load function.])], [AC_CHECK_LIB([dld], [shl_load], [AC_DEFINE([HAVE_SHL_LOAD], [1], [Define if you have the shl_load function.]) -LIBADD_DL="$LIBADD_DL -ldld" +LIBADD_DL="$LIBADD_DL -ldld"], +[AC_CHECK_LIB([dl], [dlopen], + [AC_DEFINE([HAVE_LIBDL], [1], + [Define if you have the libdl library or equivalent.]) + LIBADD_DL="-ldl"], + [AC_TRY_LINK([#if HAVE_DLFCN_H +# include +#endif +], +[dlopen(0, 0);], +[AC_DEFINE([HAVE_LIBDL], [1], + [Define if you have the libdl library or equivalent.])], +[AC_CHECK_LIB([svld], [dlopen], + [AC_DEFINE([HAVE_LIBDL], [1], +[Define if you have the libdl library or equivalent.]) + LIBADD_DL="-lsvld"], + [AC_CHECK_LIB([dld], [dld_link], +[AC_DEFINE([HAVE_DLD], [1], + [Define if you have the GNU dld library.]) +test x"$ac_cv_lib_dld_shl_load" = xyes || LIBADD_DL="$LIBADD_DL -ldld" +]) + ]) +]) + ]) ]) - ]) - -AC_CHECK_LIB([dld], [dld_link], - [AC_DEFINE([HAVE_DLD], [1], -[Define if you have the GNU dld library.]) - test x"$ac_cv_lib_dld_shl_load" = xyes || LIBADD_DL="$LIBADD_DL -ldld" ]) if test x"$ac_cv_func_dlopen" = xyes || test x"$ac_cv_lib_dl_dlopen" = xyes ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool does not preserve -xarch=v9
On Thu, Sep 20, 2001 at 09:38:29PM -0500, Bob Friesenhahn wrote: > 64-bit compilation under Solaris & Sun's compiler requires that the > argument '-xarch=v9' be provided when compiling C++ objects. > Unfortunately libtool (1.4a (1.641.2.259 2001/06/04 19:32:47)) is > discarding this argument (which was passed via LDFLAGS to configure) > so objects are built as 32-bit objects instead. Is a fix for this > available? Does Sun ld(1) even support -xarch? I just checked the manpage on a Solaris 8/SPARC 64-bit system and didn't see mention of it. I also tried linking a library using ld(1) with -xarch=v9 as an argument and got an error. Anyway, *without* having LDFLAGS="-xarch=v9", I built HEAD and ran nm on libltdl/.libs/libltdl.so.3.1.0: $ nm libltdl/.libs/libltdl.so.3.1.0 libltdl.so.3.1.0: ELF 64-bit MSB dynamic lib SPARCV9 Version ... -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
HEAD and different C, C++ compilers
Does HEAD support *different* a different C and C++ compiler (e.g. native vendor C and GNU C++)? -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: HEAD and HP-UX C++ compiler
On Wed, Sep 19, 2001 at 10:03:12PM -0500, [EMAIL PROTECTED] wrote:
> From HEAD:
> ...
> checking how to run the C++ preprocessor... aCC -E
> checking the maximum length of command line arguments... 393217
> checking command to parse /usr/ccs/bin/nm -p output from cc object... failed
> ...
>
> Problem is, with HP C++, A.03.30 (A.03.31 is the latest):
>
> $ aCC -o conftest conftest.cc conftstm.o
> Error 352: "conftest.cc", line 23 # Cannot take the address of main.
> {"main", (lt_ptr_t) &main},
>
> $ cat conftest.cc
> #ifdef __cplusplus
> extern "C" {
> #endif
>
> extern char nm_test_var;
> extern int main();
> extern int nm_test_func();
> #if defined (__STDC__) && __STDC__
> # define lt_ptr_t void *
> #else
> # define lt_ptr_t char *
> # define const
> #endif
>
> /* The mapping between symbol names and symbols. */
> const struct {
> const char *name;
> lt_ptr_t address;
> }
> lt_preloaded_symbols[] =
> {
> {"nm_test_var", (lt_ptr_t) &nm_test_var},
> {"main", (lt_ptr_t) &main},
> {"nm_test_func", (lt_ptr_t) &nm_test_func},
> {0, (lt_ptr_t) 0}
> };
>
> #ifdef __cplusplus
> }
> #endif
>
> So, do we ignore main on HP-UX with aCC? BTW, G++ 3.0.1 failes too.
> Solaris C++ (5.3) works fine.
Here's a patch for this. Note that I tried, as a solution, changing
the default lt_cv_sys_global_symbol_to_cdecl to:
sed -n -e 's/^T .* \(.*\)$/extern int \1();/p' -e \
's/^$symcode* .* \(.*\)$/extern char \1;/p'
as we should mark functions with a (). This worked on Solaris, HP-UX,
Tru64 UNIX, and IRIX but not on AIX. Given the following program:
void foo(){int a=1;}
int un_test;
int in_test=1;
AIX xlc does:
$ xlc -c a.c
$ nm -Bg a.o
0 T .foo
44 D foo
56 D in_test
60 B un_test
If we could have the sed magic change this to (on output):
T foo foo
D in_test in_test
D un_test un_test
then we'd be set but that requires us to keep state and I can't see a
quick hack to do this.
--
albert chin ([EMAIL PROTECTED])
-- snip snip
2001-09-20 Albert Chin-A-Young <[EMAIL PROTECTED]>
* libtool.m4: Don't include main() when testing for
command to parse $NM output because some C++ compilers
don't allow you to take the address of main (e.g. HP-UX aCC).
Index: libtool.m4
===
RCS file: /cvsroot/libtool/libtool/libtool.m4,v
retrieving revision 1.231
diff -u -3 -p -r1.231 libtool.m4
--- libtool.m4 2001/09/11 00:22:48 1.231
+++ libtool.m4 2001/09/20 13:38:10
@@ -3741,7 +3741,7 @@ extern "C" {
EOF
# Now generate the symbol file.
- eval "$lt_cv_sys_global_symbol_to_cdecl"' < "$nlist" >> conftest.$ac_ext'
+ eval "$lt_cv_sys_global_symbol_to_cdecl"' < "$nlist" | grep -v main >>
+conftest.$ac_ext'
cat <> conftest.$ac_ext
#if defined (__STDC__) && __STDC__
@@ -3759,7 +3759,7 @@ const struct {
lt_preloaded_symbols[[]] =
{
EOF
- sed "s/^$symcode$symcode* \(.*\) \(.*\)$/ {\"\2\", (lt_ptr_t) \&\2},/" <
"$nlist" >> conftest.$ac_ext
+ sed "s/^$symcode$symcode* \(.*\) \(.*\)$/ {\"\2\", (lt_ptr_t) \&\2},/" <
+"$nlist" | grep -v main >> conftest.$ac_ext
cat <<\EOF >> conftest.$ac_ext
{0, (lt_ptr_t) 0}
};
@@ -4721,7 +4721,7 @@ EOF
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
use of __STDC__ in libtool.m4 on HEAD
>From libtool.m4 in HEAD branch: #if defined (__STDC__) && __STDC__ # define lt_ptr_t void * #else # define lt_ptr_t char * # define const #endif Why? Some C compilers define __STDC__ but don't define it to 1. How about: #ifdef __STDC__ -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
HEAD and HP-UX C++ compiler
>From HEAD:
...
checking how to run the C++ preprocessor... aCC -E
checking the maximum length of command line arguments... 393217
checking command to parse /usr/ccs/bin/nm -p output from cc object... failed
...
Problem is, with HP C++, A.03.30 (A.03.31 is the latest):
$ aCC -o conftest conftest.cc conftstm.o
Error 352: "conftest.cc", line 23 # Cannot take the address of main.
{"main", (lt_ptr_t) &main},
$ cat conftest.cc
#ifdef __cplusplus
extern "C" {
#endif
extern char nm_test_var;
extern int main();
extern int nm_test_func();
#if defined (__STDC__) && __STDC__
# define lt_ptr_t void *
#else
# define lt_ptr_t char *
# define const
#endif
/* The mapping between symbol names and symbols. */
const struct {
const char *name;
lt_ptr_t address;
}
lt_preloaded_symbols[] =
{
{"nm_test_var", (lt_ptr_t) &nm_test_var},
{"main", (lt_ptr_t) &main},
{"nm_test_func", (lt_ptr_t) &nm_test_func},
{0, (lt_ptr_t) 0}
};
#ifdef __cplusplus
}
#endif
So, do we ignore main on HP-UX with aCC? BTW, G++ 3.0.1 failes too.
Solaris C++ (5.3) works fine.
--
albert chin ([EMAIL PROTECTED])
_______
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
AC_LTDL_DLLIB in HEAD/ltdl.m4
We've modified libtool.m4 to perfer shl_load on HP-UX *even* if dlopen is available. The rationale for this is because dlopen() requires a patch which all users might not have (we're running into this problem now). Unfortunately, ltdl calls AC_LTDL_DLLIB which searches for *every* possible loader and defines them all in libtldl/ltdl.c. Why? Why not just pick the first we find? The current behaviour uses shl_load and dlopen on HP-UX by default. I'd like to get this changed to shl_load only. -- albert chin ([EMAIL PROTECTED]) _______ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool RFE
On Tue, Sep 11, 2001 at 04:26:16PM -0500, [EMAIL PROTECTED] wrote: > > From: [EMAIL PROTECTED] > > To: [EMAIL PROTECTED] > > Subject: Re: libtool RFE > > Date: Tue, 11 Sep 2001 16:05:17 -0500 > > > Are you > > aware of any OS that supports 32 and 64-bit libraries in the same > > directory? I know Solaris and AIX don't do this. > > The libraries that ship as part of AIX (on PowerPC) are actually archives, > and most of them do indeed contain 32 and 64 bit objects. Thanks. I meant IRIX. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool RFE
On Tue, Sep 11, 2001 at 12:14:42PM -0700, Bruce Korb wrote: > It seems I need to be able to build both 32 and 64 bit > libraries. Since nobody seems to have anything to do, > maybe we can add this to our copious spare time activities: > > Construction of multiple output libraries based on more > than just the -PIC compiler flags. viz., the > ``-xarch=v9 -xregs=no%appl,no%float'' variation on Sun. > > Since I have not taken a serious look at how you manage > the build-with-PIC vs. build-without-PIC stuff, how hard > would anyone guess it might be to put together a list > of compile options and associated target library names, > then going through all the compiles to build libraries > one after the other? Can I do it over lunch? ;-) > Probably not. :-( What? Are you talking about building *both* 32 and 64-bit libraries at once. How do you handle naming the library? What directory do they get installed in. For now, I say no. Build the 32-bit libs and install, then the 64-bit libs and install (into separate locations). Are you aware of any OS that supports 32 and 64-bit libraries in the same directory? I know Solaris and AIX don't do this. And, if you're going to *link* a program against the library you've created, do you then generate both 32 and 64-bit versions as well? -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool broken in kdebase 2.2.0
On Mon, Sep 10, 2001 at 09:46:15PM +0100, Gary V. Vaughan wrote: > I wish I had a better understanding of linkers and the like :-( Title: Linkers and Loaders ISBN: 1558604960 Author: John R. Levine Date: 1999 -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: question about AC_LTDL_SYS_DLOPEN_DEPLIBS
On Tue, Jul 17, 2001 at 12:33:28PM -0500, Robert Boehne wrote: > From earlier discussions, it was noted that > libltdl_cv_sys_dlopen_deplibs=yes > actually not only referrs to dlopen() calls, but their equivalents > on other OS's like HPUX. Why don't we do this: set > ibltdl_cv_sys_dlopen_deplibs > based on host in configury, then add a test case that uses libltdl to > check if libltdl_cv_sys_dlopen_deplibs is set properly? > That way those platforms that aren't set properly will fail the test > case, and we will be notified we need to change ltdl.m4 to fix it. > This doesn't handle the cases such as Tru64 5.1 patched vs not patched > but it gets us most of the way there. N'cest pas? Actually, why not set libltdl_cv_sys_dlopen_deplibs=yes regardless of host configury and then if ltdl cannot load the library, set libltdl_cv_sys_dlopen_deplibs=unknown? I thought about this but, having not looked too much into ltdl, don't know how difficult it would be. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: question about AC_LTDL_SYS_DLOPEN_DEPLIBS
On Tue, Jul 17, 2001 at 11:36:11AM -0500, Robert Boehne wrote:
> [EMAIL PROTECTED] wrote:
> >
> > On Tue, Jul 17, 2001 at 10:10:49AM -0500, Robert Boehne wrote:
> > > "Gary V. Vaughan" wrote:
> > > >
> > > > On Monday 16 July 2001 4:10 pm, Robert Boehne wrote:
> > > > > Here is the test case, if someone wants to libtoolize it, we
> > > > > could add it to the macro.
> > > >
> > > > Seconded! I would happily accept a patch to perform the test *instead* of
> > > > listing values for only hosts triplets that have been researched...
> > > >
> > > > Cheers,
> > > > Gary.
> > >
> > > If we use the test *instead* of looking at the host we would miss the
> > > case for Tru64 4-5.1, which passes the test but doesn't search the
> > > library RPATH, but perhaps we could limit it to that case only.
> >
> > Then how about augmenting the patch to catch this case? This is
> > actually important for people how have Tru64 UNIX with patch kit < #2
> > where such an augmented test would fail and patch kit >= #2 where the
> > augmented test should succeed.
> >
> > --
> > albert chin ([EMAIL PROTECTED])
>
> That's a great idea, if we don't want to set dlopen_deplibs to "yes"
> in that case anyway that is what we should test for.
> I'm having some trouble creating this test case though, how can
> I use ltdl in a program that is used to create libtool?
Just so I'm on the same page, this is to autodetect
$libltdl_cv_sys_dlopen_deplibs correct? If so, why do you want to use
ltdl at all? Isn't it enough to write the following test programs
during the run of ltdl.m4:
('t1') dlopen test program 't2'
('t2') dlopen'ed by 't1' and depends on library 't3'
('t3') library depending on 't4'
('t4') dummy library
and then run t1. If you fail, libltdl_cv_sys_dlopen_deplibs=unknown.
If you succeed, libltdl_cv_sys_dlopen_deplibs=yes.
The purpose of 't2' is to detect if dlopen loads dependency libraries
and the purpose of 't3' is to detect if dlopen honours RPATH in a
library.
BTW, this probably isn't so trivial because you'd need to embed the
runtime path into programs 't2' and 't3'. You definitely don't want to
set LD_LIBRARY_PATH. Can you use the generated libtool program during
ltdl.m4?
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: question about AC_LTDL_SYS_DLOPEN_DEPLIBS
On Tue, Jul 17, 2001 at 10:10:49AM -0500, Robert Boehne wrote: > "Gary V. Vaughan" wrote: > > > > On Monday 16 July 2001 4:10 pm, Robert Boehne wrote: > > > Here is the test case, if someone wants to libtoolize it, we > > > could add it to the macro. > > > > Seconded! I would happily accept a patch to perform the test *instead* of > > listing values for only hosts triplets that have been researched... > > > > Cheers, > > Gary. > > If we use the test *instead* of looking at the host we would miss the > case for Tru64 4-5.1, which passes the test but doesn't search the > library RPATH, but perhaps we could limit it to that case only. Then how about augmenting the patch to catch this case? This is actually important for people how have Tru64 UNIX with patch kit < #2 where such an augmented test would fail and patch kit >= #2 where the augmented test should succeed. -- albert chin ([EMAIL PROTECTED]) _______ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: question about AC_LTDL_SYS_DLOPEN_DEPLIBS
On Mon, Jul 16, 2001 at 04:50:54PM -0500, Tim Mooney wrote: > In regard to: Re: question about AC_LTDL_SYS_DLOPEN_DEPLIBS, Gary V: > > >On Monday 16 July 2001 4:10 pm, Robert Boehne wrote: > >> Here is the test case, if someone wants to libtoolize it, we > >> could add it to the macro. > > > >Seconded! I would happily accept a patch to perform the test *instead* of > >listing values for only hosts triplets that have been researched... > > :-) For now, what do you think of the updated patch, below? > > 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 > > > diff -ur libtool-1.4b.orig/ltdl.m4 libtool-1.4b/ltdl.m4 > --- libtool-1.4b.orig/ltdl.m4 Thu Jul 5 18:10:26 2001 > +++ libtool-1.4b/ltdl.m4 Mon Jul 16 16:06:34 2001 > @@ -70,13 +70,57 @@ > [AC_REQUIRE([AC_CANONICAL_HOST]) > AC_CACHE_CHECK([whether deplibs are loaded by dlopen], > libltdl_cv_sys_dlopen_deplibs, [dnl > - # PORTME does your system automatically load deplibs for dlopen()? > + # PORTME does your system automatically load deplibs for dlopen() > + # or its logical equivalent (e.g. shl_load for HP-UX < 11) > + # For now, we just catch OSes we know something about -- in the > + # future, we'll try test this programmatically. > libltdl_cv_sys_dlopen_deplibs=unknown > case "$host_os" in > + aix3*|aix4.1.*|aix4.2.*) > + # Unknown whether this is true for these versions of AIX, but > + # we want this `case' here to explicitly catch those versions. > + libltdl_cv_sys_dlopen_deplibs=unknown > + ;; > + aix4*) > + # Unknown whether this is true for aix5, but is true for aix >= 4.3.* > + libltdl_cv_sys_dlopen_deplibs=yes > + ;; > + irix[12345]*|irix6.[01234]*) > + # Catch all versions of IRIX before 6.5, and indicate that we don't > + # know how it worked for any of those versions. > + libltdl_cv_sys_dlopen_deplibs=unknown Works fine for IRIX 6.2. Therefore, I'd presume it works for 6.3 and 6.4 as well. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: question about AC_LTDL_SYS_DLOPEN_DEPLIBS
On Mon, Jul 16, 2001 at 02:21:48PM -0500, Tim Mooney wrote: > An earlier question I asked still remains, though: what about platforms > that have a different API for dynamic loading, e.g. HP-UX < 11.x? Does > this cache value (or these cache values) apply there as well, even though > the system uses shl_load instead of dlopen()? I believe so. I think the use of "dlopen" does not necessarily imply the function by which dynamic loading occurs. -- albert chin ([EMAIL PROTECTED]) _______ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: question about AC_LTDL_SYS_DLOPEN_DEPLIBS
On Fri, Jul 13, 2001 at 12:30:14AM +0100, Gary V. Vaughan wrote: > On Thursday 12 July 2001 8:12 pm, Tim Mooney wrote: > > I'm not 100% sure I know what > > > > whether deplibs are loaded by dlopen > > > > means. Does it mean: > > > > If you explicitly load a shared object via dlopen(), are any shared > > objects that it depends on loaded for you automatically? > > Yes, exactly that. And if libltdl_cv_sys_dlopen_deplibs=yes is true for a platform but the platform loader does not honor RPATH in shared libraries and a shared library being dlopen'ed has a dependency on another library whose path is not in the application RPATH, should libltdl_cv_sys_dlopen_deplibs still be "yes" for this platform? -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: question about AC_LTDL_SYS_DLOPEN_DEPLIBS
On Mon, Jul 16, 2001 at 01:06:10PM -0500, Tim Mooney wrote: > In regard to: Re: question about AC_LTDL_SYS_DLOPEN_DEPLIBS,...: > > >> The first paragraph of the dlopen() man page on Tru64 UNIX 5.1 (and 4.0f) > >> says that > >> > >> The dlopen function attempts to load the specified file in the address space > >> of the process, resolving symbols as appropriate. Any libraries that the > >> specified file depends upon are also loaded. > > > >The loader on Tru64 UNIX 5.0A and below will load not load dependent > >libraries for a shared library. > > I believe that's incorrect, and it's certainly contrary to how things are > documented to act. You are correct. I incorrectly worded what I meant. -- albert chin ([EMAIL PROTECTED]) _______ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: question about AC_LTDL_SYS_DLOPEN_DEPLIBS
On Mon, Jul 16, 2001 at 11:13:28AM -0500, Robert Boehne wrote: > It appears to work in my test case under Tru64 4.0f, and according > to Tim's snippet of the documentation. Is there a problem with my > test case? Perhaps I'm not testing this correctly, or perhaps you > are referring to a slightly different situation. In this case a > library is dlopen'ed, and this library is dependent on another > shared library (also in LD_LIBRARY_PATH). The way I read this is > that if the dlopen'ed library is built by linking with the dependent > lib, the executable doesn't need to be. What happens if LD_LIBRARY_PATH is not set? IRIX, AIX, HP-UX, and Solaris honor RPATH for libraries. Tru64 UNIX does not (5.0A and below). Maybe I'm unclear on the question. Tru64 UNIX *will* load deplibs. However, if the path to the deplib is in the RPATH of the shared library being dlopen'ed and the path is either not in LD_LIBRARY_PATH or the RPATH of the application doing the dlopen, then the shared library will not be loaded in. IRIX, AIX, HP-UX, and Solaris will, however, load the shared library as they grok RPATH in shared libraries. > Rob > > [EMAIL PROTECTED] wrote: > > > > On Fri, Jul 13, 2001 at 04:09:28PM -0500, Tim Mooney wrote: > > > In regard to: Re: question about AC_LTDL_SYS_DLOPEN_DEPLIBS, Gary V: > > > > > > >On Thursday 12 July 2001 8:12 pm, Tim Mooney wrote: > > > >> I'm not 100% sure I know what > > > >> > > > >>whether deplibs are loaded by dlopen > > > >> > > > >> means. Does it mean: > > > >> > > > >>If you explicitly load a shared object via dlopen(), are any shared > > > >>objects that it depends on loaded for you automatically? > > > > > > > >Yes, exactly that. > > > > > > Does this macro apply at all to platforms that have some other mechanism > > > of dynamically loading a shared object (e.g. HP-UX 10.x and earlier)? > > > > > > The first paragraph of the dlopen() man page on Tru64 UNIX 5.1 (and 4.0f) > > > says that > > > > > > The dlopen function attempts to load the specified file in the address space > > > of the process, resolving symbols as appropriate. Any libraries that the > > > specified file depends upon are also loaded. > > > > The loader on Tru64 UNIX 5.0A and below will load not load dependent > > libraries for a shared library. RPATH is honored for executables but > > not for libraries. You'll need a test program to determine if this has > > been "fixed" under 5.1 but I doubt it. > > > > -- > > albert chin ([EMAIL PROTECTED]) > > > > ___ > > Libtool mailing list > > [EMAIL PROTECTED] > > http://mail.gnu.org/mailman/listinfo/libtool > > -- > Robert Boehne Software Engineer > Ricardo Software Chicago Technical Center > TEL: (630)789-0003 x. 238 > FAX: (630)789-0127 > email: [EMAIL PROTECTED] -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: question about AC_LTDL_SYS_DLOPEN_DEPLIBS
On Fri, Jul 13, 2001 at 04:09:28PM -0500, Tim Mooney wrote: > In regard to: Re: question about AC_LTDL_SYS_DLOPEN_DEPLIBS, Gary V: > > >On Thursday 12 July 2001 8:12 pm, Tim Mooney wrote: > >> I'm not 100% sure I know what > >> > >>whether deplibs are loaded by dlopen > >> > >> means. Does it mean: > >> > >>If you explicitly load a shared object via dlopen(), are any shared > >>objects that it depends on loaded for you automatically? > > > >Yes, exactly that. > > Does this macro apply at all to platforms that have some other mechanism > of dynamically loading a shared object (e.g. HP-UX 10.x and earlier)? > > The first paragraph of the dlopen() man page on Tru64 UNIX 5.1 (and 4.0f) > says that > > The dlopen function attempts to load the specified file in the address space > of the process, resolving symbols as appropriate. Any libraries that the > specified file depends upon are also loaded. The loader on Tru64 UNIX 5.0A and below will load not load dependent libraries for a shared library. RPATH is honored for executables but not for libraries. You'll need a test program to determine if this has been "fixed" under 5.1 but I doubt it. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool: not configured to build any kind of library
On Wed, Jun 27, 2001 at 12:43:18PM +0200, Gabriele Bartolini wrote: > I am trying to port my application, ht://Check, to libtool 1.4, the > latest stable release. I have no difficult when building the application > whether with shared or static libraries support. But I am having some > troubles when I try to disable both of them (my friend who wants to build > the debian package uses to configure it this way - --disable-shared > --disable-static). > > That's the error I get: > > >>> > libtool: not configured to build any kind of library > Fatal configuration error. See the libtool docs for more information. > <<< > > Any ideas? I also patched automake as suggested by the INSTALL file of > libtool. Am I missing something? Libtool builds only shared or static libraries. If you tell it to do neither, how is it going to work? You need either --disable-shared or --disable-static, not both. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Search paths with duplicated .la libraries
Say I have: /opt/dir1/ libfoo.a libfoo.la /opt/dir2/ libfoo.so libfoo.la If I: libtool --mode-link cc -L/opt/dir2 -L/opt/dir1 ... then libtool uses /opt/dir2/libfoo.la. However, if I: libtool --mode-link cc -L/opt/dir1 -L/opt/dir2 ... then libtool uses /opt/dir1/libfoo.la even though a shared library exists in /opt/dir2/libfoo.la and not in /opt/dir1/libfoo.la. Is this the desired behaviour? Does libtool care about the first .la it finds or the first .la with a shared library (if not linking statically)? I'm using MLB. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [marcelo.magallon@bigfoot.com: Re: [Mesa3d-dev] Re: libtool]
On Thu, Jun 07, 2001 at 11:50:44AM -0600, Brian Paul wrote: > I'm not going to put a lot of effort into explaining this but here's > the story. > > Mesa's used the convention libGL.so.1.2.xxyyzz for some years now. > The "1.2" indicates the library implements the OpenGL 1.2 API. > Anything else there would be VERY confusing for end users at this > point. > > The last part "xxyyzz" is usually something like 030402 to indicate > Mesa version 3.4.2. With this convention, people can look at their > libGL.so.1.2.xxyyzz file and determine which version of Mesa they're > using. It also allows various versions of libGL.so.1.2.* to coexist. > This very useful for the developers so we may easily switch between > versions when doing regression testing. So the 1.2 is "static"? Have you looked at -release? I don't know what this will do to the SONAME though. It won't give you the name above but close enough (libGL-1.2.xxyyzz.so). -- albert chin ([EMAIL PROTECTED]) _______ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool 1.4 failure on Solaris 8
On Thu, Jun 07, 2001 at 10:48:04AM -0700, Bruce Korb wrote: > Building ethereal: > > Making all in gryphon > /bin/sh ../../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../.. > -I../.. -I/u/local/include -I../.. -I../../wiretap -I../../epan > -I/usr/local/include -I/u/local/include -Wall -g -O2 -I../.. > -I../../wiretap -I../../epan -I/usr/local/include -I/usr/openwin/include > -I/usr/local/lib/glib/include -I/usr/local/include -I/u/local/include -c > packet-gryphon.c > ../../libtool: test: argument expected How did you configure Ethereal 0.8.18? We built with --enable-shared --enable-static and it worked fine (we have a customized version of libtool 1.4 but out changes don't affect Solaris). -- albert chin ([EMAIL PROTECTED]) _______ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Line length limitations
On Wed, Jun 06, 2001 at 07:47:43PM -0700, Bruce Korb wrote:
> [EMAIL PROTECTED] wrote:
> >
> > On Wed, Jun 06, 2001 at 01:10:14AM -0300, Alexandre Oliva wrote:
> > > On Jun 5, 2001, Robert Boehne <[EMAIL PROTECTED]> wrote:
> > >
> > > > So I'm sure how to check the limits under SGI without
> > > > the 'wc' command.
> > >
> > > Use cmp.
> >
> > Ok, I wrote a short test script to do what I want. I have made the
> > decision not to tie the limit of sed to the command-line length limit
> > by having sed take its input from a file rather than a pipe (echo |
> > sed). So, I currently append 30 characters at a time to a file and
> > have sed strip off the last character. I then cmp this against what
> > the correct output should be. The problem with this is that I
> > currently use 3 files and it's slow (too many forks):
> > 1. /tmp/sed-in (non-newline terminated)
> > 2. /tmp/sed-in-nl (newline terminated) because sed wants a NL. We
> > cmp this against /tmp/sed-out.
> > 3. /tmp/sed-out (output sed gave us)
> >
> > My test script is appended below. If this is the correct course of
> > action, I'll work up a patch.
>
> I suggest doing a binary search by doubling the line size
> each iteration. You are correct. You are spending too much
> time inside of the loop. :-) Use this in the loop:
>
> cat /tmp/$$-sed-in /tmp/$$-sed-in > /tmp/$$-sed-tmp
> mv -f /tmp/$$-sed-tmp /tmp/$$-sed-in
Now it's really quick. I'm worried that doubling is too fast but I
think we should be OK.
--
albert chin ([EMAIL PROTECTED])
-- snip snip
#!/bin/sh
trap "rm -f /tmp/$$-sed-out /tmp/$$-sed-in /tmp/$$-sed-in-nl \
/tmp/$$" 0 2 13
if (echo "testing\c"; echo 1,2,3) | grep c >/dev/null; then
# Stardent Vistra SVR4 grep lacks -e, says [EMAIL PROTECTED]
if (echo -n testing; echo 1,2,3) | sed s/-n/xn/ | grep xn
/dev/null; then
ac_n= ac_c='
' ac_t=''
else
ac_n=-n ac_c= ac_t=
fi
else
ac_n= ac_c='\c' ac_t=
fi
_max=0
_count=0
for _sed in /bin/sed /usr/xpg4/bin/sed; do
test ! -f ${_sed} && break
cp /dev/null /tmp/$$-sed-in
_count=0
echo $ac_n "0123456789$ac_c" >/tmp/$$-sed-in
while /bin/true; do
echo "sed: $_sed, _count: $_count"
cat /tmp/$$-sed-in /tmp/$$-sed-in >/tmp/$$
mv /tmp/$$ /tmp/$$-sed-in
cp /tmp/$$-sed-in /tmp/$$-sed-in-nl
echo >>/tmp/$$-sed-in-nl
${_sed} -e 's/a$//' < /tmp/$$-sed-in-nl >/tmp/$$-sed-out
test $? -ne 0 && break
cmp -s /tmp/$$-sed-out /tmp/$$-sed-in-nl
test $? -ne 0 && break
# 1 chars as input seems more than enough
test $_count -gt 10 && break
_count=`expr $_count + 1`
if test $_count -gt $_max; then
_max=$_count
_best_sed=$_sed
fi
done
done
echo $_best_sed
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: Line length limitations
On Wed, Jun 06, 2001 at 01:10:14AM -0300, Alexandre Oliva wrote:
> On Jun 5, 2001, Robert Boehne <[EMAIL PROTECTED]> wrote:
>
> > So I'm sure how to check the limits under SGI without
> > the 'wc' command.
>
> Use cmp.
Ok, I wrote a short test script to do what I want. I have made the
decision not to tie the limit of sed to the command-line length limit
by having sed take its input from a file rather than a pipe (echo |
sed). So, I currently append 30 characters at a time to a file and
have sed strip off the last character. I then cmp this against what
the correct output should be. The problem with this is that I
currently use 3 files and it's slow (too many forks):
1. /tmp/sed-in (non-newline terminated)
2. /tmp/sed-in-nl (newline terminated) because sed wants a NL. We
cmp this against /tmp/sed-out.
3. /tmp/sed-out (output sed gave us)
My test script is appended below. If this is the correct course of
action, I'll work up a patch.
--
albert chin ([EMAIL PROTECTED])
-- snip snip
#!/bin/sh
trap "rm -f /tmp/$$-sed-in /tmp/$$-sed-in-nl /tmp/$$-sed-out" 0 2 13
if (echo "testing\c"; echo 1,2,3) | grep c >/dev/null; then
# Stardent Vistra SVR4 grep lacks -e, says [EMAIL PROTECTED]
if (echo -n testing; echo 1,2,3) | sed s/-n/xn/ | grep xn
/dev/null; then
ac_n= ac_c='
' ac_t=''
else
ac_n=-n ac_c= ac_t=
fi
else
ac_n= ac_c='\c' ac_t=
fi
_max=0
for _sed in /bin/sed /usr/xpg4/bin/sed; do
test ! -f ${_sed} && break
cp /dev/null /tmp/$$-sed-in
_count=0
while /bin/true; do
echo "sed: $_sed, _count: $_count"
echo $ac_n "012345678901234567890123456789$ac_c" >>/tmp/$$-sed-in
cp /tmp/$$-sed-in /tmp/$$-sed-in-nl
echo >>/tmp/$$-sed-in-nl
# There is no 'a' in sed-in but sed has to do something
${_sed} -e 's/^a//' < /tmp/$$-sed-in-nl >/tmp/$$-sed-out
test $? -ne 0 && break
cmp -s /tmp/$$-sed-out /tmp/$$-sed-in-nl
test $? -ne 0 && break
# 1 chars as input seems more than enough
test $_count -gt 333 && break
_count=`expr $_count + 1`
if test $_count -gt $_max; then
_max=$_count
_best_sed=$_sed
fi
done
done
echo $_best_sed
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: Line length limitations
On Sun, May 27, 2001 at 07:10:43PM -0300, Alexandre Oliva wrote: > On May 27, 2001, [EMAIL PROTECTED] wrote: > > > Turns out the problem was with sed. Solaris > > 2.5.1-8/SPARC have the same problem. > > > The problem arises with the assignment for compile_command. I get: > > Output line too long. > > Output line too long. > > Wow! At least you get some output. Some seds will just throw away > the excess characters. > > > Should the command to find the maximum command-line length take the > > above into consideration? > > Yep. This is in our wishlist. > > > And, if it did, would it have helped? > > Only to the point of warning you in case sed is broken if you use long > command lines. I can't think of any reasonable way to make it work in > this case. Would you accept a patch to libtool to locale a better sed on the system? On solaris, /usr/xpg4/bin/sed works better than /usr/bin/sed. I imagine some autoconf addition that sent a long string to various sed's on the system and whichever worked would be used as the sed in libtool. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Line length limitations
While building the latest version of Ethereal 0.8.18 with a long
--prefix, I ran into what appeared to be a limitation in the
command-line length of Solaris 2.6/SPARC /bin/sh. So, I upgraded the
version of libtool used therein to MLB hoping Robert's
piecewise-linking enhancements would work around this problem. I had
the same error. Turns out the problem was with sed. Solaris
2.5.1-8/SPARC have the same problem. GNU sed does not. Here's the
snippet from libtool 1.4 that was giving the problem:
# Now compile the dynamic symbol file.
$show "(cd $output_objdir && $CC
-c$no_builtin_flag$pic_flag_for_symtable\"$dlsyms\")"
$run eval '(cd $output_objdir && $CC
-c$no_builtin_flag$pic_flag_for_symtable"$dlsyms")' || exit $?
# Clean up the generated files.
$show "$rm $output_objdir/$dlsyms $nlist ${nlist}S ${nlist}T"
$run $rm "$output_objdir/$dlsyms" "$nlist" "${nlist}S" "${nlist}T"
# Transform the symbol file into the correct name.
compile_command=`$echo "X$compile_command" | $Xsed -e
"s%@SYMFILE@%$output_objdir/${outputname}S.${objext}%"`
finalize_command=`$echo "X$finalize_command" | $Xsed -e
"s%@SYMFILE@%$output_objdir/${outputname}S.${objext}%"`
;;
The problem arises with the assignment for compile_command. I get:
Output line too long.
Output line too long.
The following platforms don't have the same sed limitation (or at
least their limitation is greater than Solaris): HP-UX 10.20, 11.00,
Tru64 UNIX 4.0D, 5.0, IRIX 6.2, 6.5, AIX 4.3.2.
Should the command to find the maximum command-line length take the
above into consideration? And, if it did, would it have helped?
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: 1.4 oddity
On Mon, May 21, 2001 at 09:37:29PM -0500, [EMAIL PROTECTED] wrote:
> ltmain.in from libtool 1.4 has:
>
> # Do each of the archive commands.
> if test -n "$export_symbols" && test -n "$archive_expsym_cmds"; then
> eval cmds=\"$archive_expsym_cmds\"
> else
> eval cmds=\"$archive_cmds\"
> fi
> IFS="${IFS= }"; save_ifs="$IFS"; IFS='~'
> for cmd in $cmds; do
> IFS="$save_ifs"
> $show "$cmd"
> $run eval "$cmd" || exit $?
> done
> IFS="$save_ifs"
>
> Why don't we:
> eval $show "$cmd"
>
> This would *really* show what will be $run.
Never mind. This breaks Solaris. We still have an issue with what's
being shown is not what is eval'd.
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
1.4 oddity
ltmain.in from libtool 1.4 has:
# Do each of the archive commands.
if test -n "$export_symbols" && test -n "$archive_expsym_cmds"; then
eval cmds=\"$archive_expsym_cmds\"
else
eval cmds=\"$archive_cmds\"
fi
IFS="${IFS= }"; save_ifs="$IFS"; IFS='~'
for cmd in $cmds; do
IFS="$save_ifs"
$show "$cmd"
$run eval "$cmd" || exit $?
done
IFS="$save_ifs"
Why don't we:
eval $show "$cmd"
This would *really* show what will be $run.
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool litter
On Fri, May 11, 2001 at 09:30:32PM -0400, John David Anglin wrote:
> > With the current cvs source for the branch, I find that libtool is leaving
> > an incredible amount of litter in /usr/tmp. I am getting hundreds if
> > not thousands of files like:
> >
> > # cat sh17740.3
> > int main() { return 0; }
> > # cat sh17740.2
> > # Name of the non-PIC object.
> > non_pic_object=none
> >
> > # cat sh17740.1
> > pic_object=none
>
> Should have said this is from running the v3 testsuite fro the 3.0 branch
> under hpux 10.20.
Installing patch PHCO_22536 might help. HP-UX 10.20 sh has a known bug
leaving droppings in /tmp WRT here-documents.
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: $whole_archive_flag_spec and AIX
On Thu, May 10, 2001 at 12:32:15PM -0500, Robert Boehne wrote: > [EMAIL PROTECTED] wrote: > > > > I think the proper way to get $whole_archive_flag_spec set for AIX is > > to use the -bnogc option or one of its equivalents. The > > whole_archive_flag_spec variable is set for Solaris as follows (1.4): > > whole_archive_flag_spec='-z allextract$convenience -z defaultextract' > > > > Looking at ld(1) for AIX, I cannot find an equivalent command. We have: > > -bnogcTurn off garbage collection for all objects > > being linked in > > -bgcbypass:# Turn off garbage collection for # many files > > following this option > > -bkeepfile:F Turn off garbage collection for file `F' > > > > I tried -bnogc and -bgc to determine if object files inbetween them > > would not have garbage collection activated but these flags apply to > > all objects on the command line. I think I could set > > whole_archive_flag_spec in such a way as to split $convenience into > > space-separated filenames and pass that through wc to get the number > > of object files allowing us to use -bgcbypass. Two solutions using > > this method: > > > > whole_archive_flag_spec='-bgcbypass:`echo $convenience | > > tr ' ' '\012' | wc -l` $convenience' > > > > whole_archive_flag_spec='-bgcbypass:`set -- \`echo $convenience\`; > > echo $#` $convenience' > > > > Look like an acceptable solution? The only problem with this is if > > files in $convenience have spaces in the filename. But the Solaris > > solution above has the same problem. > > > > -- > > albert chin ([EMAIL PROTECTED]) > > > > Albert: > > The GNU coding standards don't let you use 'wc' for general Libtool > code, you may be able to get away with it here if 'wc' is available > by default on all the machines this code would be used on. I would > also like you to look at this from the standpoint of a library > such that the list of object files is too long for the shell > to interpret. From my testing 'wc' won't truncate it's output > as much as the shell, but we should check for any limits in wc > under AIX before it gets used. > Is it possible to use a relocatable object file > i.e. 'ld -r manyobjs -o singleobj' Yes. I presume manyobjs would be $convenience. And, what if the list of $convenience files is too long? The above command would fail. I'd have to make singleobj a temporary file. Problem is, when would the temp file be removed? whole_archive_flag_spec is inserted into the link command line. > like an archive file under AIX? I say this because that may > give you an easier solution. Or perhaps you could create > one object file and then make an archive library from that. > I'm not sure if AIX will link all code from an object or > if it does function-level garbage collection. We'd have to rework the way whole_archive_flag_spec is dealt with for that. I'm hoping I don't have to go that far. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
$whole_archive_flag_spec and AIX
I think the proper way to get $whole_archive_flag_spec set for AIX is to use the -bnogc option or one of its equivalents. The whole_archive_flag_spec variable is set for Solaris as follows (1.4): whole_archive_flag_spec='-z allextract$convenience -z defaultextract' Looking at ld(1) for AIX, I cannot find an equivalent command. We have: -bnogcTurn off garbage collection for all objects being linked in -bgcbypass:# Turn off garbage collection for # many files following this option -bkeepfile:F Turn off garbage collection for file `F' I tried -bnogc and -bgc to determine if object files inbetween them would not have garbage collection activated but these flags apply to all objects on the command line. I think I could set whole_archive_flag_spec in such a way as to split $convenience into space-separated filenames and pass that through wc to get the number of object files allowing us to use -bgcbypass. Two solutions using this method: whole_archive_flag_spec='-bgcbypass:`echo $convenience | tr ' ' '\012' | wc -l` $convenience' whole_archive_flag_spec='-bgcbypass:`set -- \`echo $convenience\`; echo $#` $convenience' Look like an acceptable solution? The only problem with this is if files in $convenience have spaces in the filename. But the Solaris solution above has the same problem. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
use of $host_os in ltmain.in [1.4]
ltmain.in in 1.4 has: # On Cygwin there's no "real" PIC flag so we must build both object types case $host_os in cygwin* | mingw* | pw32* | os2*) pic_mode=default ;; esac Taking a look at the generated libtool on Solaris 8/SPARC and AIX 4.3.2, $host_os is not defined anywhere. Is the above an error? Later on I see: # libtool link mode link | relink) modename="$modename: link" case $host in *-*-cygwin* | *-*-mingw* | *-*-pw32* | *-*-os2*) -- albert chin ([EMAIL PROTECTED]) _______ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: static/shared libraries on AIX
On Thu, Apr 26, 2001 at 10:12:52AM -0500, Robert Boehne wrote:
> [EMAIL PROTECTED] wrote:
> >
> > Dan and Robert, please review. The patch does the following:
> > 1. If using runtime-linking, created shared libraries with
> > -G as the final option. Remove -bM:SRE if runtime-linking
> > in effect and creating shared libraries.
> > 2. If using runtime-linking, create static libraries *only*
> > under lib.a and shared libraries *only* under
> > lib.so.
> > 3. Fix bug in allow_undefined_flag WRT evaluation of
> > allow_undefined_flag.
> > 4. Rename lt_cv_prog_cc_static to ac_cv_prog_cc_static.
> > 5. Set ac_cv_prog_cc_wl='-Wl,' to fix bug in quote.test.
> > 6. Set soname_spec='${libname}${release}.so$major' to sync
> > with 1.4.
> >
> > --
> > albert chin ([EMAIL PROTECTED])
>
> I completely agree. I never really liked the idea that you'd have
> to add platform specific flags to get runtime linking, as I'm
> an Automake user. It will take quite a while, but I'm going to
> test your patch on my project, 55 C++ shared libraries dependent
> on each other, all created using Automake from 160MB of source.
> In my expierence, if THAT works, it's pretty darn good.
> Unfortunately, this takes several days to compile so don't
> expect the results tomorrow. ;)
Well, you still need LDFLAGS="-Wl,-brtl". I haven't made it
transparent yet. Once the above patch is confirmed to work, then it'll
be relatively easy to set $aix_use_runtimelinking=yes for aix 4.2 and
above.
Also, I have *not* tested with gcc nor g++ so ltcf-cxx.sh is getting
less attention that ltcf-c.sh.
At this point, I just want to make sure the test suite is 100%
correct. I'm testing with gcc now.
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: static/shared libraries on AIX
On Thu, Apr 26, 2001 at 08:31:02AM -0500, [EMAIL PROTECTED] wrote:
> > From: [EMAIL PROTECTED]
> >
> > Can we decide to:
> > 1. On AIX systems that support run-time-linking, make it the
> > *default* so lib.a is "static" and lib.so is
> > shared. With this, "-brtl" would be "inserted" automatically
> > into the compile/link phases.
>
> I'm not sure if this would work or not. For run-time-linking to work on
> AIX the "program" must be linked with -brtl, and the shared libraries
> must link with -G (shared libs can be linked with -brtl and -G, but
> -G MUST follow the last -brtl flags).
Ok, with the attached patch:
$ LDFLAGS="-brtl" CC=xlc ./configure
$ LDFLAGS="-brtl" CC=xlc gmake MAKE=gmake check
passes all tests for MLB.
Dan and Robert, please review. The patch does the following:
1. If using runtime-linking, created shared libraries with
-G as the final option. Remove -bM:SRE if runtime-linking
in effect and creating shared libraries.
2. If using runtime-linking, create static libraries *only*
under lib.a and shared libraries *only* under
lib.so.
3. Fix bug in allow_undefined_flag WRT evaluation of
allow_undefined_flag.
4. Rename lt_cv_prog_cc_static to ac_cv_prog_cc_static.
5. Set ac_cv_prog_cc_wl='-Wl,' to fix bug in quote.test.
6. Set soname_spec='${libname}${release}.so$major' to sync
with 1.4.
--
albert chin ([EMAIL PROTECTED])
-- snip snip
Index: ltcf-c.sh
===
RCS file: /home/cvs/libtool/Attic/ltcf-c.sh,v
retrieving revision 1.1.2.36
diff -u -3 -p -r1.1.2.36 ltcf-c.sh
--- ltcf-c.sh 2001/04/24 23:58:18 1.1.2.36
+++ ltcf-c.sh 2001/04/26 14:37:37
@@ -268,6 +268,27 @@ else
;;
aix4* | aix5*)
+if test "$host_cpu" = ia64; then
+ # On IA64, the linker does run time linking by default, so we don't
+ # have to do anything special.
+ aix_use_runtimelinking=no
+ exp_sym_flag='-Bexport'
+ no_entry_flag=""
+else
+ # Test if we are trying to use run time linking, or normal AIX
+ # style linking. If -brtl is somewhere in LDFLAGS, we need to
+ # do run time linking.
+ aix_use_runtimelinking=no
+ for ld_flag in $LDFLAGS; do
+if (test $ld_flag = "-brtl" || test $ld_flag = "-Wl,-brtl" ); then
+ aix_use_runtimelinking=yes
+ break
+fi
+ done
+ exp_sym_flag='-bexport'
+ no_entry_flag='-bnoentry'
+fi
+
hardcode_direct=yes
hardcode_libdir_separator=':'
link_all_deplibs=yes
@@ -303,52 +324,37 @@ else
if test "$host_cpu" = ia64; then
shared_flag='${wl}-G'
else
-shared_flag='${wl}-bM:SRE'
+if test "$aix_use_runtimelinking" = yes; then
+ shared_flag='${wl}-G'
+else
+ shared_flag='${wl}-bM:SRE'
+fi
fi
fi
-if test "$host_cpu" = ia64; then
- # On IA64, the linker does run time linking by default, so we don't
- # have to do anything special.
- aix_use_runtimelinking=no
- exp_sym_flag='-Bexport'
- no_entry_flag=""
-else
- # Test if we are trying to use run time linking, or normal AIX style linking.
- # If -brtl is somewhere in LDFLAGS, we need to do run time linking.
- aix_use_runtimelinking=no
- for ld_flag in $LDFLAGS; do
-if (test $ld_flag = "-brtl" || test $ld_flag = "-Wl,-brtl" ); then
- aix_use_runtimelinking=yes
- break
-fi
- done
- exp_sym_flag='-bexport'
- no_entry_flag='-bnoentry'
-fi
# -bexpall does not export symbols beginning with underscore (_)
always_export_symbols=yes
if test "$aix_use_runtimelinking" = yes; then
- # Warning - without using the other run time loading flags (-brtl), -berok will
- # link without error, but may produce a broken library.
- allow_undefined_flag=' ${wl}-berok'
+ # Warning - without using the other run time loading flags (-brtl),
+ # -berok will link without error, but may produce a broken library.
+ allow_undefined_flag='-berok'
hardcode_libdir_flag_spec='${wl}-blibpath:$libdir:/usr/lib:/lib'
- archive_expsym_cmds="\$CC $shared_flag"' -o $output_objdir/$soname $libobjs
$deplibs $compiler_flags ${allow_undefined_flag} '"\${wl}$no_entry_flag
\${wl}$exp_sym_flag:\$export_symbols"
+ archive_expsym_cmds="\$CC"' -o $output_objdir/$soname $libobjs $deplibs
+$compiler_flags `if test "x${allow_undefined_f
Re: Making hardcode.test more robust [patch against HEAD]
On Tue, Apr 24, 2001 at 02:47:38AM -0300, Alexandre Oliva wrote: > On Apr 22, 2001, [EMAIL PROTECTED] wrote: > > BTW, another possible solution is to compile with CFLAGS=-s. Compiling > > without CFLAGS=-g solves the problem on Solaris and with CFLAGS=-s > > solves the problem on IRIX 6.x. > > I'm not sure how portable -s is. Hmm... Any takers? How about running strip on the binary after creating it? > > Good point about host != build. How would I even begin to solve that? > > Only do the improved test when host = build. Which amounts to falling > back to the original version when cross compiling. And then, I wonder > whether we really want potentially different results for the same host > platform... I'll see about adding a strip after creating the binary. That might be more "portable", though I still like the objdump approach. How about a warning if host != build and the improved test case exists? -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: static/shared libraries on AIX
On Tue, Apr 17, 2001 at 02:51:08AM +0100, Gary V. Vaughan wrote: > > AIX by default wants it's shared libraries called lib.a. > > So libltdl.a is created (as a symlink to libltdl.so.3.0.0). > > The Makefile then wants to create a non-shared library also called > > libltdl.a. This predictably fails as follows: > > ar cru .libs/libltdl.a ltdl.o > > ar: 0707-108 File .libs/libltdl.a is not an archive file. > > AIX is fast catching Ultrix in my league table of `most gratuitously > different Unix'... > > > My changes get around this problem in two ways: > > > > - When building libtool with run-time-linking enabled, we no longer need > > to name our shared libraries lib.a. lib.so is used instead, > > so the non-shared libltdl.a can be created without any collision. > > > > - When building libtool without run-time-linking, my changes do still > > create a lib.a. However, it is an actual archive containing the > > shared object (just like the quirky way the rest of AIX does it). > > What you end up with is a libltdl.a that contains both the shared and the > > non-shared object. This is not really what was intended, and would > > likely cause problems if you ever really needed to use the non-shared > > object, but for the most part it seems to work. The only other thing I can > > think to do is not bulid the non-shared object in this case. Can we decide to: 1. On AIX systems that support run-time-linking, make it the *default* so lib.a is "static" and lib.so is shared. With this, "-brtl" would be "inserted" automatically into the compile/link phases. 2. On AIX systems that do not support run-time-linking, support only shared libraries (so, lib.a is shared and there is no lib.so). I'm trying to fix the remaining 'make check' failures on AIX and knowing what to do about shared/static would certainly help. While the above doesn't expose the full "robustness" of the AIX linker, methinks it good enough. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: test if -c and -o work in 1.4
On Wed, Apr 25, 2001 at 04:13:13PM -0500, [EMAIL PROTECTED] wrote:
> The test to determine if a compiler supports -c and -o creates a
> non-writable directory and performs a test compile sending stderr to a
> file. If the file is non-empty, even if the object file was written
> (CWD is a non-writable directory while -o points to a file in a
> writable directory), the test fails. Is this correct?
>
> The IBM xlC compiler complains that the current directory is not
> writable (because it's using temporary files?) but still saves the
> object file to the path specified with -o. Do we want to assume
> success if the object file was created and has non-empty size?
>
> Anyway, if libtool runs and $need_locks="yes", should there be *any*
> lock files after libtool completes? If so, why don't you add:
> trap "$run $rm $removelist; exit 0" 0
> to:
> if test "$compiler_c_o" = no; then
> output_obj=`$echo "X$srcfile" | \
> $Xsed -e 's%^.*/%%' -e 's%\.[^.]*$%%'`.${objext}
> lockfile="$output_obj.lock"
> removelist="$removelist $output_obj $lockfile"
> trap "$run $rm $removelist; exit 1" 1 2 15
> in ltmain.in?
Ok, I think I found the problem. In ltmain.in from 1.4 we have:
baseobj=`$echo "X$obj" | $Xsed -e "s%.*/%%"`
libobj=`$echo "X$baseobj" | $Xsed -e "$o2lo"`
# Now arrange that obj and lo_libobj become the same file
$show "(cd $xdir && $LN_S $baseobj $libobj)"
if $run eval '(cd $xdir && $LN_S $baseobj $libobj)'; then
exit 0
else
Shouldn't it be:
baseobj=`$echo "X$obj" | $Xsed -e "s%.*/%%"`
libobj=`$echo "X$baseobj" | $Xsed -e "$o2lo"`
# Now arrange that obj and lo_libobj become the same file
$show "(cd $xdir && $LN_S $baseobj $libobj)"
if $run eval '(cd $xdir && $LN_S $baseobj $libobj)'; then
# Unlock the critical section if it was locked
if test "$need_locks" != no; then
$run $rm "$lockfile"
fi
exit 0
else
This is the only non-zero exit before '$run $rm "$lockfile"' later on.
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
test if -c and -o work in 1.4
The test to determine if a compiler supports -c and -o creates a
non-writable directory and performs a test compile sending stderr to a
file. If the file is non-empty, even if the object file was written
(CWD is a non-writable directory while -o points to a file in a
writable directory), the test fails. Is this correct?
The IBM xlC compiler complains that the current directory is not
writable (because it's using temporary files?) but still saves the
object file to the path specified with -o. Do we want to assume
success if the object file was created and has non-empty size?
Anyway, if libtool runs and $need_locks="yes", should there be *any*
lock files after libtool completes? If so, why don't you add:
trap "$run $rm $removelist; exit 0" 0
to:
if test "$compiler_c_o" = no; then
output_obj=`$echo "X$srcfile" | \
$Xsed -e 's%^.*/%%' -e 's%\.[^.]*$%%'`.${objext}
lockfile="$output_obj.lock"
removelist="$removelist $output_obj $lockfile"
trap "$run $rm $removelist; exit 1" 1 2 15
in ltmain.in?
In 1.4 on powerpc-ibm-aix4.3.2.0 with xlC 5.0, if I do:
$ cd tests
$ sh mdemo-conf.test
$ sh mdemo-make.test
$ cd ../mdemo
$ ls *lock
foo1.o.lock foo2.o.lock sub.o.lock
Is this correct? Because the lock files don't get cleaned up, I'm
getting the following behaviour while running 'make check':
PASS: depdemo-unst.test
PASS: mdemo-conf.test
PASS: mdemo-make.test
FAIL: mdemo-exec.test
FAIL: mdemo-inst.test
PASS: mdemo-unst.test
=== Running dryrun.test
= Running gmake clean in ../mdemo
= Making object files in ../mdemo (dry run)
= Making object files in ../mdemo
gmake[3]: Entering directory `/opt/build/libtool-1.4/mdemo'
/bin/sh ./libtool --mode=compile xlc -DPACKAGE=\"mdemo\"
-DVERSION=\"0.1\" -DHAVE_DLFCN_H=1 -DHAVE_MATH_H=1 -I.
-I/opt/build/libtool-1.4/tests/../mdemo
-I/opt/build/libtool-1.4/tests/../mdemo/../libltdl-g -c foo1.c
Waiting for foo1.o.lock to be removed
Waiting for foo1.o.lock to be removed
Waiting for foo1.o.lock to be removed
...
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: AIX shared libraries in MLB and 1.4
On Wed, Apr 25, 2001 at 11:08:05AM -0500, [EMAIL PROTECTED] wrote:
> It looks like AIX has been using
> version_type=linux
> for quite some time. So I guess we should keep using it.
Ok, patch to MLB to sync with 1.4 attached.
ChangeLog:
2001-04-25 Albert Chin-A-Young <[EMAIL PROTECTED]>
* ltconfig.in: Remove `.o' from end of shared library
names in AIX (sync with 1.4 branch). Use $major number
in shared library name by setting version_type=linux.
> Dan
>
> > From: [EMAIL PROTECTED]
> >
> > On Wed, Apr 25, 2001 at 10:38:31AM -0500, [EMAIL PROTECTED] wrote:
> > > I've been meaning to send in a patch about this:
> > >
> > > soname_spec='${libname}${release}.so$major'
> > >
> > > is what we finally decided to go with for AIX standard linking.
> > > It is important to get these synched up, or we will have binary
> > > compatibility problems.
> >
> > And do you plan to leave version_type=linux for 1.4? To keep 1.4 and
> > MLB the same, we need to decide on whether or not version_type=linux
> > and what soname_spec is. I'm fine with removing version_type=linux and
> > making soname_spec equivalent to what you have above (though different
> > from MLB but I'm assuming you know better what to do).
> >
> > --
> > albert chin ([EMAIL PROTECTED])
--
albert chin ([EMAIL PROTECTED])
-- snip snip
Index: ltconfig.in
===
RCS file: /home/cvs/libtool/Attic/ltconfig.in,v
retrieving revision 1.246.2.58
diff -u -3 -p -r1.246.2.58 ltconfig.in
--- ltconfig.in 2001/04/24 22:20:08 1.246.2.58
+++ ltconfig.in 2001/04/25 17:04:01
@@ -984,6 +984,7 @@ aix3*)
;;
aix4* | aix5*)
+ version_type=linux
if test "$host_cpu" = ia64; then
# AIX 5 supports IA64
library_names_spec='${libname}${release}.so$versuffix
${libname}${release}.so$major $libname.so'
@@ -1002,7 +1003,7 @@ aix4* | aix5*)
# We preserve .a as extension for shared libraries though AIX4.2
# and later when we are not doing run time linking.
library_names_spec='${libname}${release}.a $libname.a'
- soname_spec='${libname}${release}.so$major.o'
+ soname_spec='${libname}${release}.so$major'
fi
# If we're using GNU nm, then we don't want the "-C" option.
# -C means demangle to AIX nm, but means don't demangle with GNU nm
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
quote.test in 1.4 and MLB for AIX
In 1.4's libtool.m4 we have:
if test "$GCC" = yes; then
lt_cv_prog_cc_wl='-Wl,'
lt_cv_prog_cc_static='-static'
case $host_os in
aix*)
...
else
# PORTME Check for PIC flags for the system compiler.
case $host_os in
aix3* | aix4* | aix5*)
# All AIX code is PIC.
if test "$host_cpu" = ia64; then
# AIX 5 now supports IA64 processor
lt_cv_prog_cc_static='-Bstatic'
lt_cv_prog_cc_wl='-Wl,'
else
lt_cv_prog_cc_static='-bnso -bI:/lib/syscalls.exp'
fi
;;
Any reason we don't define lt_cv_prog_cc_wl='-Wl,' if $host_CPU !=
ia64? xlC 5.0 does support -Wl. From the xlc help text:
-W Give the options to the compiler program
where x can be one or more of the following:
In MLB's ltcf-c.sh we have:
if test "$with_gcc" = yes; then
ac_cv_prog_cc_wl='-Wl,'
ac_cv_prog_cc_static='-static'
case $host_os in
aix*)
...
else
# PORTME Check for PIC flags for the system compiler.
case $host_os in
aix*)
# All AIX code is PIC.
ac_cv_prog_cc_static="$ac_cv_prog_cc_static ${ac_cv_prog_cc_wl}-lC"
;;
Any reason we don't define ac_cv_prog_cc_wl='-Wl,' for aix?
I think this is the reason quote.test is failing on MLB (because wl=""
causing libtool to strip "-Wl").
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
quote.test in 1.4
Why is tests/quote.test hardcoded to use gcc? In MLB tests/quote.test, we use $CC and get CC from tests/defs by: eval `$libtool --config | grep '^CC='` -- albert chin ([EMAIL PROTECTED]) _______ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: AIX shared libraries in MLB and 1.4
On Wed, Apr 25, 2001 at 10:10:06AM -0500, Robert Boehne wrote: > Yes, this should be the case that MLB and 1.4 are similar. > I'm suprised that they aren't actually, but I haven't really > kept up with the 1.4 patches. Does this patch cause any > differences in the test suite results? If not I'm all for it. BTW, do you get all tests to pass in MLB for AIX? I'm using xlc 5.0.0 (will update to 5.0.2 later today) and get the following failures on powerpc-ibm-aix4.3.2.0: FAIL: mdemo-inst.test FAIL: mdemo-inst.test FAIL: quote.test The patch does not introduce additional regressions for 1.4. -- albert chin ([EMAIL PROTECTED]) _______ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: AIX shared libraries in MLB and 1.4
On Wed, Apr 25, 2001 at 10:38:31AM -0500, [EMAIL PROTECTED] wrote:
> I've been meaning to send in a patch about this:
>
> soname_spec='${libname}${release}.so$major'
>
> is what we finally decided to go with for AIX standard linking.
> It is important to get these synched up, or we will have binary
> compatibility problems.
And do you plan to leave version_type=linux for 1.4? To keep 1.4 and
MLB the same, we need to decide on whether or not version_type=linux
and what soname_spec is. I'm fine with removing version_type=linux and
making soname_spec equivalent to what you have above (though different
from MLB but I'm assuming you know better what to do).
--
albert chin ([EMAIL PROTECTED])
_______
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
AIX shared libraries in MLB and 1.4
I'm looking over the differences in how shared libraries are built
between MLB and 1.4. Some questions:
1. Any reason for version_type=linux in 1.4 and not MLB?
2. Should we sync up shared library names between 1.4 and MLB
(cf soname_spec below). Shared library names in MLB are
libfoo.so.o while in 1.4 its libfoo.so.$major.
--
albert chin ([EMAIL PROTECTED])
-- snip snip
Index: libtool.m4
===
RCS file: /home/cvs/libtool/libtool.m4,v
retrieving revision 1.166
diff -u -3 -p -r1.166 libtool.m4
--- libtool.m4 2001/04/24 23:40:42 1.166
+++ libtool.m4 2001/04/25 12:51:50
@@ -1832,7 +1832,6 @@ aix3*)
;;
aix4* | aix5*)
- version_type=linux
if test "$host_cpu" = ia64; then
# AIX 5 supports IA64
library_names_spec='${libname}${release}.so$major
${libname}${release}.so$versuffix $libname.so'
@@ -1854,18 +1853,20 @@ aix4* | aix5*)
fi
;;
esac
-# AIX (on Power*) has no versioning support, so currently we can not hardcode
correct
-# soname into executable. Probably we can add versioning support to
-# collect2, so additional links can be useful in future.
+# AIX (on Power*) has no versioning support, so currently we can
+# not hardcode correct soname into executable. Probably we can
+# add versioning support to collect2, so additional links can
+# be useful in future.
if test "$aix_use_runtimelinking" = yes; then
- # If using run time linking (on AIX 4.2 or later) use lib.so instead of
- # lib.a to let people know that these are not typical AIX shared
libraries.
+ # If using run time linking (on AIX 4.2 or later) use lib.so
+ # instead of lib.a to let people know that these are not
+ # typical AIX shared libraries.
library_names_spec='${libname}${release}.so$versuffix
${libname}${release}.so$major $libname.so'
else
# We preserve .a as extension for shared libraries through AIX4.2
# and later when we are not doing run time linking.
library_names_spec='${libname}${release}.a $libname.a'
- soname_spec='${libname}${release}.so$major'
+ soname_spec='${libname}${release}.so$major.o'
fi
shlibpath_var=LIBPATH
deplibs_check_method=pass_all
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: 1.3e (1.913) test results for hppa2.0n-hp-hpux11.00 (FAIL)
On Tue, Apr 24, 2001 at 12:46:33AM -0700, Russ Allbery wrote: > That patch fixed the hang. The test results still aren't pretty. Apply the fix I posted to libtool-patches. That should bring it down to 6 failures. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: 1.3e (1.910) test results for sparc-sun-solaris2.8 (FAIL)
On Mon, Apr 23, 2001 at 10:41:36PM +0100, Gary V. Vaughan wrote: > On Monday 23 April 2001 10:26 am, Russ Allbery wrote: > > I assume that these are mostly the known Solaris failures. > > > > > > Configuring libtool 1.3e (1.910 2001/04/23 00:34:53) > > > > > > checking host system type... sparc-sun-solaris2.8 > > checking build system type... sparc-sun-solaris2.8 > > checking for ld used by GCC... /usr/ccs/bin/ld > > checking if the linker (/usr/ccs/bin/ld) is GNU ld... no > > > > Using gcc 2.95.3. > > After patching for test -L, using gcc 2.95.1, the suite now passes for me on > Solaris 8 and Solaris 2.5.1. I can't reproduce the failure with quote.test, > so I am assuming Solaris is now in pretty good shape. No. hardcode.test fails with the Sun C compiler because, with CFLAGS=-g, the -L flags are saved in the generated binary. Ditto for IRIX. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: HP-UX 11.00 and parsing /bin/nm -p output (failing)
On Mon, Apr 23, 2001 at 02:11:52PM -0500, [EMAIL PROTECTED] wrote:
> This pertains to the HEAD branch.
>
> When parsing the output of /bin/nm -p, libtool.m4 contains the
> following sed statement to massage the output:
>
> # Try without a prefix undercore, then with it.
> for ac_symprfx in "" "_"; do
>
> # Write the raw and C identifiers.
> [lt_cv_sys_global_symbol_pipe="sed -n -e 's/^.*[]\($symcode\)[
> ][ ]*\($ac_symprfx\)$sympat$opt_cr$/$symxfrm/p'"]
>
> So, there can be only *one* $symcode between spaces in the /bin/nm -p
> output. While creating demo/libtool during a run of 'make tests' for
> demo-conf.test, /bin/nm -p generates the following on the sample
> conftest.o file:
> $ /bin/nm -p conftest.o
> 08 t D$0
> 60 t D$1
> 08 T main
> 00 T nm_test_func
> 01 CS nm_test_var
>
> [snip ...]
>
> So, it seems there can be *more* than one $symcode. So, how about we
> change the sed statement to look for *more* than one $symcode
> separated by spaces? I have looked at the man pages of nm on Solaris
> and Tru64 UNIX and don't see anywhere that there is only one $symcode
> output.
Patch below.
--
albert chin ([EMAIL PROTECTED])
-- snip snip
Index: libtool.m4
===
RCS file: /home/cvs/libtool/libtool.m4,v
retrieving revision 1.160
diff -u -3 -p -r1.160 libtool.m4
--- libtool.m4 2001/04/20 20:55:18 1.160
+++ libtool.m4 2001/04/23 20:21:37
@@ -188,7 +188,7 @@ cygwin* | mingw* | pw32*)
[symcode='[ABCDGISTW]']
;;
hpux*) # Its linker distinguishes data from code symbols
- lt_cv_global_symbol_to_cdecl="sed -n -e 's/^T .* \(.*\)$/extern char \1();/p' -e
's/^. .* \(.*\)$/extern char \1;/p'"
+ lt_cv_global_symbol_to_cdecl="sed -n -e 's/^T .* \(.*\)$/extern char \1();/p' -e
+'s/^$symcode* .* \(.*\)$/extern char \1;/p'"
;;
irix*)
[symcode='[BCDEGRST]']
@@ -218,7 +218,7 @@ fi
for ac_symprfx in "" "_"; do
# Write the raw and C identifiers.
-[lt_cv_sys_global_symbol_pipe="sed -n -e 's/^.*[ ]\($symcode\)[ ][
]*\($ac_symprfx\)$sympat$opt_cr$/$symxfrm/p'"]
+[lt_cv_sys_global_symbol_pipe="sed -n -e 's/^.*[ ]\($symcode$symcode*\)[
+ ][ ]*\($ac_symprfx\)$sympat$opt_cr$/$symxfrm/p'"]
# Check to see that the pipe works correctly.
pipe_works=no
@@ -274,7 +274,7 @@ const struct {
[lt_preloaded_symbols[] =]
{
EOF
- sed 's/^. \(.*\) \(.*\)$/ {"\2", (lt_ptr_t) \&\2},/' < "$nlist" >>
conftest.$ac_ext
+ sed "s/^$symcode* \(.*\) \(.*\)$/ {\"\2\", (lt_ptr_t) \&\2},/" < "$nlist"
+>> conftest.$ac_ext
cat <<\EOF >> conftest.$ac_ext
{0, (lt_ptr_t) 0}
};
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
HP-UX 11.00 and parsing /bin/nm -p output (failing)
This pertains to the HEAD branch. When parsing the output of /bin/nm -p, libtool.m4 contains the following sed statement to massage the output: # Try without a prefix undercore, then with it. for ac_symprfx in "" "_"; do # Write the raw and C identifiers. [lt_cv_sys_global_symbol_pipe="sed -n -e 's/^.*[]\($symcode\)[ ][ ]*\($ac_symprfx\)$sympat$opt_cr$/$symxfrm/p'"] So, there can be only *one* $symcode between spaces in the /bin/nm -p output. While creating demo/libtool during a run of 'make tests' for demo-conf.test, /bin/nm -p generates the following on the sample conftest.o file: $ /bin/nm -p conftest.o 08 t D$0 60 t D$1 08 T main 00 T nm_test_func 01 CS nm_test_var Under HP-UX 10.20, it gives: $ /bin/nm -p conftest.o 08 t D$0 56 t D$1 11 T main 03 T nm_test_func 01 C nm_test_var According to the man page for nm(1): -p Display information in a blank-separated output format. Each symbol name is preceded by its value (blanks if undefined) and one of the letters A (absolute), B (bss symbol), C (common symbol), D (data symbol), R (section region), S (tstorage symbol), T (text symbol) or U (undefined). S is used on SOM files only. If the symbol is local (nonexternal), the type letter is in lowercase. If the symbol is a secondary definition, the type letter is followed by the letter S. Note that -p is not compatible with -P. So, it seems there can be *more* than one $symcode. So, how about we change the sed statement to look for *more* than one $symcode separated by spaces? I have looked at the man pages of nm on Solaris and Tru64 UNIX and don't see anywhere that there is only one $symcode output. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
HP-UX 11.00 and dlopen()
While running ./configure for libtool 1.4 on a hppa1.1-hp-hpux11.00
system:
...
checking for dlfcn.h... yes
...
checking if libtool supports shared libraries... yes
checking for dlopen in -ldl... no
checking for dlopen... yes
checking whether a program can dlopen itself... yes
checking whether a statically linked program can dlopen itself... no
The presence of dlopen is tested for from the following libtool.m4
snippet:
AC_CHECK_LIB(dl, dlopen, [lt_cv_dlopen="dlopen" lt_cv_dlopen_libs="-ldl"],
[AC_CHECK_FUNC(dlopen, lt_cv_dlopen="dlopen",
[AC_CHECK_FUNC(shl_load, lt_cv_dlopen="shl_load",
[AC_CHECK_LIB(svld, dlopen,
[lt_cv_dlopen="dlopen" lt_cv_dlopen_libs="-lsvld"],
[AC_CHECK_LIB(dld, shl_load,
[lt_cv_dlopen="dld_link" lt_cv_dlopen_libs="-dld"])
])
])
])
])
Also, dlopen() is present in 64-bit HP-UX 11.00. However, for 32-bit
systems (like the one being tested here), you need a patch
(PHSS_22514) to get dlopen. This system has PHSS_22478 installed
(predecessor patch to PHSS_22514). From the list of bugs fixed in
PHSS_22514 (after PHSS_22478):
- JAGac39834: Severity: 6
32 bit dlopen/dlsym calls can't be used on 1.1 systems
So, I did the following:
$ cat a.c
char dlopen();
int main () {
dlopen();
}
$ cc -Ae a.c
$ nm a.out
dlopen | |undef |code |
dlopen | 1|uext |stub |
I think the dlopen above comes from /usr/lib/libdld.sl.
So, how about we *force* shl_load on at least HP-UX 11.00 32-bit? Or
maybe we should check for shl_load before dlopen (which would have the
effect of not using dlopen on HP-UX at all)? We don't have to worry
about 10.20 because it doesn't have dlopen(). Should we consider
forcing shl_load for HP-UX 11.00 64-bit as well?
--
albert chin ([EMAIL PROTECTED])
_______
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
