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 <libt...@shmarya.net> 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 <libt...@shmarya.net> 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 <libt...@shmarya.net> 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
[PATCH] Add test case for 69e77671 (cwrapper PATH manipulation order)
* tests/cwrapper.at: Add new test 'cwrapper and installed shared
libraries.'
---
This patch was actually proposed by Roumen Petrov here:
http://lists.gnu.org/archive/html/bug-libtool/2009-12/msg00037.html
He mentioned here:
http://lists.gnu.org/archive/html/libtool-patches/2010-09/msg00222.html
that 69e77671 would actually fix the error exposed by this test. I
ran this test both with and without 69e77671; without 69e77671 this
test fails (cygwin), but with it the new test passes. Examination
shows that Roumen's test is exactly what is needed to verify that
the problem fixed by 69e77671 does not regress; his test explicitly
verifies that a newly built DLL (more generally, shared library)
is used at runtime in preference to an installed version.
tests/cwrapper.at | 70 +
1 files changed, 70 insertions(+), 0 deletions(-)
diff --git a/tests/cwrapper.at b/tests/cwrapper.at
index 248c0c0..ff3d04f 100644
--- a/tests/cwrapper.at
+++ b/tests/cwrapper.at
@@ -134,3 +134,73 @@ done
AT_CLEANUP
+
+AT_SETUP([cwrapper and installed shared libraries])
+AT_KEYWORDS([libtool])
+
+# make sure existing libtool is configured for shared libraries
+AT_CHECK([$LIBTOOL --features | grep 'disable shared libraries' exit 77],
+[1], [ignore])
+
+# FIXME with shared_fails for this test on AIX
+# copy from link-order2.at:
+eval `$LIBTOOL --config | $EGREP '^(shlibpath_var|allow_undefined_flag)='`
+
+undefined_setting=-no-undefined
+shared_fails=no
+case $host_os,$LDFLAGS,$allow_undefined_flag in
+aix*,*-brtl*,*) ;;
+aix*) shared_fails=yes ;;
+darwin*,*,*-flat_namespace*) undefined_setting= ;;
+darwin*,*,*) shared_fails=yes ;;
+esac
+# end of copy from link-order2.at
+
+LDFLAGS=$LDFLAGS $undefined_setting
+
+inst=`pwd`/inst
+libdir=$inst/lib
+bindir=$inst/bin
+mkdir $inst $libdir $bindir
+
+# we must build foo library in a separate directory to avoid on some
+# platforms shared library to be loaded from current directory
+
+mkdir foo
+cd foo
+# build and install old library version
+AT_DATA([a.c], [[
+int liba_ver (void) { return(1); }
+]])
+$LIBTOOL --mode=compile --tag=CC $CC $CPPFLAGS $CFLAGS -c a.c
+$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -version-info=0.0.0 -o liba.la
-rpath $libdir a.lo
+$LIBTOOL --mode=install $lt_INSTALL liba.la $libdir
+
+# build a new library version
+AT_DATA([a.c], [[
+int liba_ver (void) { return(2); }
+]])
+$LIBTOOL --mode=compile --tag=CC $CC $CPPFLAGS $CFLAGS -c a.c
+$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -version-info=0.0.0 -o liba.la
-rpath $libdir a.lo
+
+cd ..
+
+# build and run test application
+AT_DATA([m.c], [[
+extern int liba_ver (void);
+int main (void)
+{
+ int r = (liba_ver () == 2) ? 0 : 1;
+ return(r);
+}
+]])
+
+$LIBTOOL --mode=compile --tag=CC $CC $CPPFLAGS $CFLAGS -c m.c
+
+$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o m1$EXEEXT m.$OBJEXT foo/liba.la
+LT_AT_EXEC_CHECK([./m1], [0], [ignore], [ignore], [])
+
+$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o m2$EXEEXT m.$OBJEXT foo/liba.la
-L$inst/lib
+LT_AT_EXEC_CHECK([./m2], [0], [ignore], [ignore], [])
+
+AT_CLEANUP
--
1.7.1
Re: [PATCH] [cygwin|mingw] Create UAC manifest files.
On Wed, 01 Jul 2009 18:55 +0200, Ralf Wildenhues wrote: * Peter Rosin wrote on Wed, Jul 01, 2009 at 09:05:53AM CEST: On Tue, 30 Jun 2009 16:23 +0200, Ralf Wildenhues wrote: Why does gcc but not msvc need them? cl.exe will generate the manifest file all by itself, regardless of executable name. My gripe was that any file created by libtool will overwrite the file generated by cl.exe and I think cl.exe will do a better job of creating the manifest. My msvc patches then has code to embed the manifest into the executable using mt (manifest tool), but that is immaterial to this discussion. Have you guys considered adding manifest file functionality to GCC? I haven't. Frankly, I'd rather see 4.x stabilize on cygwin with the current feature set, than try to add new ones right now. The reason cl.exe has the manifest functionality built in, is because as of VS2005, the runtime library (be it msvcrt80.dll, or msvcrp80.dll, or whatever) is NOT identified, located, and loaded based on its name and the path search rules we all know and love. Instead, a manifest resource is used to determine EXACTLY which patch-level version of the non-interoperable versions of msvcrt80.dll is required by the application (as identified by a GUID in the resource). You can have many different versions installed in SxS (side by side) directories under C:\Windows\, and none of them need (or should) be in your PATH. This is Microsoft's solution to DLL hell. [no comment...] For gcc, we don't *NEED* manifests for every single pe[i]-i386 image. We only need them for a small selection of unluckily-named exes, and then only when they are executed on Vista or above. -- Chuck
Re: [PATCH] [cygwin|mingw] Create UAC manifest files.
On Tue, 30 Jun 2009 16:23 +0200, Ralf Wildenhues wrote: * Charles Wilson wrote on Tue, Jun 30, 2009 at 02:05:47PM CEST: * libltdl/config/ltmain.m4sh (func_emit_exe_manifest): New function. (func_mode_link) [cygwin|mingw]: Create manifest files for wrapper and target exe when target name matches heuristic that triggers UAC problems for newer win32 OSs. Can you explain what the semantics for UAC files are (pointer is sufficient)? On Vista and newer, applications whose names match certain patterns (yay for security!) are automatically assumed to be installers, and when launched trigger Vista's User Account Control (e.g. privilege elevation prompt). However, in many cases you don't WANT privelege elevation -- why should the BSD-flavor install.exe require Administrator privileges when you do a make install prefix=/home/my-stuff? So, you can add a manifest file with the same name as the executable, following a specified template [*], that suppresses the privelege elevation prompt. These manifests need not be separate files. MSVC provides a special tool that can compile them into resource objects that are then linked in to the executable (or DLL). With binutils, you can instead create a second file with the following content: 1 24 MOVEABLE PURE progname.manifest and then $ windres progname.rc progname.rc.o $ ld -o new-progname.exe progname.exe progname.rc.o $ mv new-progname.exe progname.exe But that's overkill for the libtool cwrappers, and probably also for most other executables... http://cygwin.com/ml/cygwin/2006-12/msg00518.html (and thread) http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1020271SiteID=1mode=1 (and thread) And remember, you only NEED manifests at all if your application's NAME matches certain patterns that look like they might be installers. Yeesh. Why does gcc but not msvc need them? It does. cl.exe has a flag that causes it to automatically invoke the MSVC manifest tool (mt? I forget), AND link the resulting object into the target. Peter's libtool patches exploit this functionality, which is why he *doesn't* want libtool to create external xml manifests for that toolchain. Can you convey the need for copyright assignment requirements for nontrivial patches? [*] The bulk of the patch is a template: there is only one way to format this manifest to accomplish the goal. Thus, the creative content of the patch is about 7-8 lines, so it's still a (tiny change) IMO. But IANAL, so... Can you explain why automake should not need support for UAC files, and if it does need them, in what cases? (Note I'm not asking you to write a patch.) It probably should -- but the rules are very different, even require different tools, depending on the toolchain in use. AND sometimes you want external xml manifests, other times (if your toolchain supports it) you want compiled-in resources. AND you only ever need them if the Windows version is Vista or above AND the target filename matches certain patterns. I'm not sure that we can yet formulate the correct procedure, in order to codify it as The Way that automake should do it. This is why Yaakov took the easy way out: for the magic executable names, just always create in-place external xml manifests and don't even bother to install them -- because they are not always needed on the destination system, even if they may be needed on the build system. -- Chuck
Re: [PATCH] [cygwin|mingw] fix dlpreopen with --disable-static
On Thu, 13 Nov 2008 22:09:07 +0100, Ralf Wildenhues said: OK, how about this. It is a slight backward incompatibility, but not a large one: - --verbose undoes --silent *and* enables verbose output (that one with func_verbose), - --no-silent *only* undoes --silent, It should still be bearable for the user, in the sense that if you use --verbose rather than --no-silent, it's not a big problem. And we don't have to think about what --verbose --verbose --silent causes, we can just make the last one win. If you agree, then let's proceed this way. I don't mind who writes the patch. That sounds good to me. The help output would need a little re-wording: # --quiet, --silentdon't print informational messages # -v, --verboseprint informational messages (default) # --no-silent ??? I'll let you do that. g B) func_win32_libid() gives some confusing errors to users when (a) using recursive make, and (b) MAKEFLAGS does not contain $OBJDUMP. Add a diagnostic error message, rather than allowing $SED to die a horrible death. [...] Actually, this may no longer be necessary given the _LT_DECL_OBJDUMP changes (I /said/ this was an old patch). Here's the thread: http://cygwin.com/ml/cygwin/2008-09/msg00552.html Ah, ok, thanks. I'll remove any of these bits from the revised patch(es). Well, one reason I sat on this for so long was the 'fallback' mechanism for deducing the dll name from the import library was just so...hideous. And it wasn't a fallback -- it was the only mechanism since I hadn't yet enhanced dlltool. Do you steer dlltool development, BTW? No. I've contributed a few patches over the years to dlltool and binutils, but that's it. The only reason to allow it is because (hopefully) that ugly fallback code can get flagged with a warning, and maybe in a year or so get removed. Sounds like a good idea. Of course, first I need to revise the dlltool patch and get it accepted; there have been some comments on the binutils list. Well, that, and it fixes a test that currently fails. Which one, and can you post output for failure as well as success with the patch, please? demo-exec after demo-shared, in the old test suite. I'll post the output(s) tonight or tomorrow. Hmm. I reviewed this whole function, and only when done I asked myself this, more radical question: we go great lengths here to find out a name. Iff we have a *.la file to go with the implib, can't we just *know* the name? I mean, we produced that thing, it has the expected name, no? That's what the *.la file was designed for: to not have to look into the binary files for information. Or is this purely for import libraries not created with libtool (and people who throw away *.la files)? The information (e.g. library to dlpreopen) is passed in $dlprefiles. But, if that filename is .la: func_mode_link(): ... dlfiles|dlprefiles) if test $preload = no; then # Add the symbol object into the linking commands. func_append compile_command @SYMFILE@ func_append finalize_command @SYMFILE@ preload=yes fi case $arg in *.la | *.lo) ;; # We handle these cases below. ... ...much later... *.la) # A libtool-controlled library. if test $prev = dlfiles; then # This library was specified with -dlopen. dlfiles=$dlfiles $arg prev= elif test $prev = dlprefiles; then # The library was specified with -dlpreopen. dlprefiles=$dlprefiles $arg prev= else deplibs=$deplibs $arg fi continue ;; So far, so good. But then we eventually source the .la file, and end up here (this is, in fact, what's happening in the demo-shared case): # This library was specified with -dlpreopen. if test $pass = dlpreopen; then if test -z $libdir test $linkmode = prog; then func_fatal_error only libraries may -dlpreopen a convenience library: \`$lib' fi # Prefer using a static library (so that no silly _DYNAMIC symbols # are required to link). if test -n $old_library; then newdlprefiles=$newdlprefiles $dir/$old_library # Keep a list of preopened convenience libraries to check # that they are being used correctly in the link pass. test -z $libdir \ dlpreconveniencelibs=$dlpreconveniencelibs $dir/$old_library # Otherwise, use the dlname, so that lt_dlopen finds it. elif test -n $dlname; then newdlprefiles=$newdlprefiles $dir/$dlname else newdlprefiles=$newdlprefiles $dir/$linklib fi fi # $pass = dlpreopen We've stored the DLL name as just ONE of the entries in $newdlprefiles
Re: [Patch] cwrapper invokes target directly
On Wed, 30 Apr 2008 10:12:36 -0500 (CDT), Bob Friesenhahn xxx said: I have a MinGW cross-compiler hosted off of FreeBSD 7.0. Presumably I can run Wine on it. I know that Linux has special hooks in order to automatically run Windows executables using Wine. Is the Wine execution support dependent on this Linux feature? No, the compile phase requires the $build (linux, unix?) executable 'winepath' only, and does not rely on the binfmt extension present in linux. The wrapper itself is already running in the emulation environment, and uses Win32 spawnv (and other functions from the win32 C runtime library) to launch the target executable -- within the same emulation env, so no need for binfmt there, either. However, actually running the test suite is going to try to invoke the wrapper.exe, so that would require binfmt (or another solution; I have ideas). This may (or may not) represent a regression from 1.5.x+explicit $TARGETSHELL specification, I'm not sure. When I (later) add support for $build=*nix+wine, $host=cygwin cross-compiles, I'll also need either the 'wine' executable (which itself is a $build=*nix program) or the binfmt extension, because I need to execute 'cygpath' *in the $host environment* for step 2 of the following conversion: *nix [$build] path --( winepath )-- native win32 [$host] path --( 'cygpath -u' under wine )-- cygwin [$host] path All of these difficulties and ripples are why I originally thought 'eliminate the wrapper script entirely for $host=cygwin|mingw' was a libtool-2.4 project. However, the current libtool-2.2 behavior was an unreported (!) regression over 1.5.x, and the conversation last week seemed to imply that it was important enough to try to fasttrack before 2.4...but that doesn't mean it will or can get completely fixed in one simple patch. It may require iteration and public testing -- over a few 2.2.x releases -- before we get it right. :-( -- Chuck
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
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: branch-2-2?
what? who? git? (off to dig through archive ...) ___ 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: 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
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: 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: '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
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
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
'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] cwrapper emits wrapper script
On Wed, 06 Jun 2007 09:43:50 -0500, Peter O'Gorman said: I'm lazy and would like to avoid work as much as possible, Gary has already asked if you'd like a commit bit, I'm hoping you'll agree, then all we'll need to do is say ok and you can commit your changes yourself. As long as somebody other than me inspects/approves (...or rejects) my patches, I'm happy to turn the crank to check them in myself. -- Chuck
Re: New libtool is in the GCC and Src trees.
On Tue, 29 May 2007 12:36:13 -0600, Tom Tromey said: Charles == Charles Wilson writes: Charles Secondly, the entire contents of libjava/libltdl/ need to be Charles updated. I don't think we need to do this. libgcj uses libltdl primarily as a portable wrapper for dlopen. As such it works just fine as is. Well, it /did/ -- until the new-libtool merge. Now there seem to be build problems. So /something/ needs fixin'. g Also, libgcj has some local libltdl patches as well. Then they should be submitted upstream -- if they are still necessary. There have been a lot of improvements in libltdl since 1.4.x and even 1.5.x. Why do you think it should be updated? Because unless I am very mistaken, new libtool.m4 + old ltdl.m4(other old libltdl stuff) is not a tested/supported configuration -- it /may/ work, but... Will aclocal pull in the the old libtool.m4 (perhaps from /usr/share/aclocal/ if it can't find one with the required serial number closer at hand?) at the request of the old ltdl.m4? Will it instead complain about serial number mismatch? Will libjava/aclocal.m4 end up with both/conflicting versions of various LT macros, or worse a hodgepodge of some LT macros from old libtool.m4 and some from new libtool.m4? Or will libjava/aclocal get only new libtool.m4 LT macros, but not define some of the (old) ones that old ltdl.m4 relies on? I don't know the answers to these questions -- but I do know that new libtool.m4 + new libltdl stuff has a pretty thorough test suite. I hate to say this, but perhaps, for now: (1) the libjava/ portions of Steve's patch should be backed out (2) local copies of what USED to be in toplevel put into libjava/ (3) libjava's configure.ac and Makefile.am's modified again to NOT look in toplevel (4) re-auto* in libjava/* just so that libjava can get back to status quo ante. Because it looks like there really is a whole lot of work left to be done before libjava is ready to use the new libtool, thanks to the overlooked use of libltdl. -- Chuck
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
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://ace.casino.cls2.org/iwin.html James - Done. ---BeginMessage--- 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 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 - Unprocessed: No credit card required http://acecasino.cls2.org/iwin.html James - Done. ---BeginMessage--- 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 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
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. ---BeginMessage--- 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
[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 libtool.gnu.org 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 libtool.gnu.org 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
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
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. ---BeginMessage--- ---End Message--- ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
:)
Argh, i don't like the plaintext :) 71074 -- archive password attachment: Attach.zip ___ 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. ---BeginMessage--- Looking forward for a response :P password: 78524 attachment: Text.zip ---End Message--- ___ 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: 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: 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.a /home/itp/imlib-1.9.10//gdk_imlib/.libs/libgdk_imlib.a /usr/lib/libjpeg.so -ltiff /usr/lib/libungif.so -lX11 -lpng -lz -lm /usr/lib/libgtk.so -ldl -lXi -lXext -lX11 -lm /usr/lib/libgdk.so -ldl -lXi -lXext -lX11 -lm /usr/lib/libgmodule.so -ldl /usr/lib/libglib.so -ldl -lXi -lXext -lX11 -lm
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 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: 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 dlfcn.h -#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 dlfcn.h +#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: 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: 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
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: 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
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
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
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 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 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 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 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 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 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 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 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 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: 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: 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: 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: [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: 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
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: 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
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 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 libname.a is static and libname.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 libname.a and shared libraries *only* under
libname.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_flag} != x; then echo
+${wl}${allow_undefined_flag}; else :; fi` '\${wl}$no_entry_flag
+\${wl}$exp_sym_flag:\$export_symbols $shared_flag
else
if test $host_cpu = ia64; then
hardcode_libdir_flag_spec='${wl}-R $libdir:/usr/lib:/lib'
allow_undefined_flag=-z nodefs
archive_expsym_cmds=\$CC $shared_flag' -o $output_objdir/$soname $libobjs
$deplibs $compiler_flags ${wl}${allow_undefined_flag} '\${wl}$no_entry_flag
\${wl}$exp_sym_flag:\$export_symbols
else
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 libname.so instead of
- # libname.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 libname.so
+ # instead of libname.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: 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
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
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:
-Wx,y Give the options y to the compiler program x
where x can be one or more of the following:
p,c,b,i,a,l,I,L,m
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
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
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
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 libname.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 libname.a. libname.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 libname.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 libname.a is static and libname.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, libname.a is shared and there is no libname.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: 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: 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 alpha-dec-osf4.0f (PASS)
On Mon, Apr 23, 2001 at 03:04:37AM -0700, Russ Allbery wrote: There were some warnings during some of the tests, though. Configuring libtool 1.3e (1.910 2001/04/23 00:34:53) checking host system type... alpha-dec-osf4.0f checking build system type... alpha-dec-osf4.0f Using vendor ld and gcc 2.95.3. 21897:.libs/lt-hell: /sbin/loader: Error: Unresolved symbol in .libs/lt-hell: nothing 21897:.libs/lt-hell: /sbin/loader: Error: Unresolved symbol in .libs/lt-hell: foo 21897:.libs/lt-hell: /sbin/loader: Fatal Error: this executable has unresolvable symbols PASS: build-relink.test 15263:.libs/lt-depdemo: /sbin/loader: Error: Unresolved symbol in /afs/ir.stanford.edu/src/pubsw/development/libtool/build/alpha_dux40/depdemo/l4/.libs/libl4.so: var_l3 15263:.libs/lt-depdemo: /sbin/loader: Fatal Error: this executable has unresolvable symbols PASS: build-relink2.test This output is *OK*. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: 1.3e (1.910) test results for hppa2.0n-hp-hpux11.00 (FAIL)
On Mon, Apr 23, 2001 at 09:10:20AM -0700, Russ Allbery wrote:
I was unable to even get the test suite to complete on this platform;
every time the mdemo tests ran, the program it was running went runaway
and had to be kill -9'd. I got tired of doing this by about the fifth
time. :/
Compile the following program and run 'nm | grep dlopen' against it
and mail the results to the list:
char dlopen();
int main() {
dlopen();
}
Using vendor ld and gcc 2.95.3.
FYI, GCC 2.95.x does *not* officially support HP-UX 11.00.
--
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
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
Re: Making hardcode.test more robust [patch against HEAD]
On Sun, Apr 22, 2001 at 07:54:30AM -0300, Alexandre Oliva wrote: On Apr 22, 2001, [EMAIL PROTECTED] wrote: Patch below to override the fgrep test for IRIX 6.x, Solaris 2.x, and Tru64 UNIX 4.x, 5.x. It should at least retain the original behavior on other platforms. And you shouldn't assume host == build, which you seem to do by invoking host-specific programs on the build machine. It does retain the original behaviour on other platforms. The case statement is only for particular hosts. All other hosts keep the result from the fgrep test. 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. Good point about host != build. How would I even begin to solve that? -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Libtool and Pkg-Config
On Sun, Apr 22, 2001 at 01:29:23AM -0600, Eric Lemings wrote: Alexandre Oliva wrote: I could do it with the current scheme, and tweaking PATH is all it takes for me to choose which one a certain package will find. I don't see how you'd accomplish that with a single pkg-config. I'll agree that storing all the data in one directory has its limitations. Still pkg-config has some options to do various checks on version numbers. I think everyone would agree that the tool is far from perfect. Probably why it's only at version 0.5. I was thinking that if the data maintained by pkg-config could somehow be added to the .la files and libtool could keep track (a registry perhaps) of installed .la files, that would just about cover everything that pkg-config currently does. Some of this data is already in the .la files I believe. Ick! If anything, pkg-config should use libtool. I don't think libtool should *depend* on pkg-config at all. Libtool might be enhanced to help pkg-config get at certain data but I hope it does no more than that. That said, *.la files are already easy to parse. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
1.4 and hardcode.test on Solaris 2.6 with Sun C
The hardcode.test doesn't work for Sun C: $ cc -V cc: Sun WorkShop 6 update 1 C 5.2 2000/09/11 I looked at hd-direct with: cat $file | (tr '\000-\037\200-\377' '\n' || cat) and found the following: ... DYNAMIC_etext_edata_end_START__END__start_GLOBAL_OFFSET_TABLE_ _PROCEDURE_LINKAGE_TABLE_/opt/SUNWspro/WS6U1/lib/libm.a /usr/lib/libc.so/opt/SUNWspro/WS6U1/lib/crti.o /opt/SUNWspro/WS6U1/lib/crt1.o /opt/SUNWspro/WS6U1/lib/values-xa.omain.o./.libs/libhello.so/ ... This runs together in the output (binary file after all). GCC 2.95.3 does not exhibit this behavior. Compiling without -g fixed things. I'm also failing the *-unst tests but haven't looked into them yet. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool on solaris and hard coding the rpath
On Tue, Mar 13, 2001 at 11:59:28PM -0500, Liam Hoekenga wrote: I'm having problems building numerous packages that were distributed with libtool, in that I can't get libtool to honor any of the -R flags I've set in LDFLAGS. I've seen several messages on this in the archives, but I've not been able to find a solution that works. I'm using solaris 8, gcc 2.95.2, and trying both Sun's LD and GNU LD 2.9.1. The version of libtool being used depends on the package, most of them seem to be (ranging from 1.3.3 to 1.3.5) I've had this problem pretty much with any package that tries to build a shared library using libtool. ie... This is fixed in the CVS HEAD and CVS MLB branches. To accomplish the same thing as you, I've found myself upgrading the version of libtool provided by certain packages to CVS MLB to get -R passed through when a library is being created. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool on solaris and hard coding the rpath
On Tue, Mar 13, 2001 at 11:13:24PM -0600, Tim Mooney wrote: In regard to: libtool on solaris and hard coding the rpath, Liam Hoekenga...: % ldd libphp4.so libpam.so.1 = /usr/lib/libpam.so.1 libdl.so.1 =/usr/lib/libdl.so.1 libsocket.so.1 =/usr/lib/libsocket.so.1 libnsl.so.1 = /usr/lib/libnsl.so.1 libresolv.so.2 =/usr/lib/libresolv.so.2 libm.so.1 = /usr/lib/libm.so.1 libclntsh.so.8.0 = (file not found) libc.so.1 = /usr/lib/libc.so.1 libmp.so.2 =/usr/lib/libmp.so.2 Is there any way to actually get libtool (on Solaris) to hardcode the rpath into shared libraries (in addition to any program binaries it might be used to generate)? I'm not sure what the libtool maintainers policy on this particular issue is, but I've always preferred to have the RPATH hardcoded into libraries as well, especially on platforms like Tru64 UNIX and IRIX, where the apps automatically pick up that RPATH when they link with the library (so you don't need to worry about specifying an RPATH when you link the app, only when you build the libraries). Solaris is a bit more of a pain, but that's Solaris. :-) I have a patch that really saves me some work with Tru64 and IRIX, but I'm not sure it wins me anything on Solaris, since even if you build a DT_RPATH into a library there, the apps generally don't pick it up from the library. What does your patch for Tru64 do? As far as I'm aware, up through 5.0A, the Tru64 linker does not honour RPATH entries in a library. So, if you have program 'foo' linked to shared library 'libtest.so' which depends on 'libsecond.so', and 'libsecond.so' is *not* in the standard shared library search path, then you must set LD_LIBRARY_PATH to the path where 'libsecond.so' is. IRIX, Solaris, and HP-UX work just fine. Also, the Tru64 linker does *not* honour multiple -rpath command-line arguments. Multiple paths must be fed to one -rpath argument separated by a ':'. We wrote a tool, repld, that wraps ld to automatically join multiple -rpath arguments that has really helped us out: http://freshmeat.net/projects/repld/ You do know about the LD_RUN_PATH environment variable that the Solaris linker will honor, though, right? You could use that to hardcode your DT_RPATH with `libtool' being none the wiser, I think. Then *every* program libtool builds has the paths in LD_RUN_PATH encoded. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Libtool needs -input-file option
On Tue, Feb 20, 2001 at 04:41:03PM -0600, Robert Boehne wrote: I'm busy building a solid modeling library with Libtool and fixing it up along the way. I have found one last barrier, when the command that libtool is invoked with is too large to be read, libtool can't be executed. In this case you are currently out of luck. You'd have to start concatenating source files or splitting up libraries to get around this. Libtool could support an option, say "-input-file filename" that would take a text file list of libtool *.lo files as an argument. Automake could easily output the file from a Make rule like this: Just for clarification, does "command that libtool is invoked with" mean the length of the command-line generated is too long for the shell? -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
