Re: Fix for Arg list too long
On Jan 24, 2001, Robert Boehne <[EMAIL PROTECTED]> wrote:
> #1) I have to check for the existence of 'wc -c' to check the
> command line length.
I'd rather not rely upon fixed limits. I was thinking about doing it
dynamically. For example, as the command line grows, test that you
can still $echo it before committing to the addition of a new
argument. But I realize this may be very hard to do right.
If you really want to use something like `wc -c', make sure you set up
portable fallbacks, such as expr "X$val" : ".*" and awk's length().
Instead of looking for fixed limits in header files, we might just try
larger and larger commands until we bump onto a limit. Starting at
128 and doubling on each iteration until it fails or gets to, say,
128Kb, is probably reasonable. The command might be the expr above or
a non-built-in echo (using the $0 --fallback-echo comes to mind).
Also bear in mind that the invocation of the char-counter itself may
fail in case the command line gets too long.
> #2) I am checking the system header files to find the maximum command
> line length. Currently I have this in ltconfig.in, but it really
> only needs to be run once for each platform, not each tag. Where should
> it go?
ltconfig is indeed the right place for it (in MLB until we move it
into libtool.m4, as Gary did in mainline). So far, we don't have
infrastructure to do the test only for the main configuration; maybe
after moving to libtool.m4 we should; that will make it much easier.
> #3) $LD is set to $CXX in most cases for C++ compilers
My opinion is that this is wrong. We should just bite the bullet and
use $CXX all over, leaving $LD with the correct value.
> A previous design linked objects one at a time
We should probably keep some version of the previous design, at least
for static libraries. It's not good to link multiple objects together
in case they're going to be stored into a static library, because
linkers often pull whole object files out of static libraries. We'd
better add them incrementally (but we can do it many at a time). We
should probably have some configuration flag to indicate that
incremental old_archiving is not possible, and fallback to relinking
in this case.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: Darwin / Mac OS X: Status, Help needed
On Jan 26, 2001, Christoph Pfisterer <[EMAIL PROTECTED]> wrote:
> My patch is attached to this message; I hope it's in good shape.
It's hard to tell, since it requires binhex to be viewed.
Anyway, Darwin is already supported in CVS versions of libtool. Maybe
you should consider using it, instead of the quite-outdated 1.3.5? It
would be nice if you could give it some testing, and fix any problems
before 1.4 goes out of the door.
> I haven't had the time to look at the 1.4 branch, so I don't know
> how different it is and how helpful this patch is.
All I can say is that it's changed a lot.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
libtool@gnu.org
On Jan 19, 2001, Alexander Mai <[EMAIL PROTECTED]> wrote:
> However upon linking our shared lib a -lbar may fail - since the
> LDFLAGS var is not used here!
Huh? LDFLAGS is certainly used when linking both static and shared
libraries. The difference is only at run-time. Are you *running*
programs at configure time?
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: A*_PROG_LIBTOOL problems
On Jan 19, 2001, Alexander Mai <[EMAIL PROTECTED]> wrote:
> AC_PROG_LIBTOOL I get
> Makefile.am:47: library used but `LIBTOOL' not defined in `configure.in'
automake 1.4 doesn't understand AC_PROG_LIBTOOL.
> In both cases configure later on asks for a ltconfig which it can't find:
Did you libtoolize the package?
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: Installation problems
On Jan 22, 2001, Alexander Mai <[EMAIL PROTECTED]> wrote:
> Now I installed the auto* tools again and it seems things do almost
> work now (still get an autoconf error message, but configure
> seems to run?!:
> autoconf: Undefined macros:
> ***BUG in Autoconf--please report*** AC_TRY_DLOPEN_SELF
> )
Is this CVS autoconf or autoconf 2.13? I think libtool isn't CVS
autoconf-ready yet. Akim posted some patches to that effect, but I'm
not sure they've already been integrated.
> Now it turns out that in /usr/X11R6/lib an old version of
> libfoo exists. And in the following libbar will be linked against
> the old /usr/X11R6/lib/libfoo.so and not the new one.
> I tried moving around the compiler/linker flags, but that
> didn't solve the problem. Is this is a shortcoming of libtool
> or is there a way for me to fix this?
For short, there's no way to solve this problem. Even if you could
manage to get the linker to find the shared libraries you want to have
linked in, you'd have trouble getting the dynamic linker to load them
from the correct directories.
Having LDFLAGS set up so that the linker searches the build tree first
always helps, but in a case like the one you describe, there's very
little libtool can do by itself to figure out what you really meant.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: Dynamically loading C++ Modules on Solaris
On Jan 22, 2001, Kevin Atkinson <[EMAIL PROTECTED]> wrote:
> On Mon, 22 Jan 2001, Kevin Atkinson wrote:
>> I am trying to get the dramatic loading of C++ libraries to work on Solaris
>> but I am running into problems with the fact that shared C++ libraries are
>> not provided on many systems because Gcc does not enable them by
>> default. Is there a way to get dynamic C++ libraries to work on Solaris
>> when only a static C++ library is available. If not does some one know
>> where I can find precompiled shared Gcc 2.95.2 shared C++ libraries on
>> Solaris? Failing that would it be possibly for some people to arrange to
>> send my the precompiled library as it is rather difficult for me to
>> compile it myself as I have a 25 MB quota. I currently using Solaris 2.7
>> but I would like to be able to get this working on as many platforms as
>> possible.
> I should also add that I am using the multi-lib branch of libtool.
Try adding -Wc,-mimpure-text to the command line. If it works, I'd
be willing to accept a patch that:
(i) tests whether GCC supports it and use it to build shared
libraries. Only in this case should we set deplibs_check_method to
pass_all on Solaris with GCC in libtool.m4
(ii) in ltcf-c.sh, ltcf-cxx.sh and ltcf-gcj.sh, in the GCC section of
Solaris, adds -mimpure-text to archive_cmds if deplibs_check_method is
pass_all.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Getting started question:
Hi, If I want to test libtool 1.4 (I develop on openBSD & windows 2K (via cygwin) - which may be an odd combination :-]), what's the recommended autoconf version to get? I saw a message recently about libtool CVS not being autoconf CVS ready which is what has prompted my question. Sometime soon I'm going to add dynamic module support to squid, which currently configures under autoconf 2.13 Rob ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Getting started question:
On Jan 31, 2001, "Robert Collins" <[EMAIL PROTECTED]> wrote:
> If I want to test libtool 1.4 (I develop on openBSD & windows 2K
> (via cygwin) - which may be an odd combination :-]), what's the
> recommended autoconf version to get?
I'd stay with 2.13, unless you really mean to test CVS autoconf and
the readiness of CVS libtool to it.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: Getting started question:
On Wed, 31 Jan 2001, Robert Collins wrote: > Hi, > If I want to test libtool 1.4 (I develop on openBSD & windows > 2K (via cygwin) - which may be an odd combination :-]), what's the > recommended autoconf version to get? > > I saw a message recently about libtool CVS not being autoconf CVS > ready which is what has prompted my question. In my experience, Libtool CVS generally works with Autoconf CVS. In fact, that is what I have been using for the past couple of years for ImageMagick. Sometimes there are nasty bugs and sometimes things work just fine (just fine at the moment). The snapshot at alpha.gnu.org is a good way to get a recent Autoconf to play with. Just make sure that you test thoroughly prior to releasing anything. > Sometime soon I'm going to add dynamic module support to squid, > which currently configures under autoconf 2.13 Great. Modules are working well for ImageMagick. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
RE: Fix for Arg list too long
Title: RE: Fix for Arg list too long -Original Message- From: Alexandre Oliva [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 31, 2001 2:40 AM To: Boehne, Robert Cc: [EMAIL PROTECTED] Subject: Re: Fix for Arg list too long >On Jan 24, 2001, Robert Boehne <[EMAIL PROTECTED]> wrote: > >> #1) I have to check for the existence of 'wc -c' to check the >> command line length. > >I'd rather not rely upon fixed limits. I was thinking about doing it >dynamically. For example, as the command line grows, test that you >can still $echo it before committing to the addition of a new >argument. But I realize this may be very hard to do right. > I agree, I had a bit of trouble with OSF/1 because the system headers didn't have the right number (or perhaps it was in a different format). I would prefer to run a test at configure time to determine the maximum command line length. >If you really want to use something like `wc -c', make sure you set up >portable fallbacks, such as expr "X$val" : ".*" and awk's length(). > I went with 'wc -c' because it was the only thing I could get to work, but I didn't try awk... I designed it so that if 'wc -c' was not available, or the maximum command length hadn't been determined, or the command line is short enough, then libtool falls back to the way it currently links. >Instead of looking for fixed limits in header files, we might just try >larger and larger commands until we bump onto a limit. Starting at >128 and doubling on each iteration until it fails or gets to, say, >128Kb, is probably reasonable. The command might be the expr above or >a non-built-in echo (using the $0 --fallback-echo comes to mind). > Alexandre, I'm not familiar with '$0 --fallback-echo', could you elaborate on this a bit? >Also bear in mind that the invocation of the char-counter itself may >fail in case the command line gets too long. > I have not had this problem with 'wc -c' but I did have it with `expr $cmd : ".*"` >> #2) I am checking the system header files to find the maximum command >> line length. Currently I have this in ltconfig.in, but it really >> only needs to be run once for each platform, not each tag. Where should >> it go? > >ltconfig is indeed the right place for it (in MLB until we move it >into libtool.m4, as Gary did in mainline). So far, we don't have >infrastructure to do the test only for the main configuration; maybe >after moving to libtool.m4 we should; that will make it much easier. > >> #3) $LD is set to $CXX in most cases for C++ compilers > >My opinion is that this is wrong. We should just bite the bullet and >use $CXX all over, leaving $LD with the correct value. > SGI was one system that would not allow me to use $reload_cmds because $LD was set to CC. (even with $reload_flag set to -Wl,-r) I suppose I could read the man pages to see if this can't be worked around using CC... >> A previous design linked objects one at a time > >We should probably keep some version of the previous design, at least >for static libraries. It's not good to link multiple objects together >in case they're going to be stored into a static library, because >linkers often pull whole object files out of static libraries. We'd >better add them incrementally (but we can do it many at a time). We >should probably have some configuration flag to indicate that >incremental old_archiving is not possible, and fallback to relinking >in this case. > I'm not sure I understand this, you're saying that some archivers can't add several object files to an existing archive properly? This would certainly be a portability problem I hadn't considered. Ouch! As far as linking one object at a time, it worked, but it increased the compile times by orders of magnitude. That wouldn't normally be a big deal, but in the case where you're linking enough objects to overflow the command line it becomes unreasonably cumbersome. Currently I have made a few assumptions about compilers and linkers, #1) $old_archive_cmds will allow users to add objects to an existing archive. I'm pretty sure this isn't true, but is there a way to add objects to an archive for most supported archivers? #2) $reload_cmds will take several objects as input and effectively concatenate the files. i.e. linking o1.o o2.o o3.o o4.o o5.o into a shared library is the same as linking in steps $reload_cmds -o newO1.o o1.o o2.o o3.o o4.o then linking a shared library with newO1.o o5.o as input. For cross-compiles this isn't an issue because it is the linker on the build system that may run into the arg list limitation. So perhaps a small C program to check argument lengths wouldn't be out of order? Only if 'wc -c' doesn't exist of course. What language could someone be using with libtool that they wouldn't have a C or C++ compiler? What OS'es don't supply 'wc -c'? I'm not asking to relax these requirements, I just would feel more at ease working around the
Re: Fix for Arg list too long
On Jan 31, 2001, "Boehne, Robert" <[EMAIL PROTECTED]> wrote:
>> 128Kb, is probably reasonable. The command might be the expr above or
>> a non-built-in echo (using the $0 --fallback-echo comes to mind).
>>
> Alexandre, I'm not familiar with '$0 --fallback-echo', could you
> elaborate on this a bit?
Run `ltconfig --fallback-echo whatever you want'. Similarly for
libtool, and mainline's configure. That's the real echo command we
use as a last resort. Look for --fallback-echo in the beginning of
ltconfig.in to see how it works.
>> Also bear in mind that the invocation of the char-counter itself may
>> fail in case the command line gets too long.
>>
> I have not had this problem with 'wc -c' but I did have it with `expr $cmd :
> ".*"`
You'd also have the problem with `$echo $cmd | wc -c' if echo is not a
shell built-in, so you must take this possibility into account.
> SGI was one system that would not allow me to use $reload_cmds because
> $LD was set to CC.
This is wrong. LD should be ld, not cc. That was a kludge we'd used
in the beginning of ltcf-cxx.sh to reduce the divergence from
ltcf-c.sh, but it no longer makes sense. We should go ahead and use
CC wherever we use LD, and keep LD with a sane value, which is the
name of the linker, not of the compiler.
> I'm not sure I understand this, you're saying that some archivers can't
> add several object files to an existing archive properly?
They can. The problem is that -r is not reversible: as soon as you
merge multiple object files into a single one, the linker will pull
them all from the archive, instead of pulling only the ones that are
actually needed. That's why I'd rather have object files added
incrementally to static libraries, many at a time, but not by means of
reloading.
For shared libraries, this doesn't matter, since it's always linked as
a whole.
> #1) $old_archive_cmds will allow users to add objects to an existing
> archive. I'm pretty sure this isn't true, but is there a way
> to add objects to an archive for most supported archivers?
This is true in general. There will probably be exceptions (Windows,
for one), in which case we won't be able to do incremental adding of
objects, and reloading will be needed. We'd set some new variable to
tell libtool whether incremental archiving is possible or not.
> #2) $reload_cmds will take several objects as input and effectively
> concatenate the files. i.e. linking
>o1.o o2.o o3.o o4.o o5.o
> into a shared library is the same as linking in steps
>$reload_cmds -o newO1.o o1.o o2.o o3.o o4.o
> then linking a shared library with
>newO1.o o5.o
> as input.
Perfect. But we should prefer incremental archiving for the creation
of static libraries, where supported.
> So perhaps a small C program to check argument lengths wouldn't
> be out of order?
Then you'd need a C compiler for the build machine, and you may not
have one. wc, expr or awk should fit the bill, no need to go for a C
program, IMO.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
bug in CVS version of yesterday
Hi, me again (the guy with the sed problem in cvs-fresh autoconf) I have a project that compiles nicely on a computer with one well-installed gcc/g++ in the path. I get the following problem on a sun which has several versions of gcc. I set $CC $CXX $CXXCPP To me, things seem to be related to the /unige/egcs/bin/g++ Please don't hesitate to ask followup questions. Cheers, Wolfgang /bin/sh ../libtool --mode=link /unige/egcs/bin/g++ -g -O2 -D__GIFT_WITH_PERL__ -D_REENTRANT -I/unige/util/lib/perl5/5.00502/sun4-solaris-thread/CORE -o gift Server.o ../expat/xmlparse/*.o ../expat/xmltok/*.o -L/user/u7/muellerw/gift-0.1.6pre/libMRML/cc/ -L/user/u7/muellerw/gift-0.1.6pre/libGIFTAcPerl/cc/ -L/user/u7/muellerw/gift-0.1.6pre/libGIFTQuPerl/cc/ -L/user/u7/muellerw/gift-0.1.6pre/libGIFTAcInvertedFile/cc/ -L/user/u7/muellerw/gift-0.1.6pre/libGIFTAcHierarchy/cc/ -L/user/u7/muellerw/gift-0.1.6pre/libGIFTAcDistanceMatrix/cc/ -L/user/u7/muellerw/gift-0.1.6pre/libGIFTQuInvertedFile/cc/ -L/user/u7/muellerw/gift-0.1.6pre/libGIFTQuBayesian/cc/ -L/user/u7/muellerw/gift-0.1.6pre/libGIFTQuHierarchy/cc/ -L/user/u7/muellerw/gift-0.1.6pre/libGIFTAcURL2FTS/cc/ -L/user/u7/muellerw/gift-0.1.6pre/libMRML/cc/ -L/user/u7/muellerw/gift-0.1.6pre/libGIFTAcPerl/cc/ -L/user/u7/muellerw/gift-0.1.6pre/libGIFTQuPerl/cc/ -L/user/u7/muellerw/gift-0.1.6pre/libGIFTAcInvertedFile/cc/ -L/user/u7/muellerw/gift-0.1.6pre/libGIFTAcHierarchy/cc/ -L/user/u7/muellerw/gift-0.1.6pre/libGIFTAcDistanceMatrix/cc/ -L/user/u7/muellerw/gift-0.1.6pre/libGIFTQuInvertedFile/cc/ -L/user/u7/muellerw/gift-0.1.6pre/libGIFTQuBayesian/cc/ -L/user/u7/muellerw/gift-0.1.6pre/libGIFTQuHierarchy/cc/ -L/user/u7/muellerw/gift-0.1.6pre/libGIFTAcURL2FTS/cc/ -L -lGIFTQuPerl -lGIFTAcPerl -lMRML /unige/util/lib/perl5/5.00502/sun4-solaris-thread/auto/DynaLoader/DynaLoader.a -L/unige/util/lib/perl5/5.00502/sun4-solaris-thread/CORE -lperl -lsocket -lnsl -ldl -lm -lposix4 -lpthread -lc -lcrypt -lpthread -lsocket -lm -- Wolfgang Müller, assistant-doctorant == PhD student (2001), teaching assistant Personal page: http://cui.unige.ch/~vision/members/WolfgangMueller.html Maintainer, GNU Image Finding Tool (http://www.gnu.org/software/gift) .&í¢fj)b b²ÒânÚ(!¶Úþf¢ ?¨¥©ÿ+-wèþX¶%
Re: Fix for Arg list too long
On Wed, Jan 31, 2001 at 05:27:25PM -0200, Alexandre Oliva wrote: : On Jan 31, 2001, "Boehne, Robert" <[EMAIL PROTECTED]> wrote: : > SGI was one system that would not allow me to use $reload_cmds because : > $LD was set to CC. : : This is wrong. LD should be ld, not cc. That was a kludge we'd used : in the beginning of ltcf-cxx.sh to reduce the divergence from : ltcf-c.sh, but it no longer makes sense. We should go ahead and use : CC wherever we use LD, and keep LD with a sane value, which is the : name of the linker, not of the compiler. In C++ mode on IRIX, you need to link libraries with CC (the C++ compiler) and not with ld (which only handles C linking correctly). Lars J ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Now complete: bug in CVS version of yesterday
> "AO" == Alexandre Oliva <[EMAIL PROTECTED]> writes: AO> On Jan 31, 2001, Wolfgang Mueller <[EMAIL PROTECTED]> wrote: >> I get the following problem on a sun which has several versions of >> gcc. AO> I don't see any problem here. Or do you mean that gibberish after AO> your signature? :-) Yesyes, there was no problem in the command line, as I mailed you already, but rather in the stuff after it. On your request the complete one goes to the list, and I try not to skip the most important two lines (the error message is in the very end). you suggested that it might be interesting to look at the .la files. I send one immediately after the promised complete error message: /bin/sh ../libtool --mode=link /unige/egcs/bin/g++ -g -O2 -D__GIFT_WITH_PERL__ -D_REENTRANT -I/unige/util/lib/perl5/5.00502/sun4-solaris-thread/CORE -o gift Server.o ../expat/xmlparse/*.o ../expat/xmltok/*.o -L/user/u7/muellerw/gift-0.1.6pre/libMRML/cc/ -L/user/u7/muellerw/gift-0.1.6pre/libGIFTAcPerl/cc/ -L/user/u7/muellerw/gift-0.1.6pre/libGIFTQuPerl/cc/ -L/user/u7/muellerw/gift-0.1.6pre/libGIFTAcInvertedFile/cc/ -L/user/u7/muellerw/gift-0.1.6pre/libGIFTAcHierarchy/cc/ -L/user/u7/muellerw/gift-0.1.6pre/libGIFTAcDistanceMatrix/cc/ -L/user/u7/muellerw/gift-0.1.6pre/libGIFTQuInvertedFile/cc/ -L/user/u7/muellerw/gift-0.1.6pre/libGIFTQuBayesian/cc/ -L/user/u7/muellerw/gift-0.1.6pre/libGIFTQuHierarchy/cc/ -L/user/u7/muellerw/gift-0.1.6pre/libGIFTAcURL2FTS/cc/ -L/user/u7/muellerw/gift-0.1.6pre/libMRML/cc/ -L/user/u7/muellerw/gift-0.1.6pre/libGIFTAcPerl/cc/ -L/user/u7/muellerw/gift-0.1.6pre/libGIFTQuPerl/cc/ -L/user/u7/muellerw/gift-0.1.6pre/libGIFTAcInvertedFile/cc/ -L/user/u7/muellerw/gift-0.1.6pre/libGIFTAcHierarchy/cc/ -L/user/u7/muellerw/gift-0.1.6pre/libGIFTAcDistanceMatrix/cc/ -L/user/u7/muellerw/gift-0.1.6pre/libGIFTQuInvertedFile/cc/ -L/user/u7/muellerw/gift-0.1.6pre/libGIFTQuBayesian/cc/ -L/user/u7/muellerw/gift-0.1.6pre/libGIFTQuHierarchy/cc/ -L/user/u7/muellerw/gift-0.1.6pre/libGIFTAcURL2FTS/cc/ -L -lGIFTQuPerl -lGIFTAcPerl -lMRML /unige/util/lib/perl5/5.00502/sun4-solaris-thread/auto/DynaLoader/DynaLoader.a -L/unige/util/lib/perl5/5.00502/sun4-solaris-thread/CORE -lperl -lsocket -lnsl -ldl -lm -lposix4 -lpthread -lc -lcrypt -lpthread -lsocket -lm ../libtool: null directory libtool: link: cannot determine absolute directory name of `' --- libMRML.la from corresponding compile: I see this dlname=''. However, it's also present in the stuff that compiled on my linux box. # libMRML.la - a libtool library file # Generated by ltmain.sh - GNU libtool 1.3c (1.854 2001/01/29 02:01:41) # # Please DO NOT delete this file! # It is necessary for linking the library. # The name that we can dlopen(3). dlname='' # Names of this library. library_names='libMRML.so.0.0.0 libMRML.so.0 libMRML.so' # The name of the static archive. old_library='libMRML.a' # Libraries that this one depends upon. dependency_libs=' -L/user/u7/muellerw/gift-0.1.6pre/libMRML/cc/ -L/user/u7/muellerw/gift-0.1.6pre/libGIFTAcPerl/cc/ -L/user/u7/muellerw/gift-0.1.6pre/libGIFTQuPerl/cc/ -L/user/u7/muellerw/gift-0.1.6pre/libGIFTAcInvertedFile/cc/ -L/user/u7/muellerw/gift-0.1.6pre/libGIFTAcHierarchy/cc/ -L/user/u7/muellerw/gift-0.1.6pre/libGIFTAcDistanceMatrix/cc/ -L/user/u7/muellerw/gift-0.1.6pre/libGIFTQuInvertedFile/cc/ -L/user/u7/muellerw/gift-0.1.6pre/libGIFTQuBayesian/cc/ -L/user/u7/muellerw/gift-0.1.6pre/libGIFTQuHierarchy/cc/ -L/user/u7/muellerw/gift-0.1.6pre/libGIFTAcURL2FTS/cc/ -lpthread -lsocket -lm' # Version information for libMRML. current=0 age=0 revision=0 # Is this an already installed library? installed=no # Files to dlopen/dlpreopen dlopen='' dlpreopen='' # Directory that this library needs to be installed in: libdir='/user/u7/muellerw/gift-install/lib' -- Wolfgang Müller, assistant-doctorant == PhD student (2001), teaching assistant Personal page: http://cui.unige.ch/~vision/members/WolfgangMueller.html Maintainer, GNU Image Finding Tool (http://www.gnu.org/software/gift) .&í¢fj)b b²ÒânÚ(!¶Úþf¢ ?¨¥©ÿ+-wèþX¶%
Re: bug in CVS version of yesterday
On Jan 31, 2001, Wolfgang Mueller <[EMAIL PROTECTED]> wrote:
> I get the following problem on a sun which has several versions of
> gcc.
I don't see any problem here. Or do you mean that gibberish after
your signature? :-)
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: Dynamically loading C++ Modules on Solaris
On 31 Jan 2001, Alexandre Oliva wrote: > Try adding -Wc,-mimpure-text to the command line. If it works, I'd > be willing to accept a patch that: > > (i) tests whether GCC supports it and use it to build shared > libraries. Only in this case should we set deplibs_check_method to > pass_all on Solaris with GCC in libtool.m4 > > (ii) in ltcf-c.sh, ltcf-cxx.sh and ltcf-gcj.sh, in the GCC section of > Solaris, adds -mimpure-text to archive_cmds if deplibs_check_method is > pass_all. I am not sure where you got the -Wc switch but it does not exist in gcc as far as I can tell. I set the environmental variable LDFLAGS to "-mimpure-text" before configuring and everything works fine now. Thanks for the tip. The best I can do, as I do not know how libtool works at all, is write a autoconf test which will try to create a shared library and if it fails try creating one with -mimpure-text and see if that works --- Kevin Atkinson kevina at users sourceforge net http://metalab.unc.edu/kevina/ ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
HEAD patches for AIX from Dan McNichol
I would like to check in the patches to the HEAD branch that Dan McNichol <[EMAIL PROTECTED]> sent in on January 10. If any one has any objections, speak now or forever hold your peace. -- Robert Boehne Software Engineer Ricardo Software Chicago Technical Center TEL: (630)789-0003 x. 238 FAX: (630)789-0127 email: [EMAIL PROTECTED] ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
RE: Fix for Arg list too long
Title: RE: Fix for Arg list too long -Original Message- From: Alexandre Oliva [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 31, 2001 1:27 PM To: Boehne, Robert Cc: '[EMAIL PROTECTED]' Subject: Re: Fix for Arg list too long On Jan 31, 2001, "Boehne, Robert" <[EMAIL PROTECTED]> wrote: > I have not had this problem with 'wc -c' but I did have it with `expr $cmd : > ".*"` You'd also have the problem with `$echo $cmd | wc -c' if echo is not a shell built-in, so you must take this possibility into account. > SGI was one system that would not allow me to use $reload_cmds because > $LD was set to CC. This is wrong. LD should be ld, not cc. That was a kludge we'd used in the beginning of ltcf-cxx.sh to reduce the divergence from ltcf-c.sh, but it no longer makes sense. We should go ahead and use CC wherever we use LD, and keep LD with a sane value, which is the name of the linker, not of the compiler. I definitely agree, I was suprised to see that $reload_cmds did not work unless it was hacked to use "ld". I also noticed that the expression at the top of ltcf-cxx.sh that sets $LD to MakeC++SharedLib under AIX has no effect (I guess I should fix that...). > I'm not sure I understand this, you're saying that some archivers can't > add several object files to an existing archive properly? They can. The problem is that -r is not reversible: as soon as you merge multiple object files into a single one, the linker will pull them all from the archive, instead of pulling only the ones that are actually needed. That's why I'd rather have object files added incrementally to static libraries, many at a time, but not by means of reloading. For shared libraries, this doesn't matter, since it's always linked as a whole. > #1) $old_archive_cmds will allow users to add objects to an existing > archive. I'm pretty sure this isn't true, but is there a way > to add objects to an archive for most supported archivers? This is true in general. There will probably be exceptions (Windows, for one), in which case we won't be able to do incremental adding of objects, and reloading will be needed. We'd set some new variable to tell libtool whether incremental archiving is possible or not. For archive libraries, I'm not creating reloadable object files, I'm just executing $old_archive_cmds in several steps, so pulling individual object files back out won't be a problem. After some checking I find that `expr "X$arg" : ".*"` fails when the command list is too long, much like a compiler does. So if we test for expr failing, that will tell us if the command line is too long. The only problem is that using this method we can't calculate beforehand how many steps we need to link in, we would have to break the object list in half, try that, then break that in half it if fails and so on. How can we do this without recursive functions?
