Re: [Autogen-users] AutoOpt-Question

[Bruce Korb]

Daniel Schregenberger wrote:

> As with pre1 I am getting errors when compiling:
> 
> Making all in autoopts
> make[2]: Entering directory `/home/npfdd/autogen-5.5.3pre2/autoopts'
> Making all in test
> make[3]: Entering directory `/home/npfdd/autogen-5.5.3pre2/autoopts/test'
> make[3]: Nothing to be done for `all'.
> make[3]: Leaving directory `/home/npfdd/autogen-5.5.3pre2/autoopts/test'
> make[3]: Entering directory `/home/npfdd/autogen-5.5.3pre2/autoopts'

> + cd /home/npfdd/autogen-5.5.3pre2/pkg/libopts-19.0.10
> + /home/npfdd/autogen-5.5.3pre2/agen5/autogen -L
> /home/npfdd/autogen-5.5.3pre2/config --writable
> Automated Options Processing Error!
> lt-autogen called optionProcess with structure version 19:0:10.
> This exceeds the compiled library version:  18:6:9

This is a libtool problem that I do not understand.
``/home/npfdd/autogen-5.5.3pre2/agen5/autogen''  is actually a script
that is supposed to set up LD_LIBRARY_PATH in a fashion such that the
actual binary (/home/npfdd/autogen-5.5.3pre2/agen5/.libs/lt-autogen)
will find the shared libraries in the autoopts directory 
(/home/npfdd/autogen-5.5.3pre2/autoopts/.libs).  Since we are adding
new bits to the interface, I need to bump the version.  It will work
if you configure with --disable-shared, but it is *supposed* to work
as is.

$ libtool --version
ltmain.sh (GNU libtool) 1.4.3 (1.922.2.110 2002/10/23 01:39:54)

It works, somehow, for me, but there is some mysterious environmental
difference and I do not know the cause.


___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: [Fwd: libtool munges '-(' linker options.]

[Scott James Remnant]

On Sun, 2002-12-15 at 17:09, Albert Chin wrote:

> On Sun, Dec 15, 2002 at 04:42:42PM +, Scott James Remnant wrote:
> > Certain applications require the linker flags --start-group
> > and --end-group (abbreviated "-(" and "-)" ) in order to
> > resolve circular references between libraries.  However,
> > libtool "sorts" these flags and places them at the beginning
> > of the command-line, destroying their utility.  At the end
> > of this report is a uuencoded archive containing three
> > source files and a Makefile demonstrating the problem.
> > We end up with an archive A.a which uses symbols defined in B.a
> > and an archive B.a which uses symbols defined in A.a --- a
> > circular dependency.  The command:
> >   gcc -o foo c.o -Wl,"-(" A.a B.a -Wl,"-)"
> > correctly builds these archives into an executable by telling
> > ld that it should iterate over A.a and B.a to resolve all
> > circular references, instead of ld's usual search-once strategy.
> > However:
> >   libtool gcc -o foo c.o -Wl,"-(" A.a B.a -Wl,"-)"
> > yields:
> >   $ libtool gcc -o foo c.o -Wl,"-(" A.a B.a -Wl,"-)"
> >   gcc -o foo c.o -Wl,"-(" -Wl,"-)"  A.a B.a
> >   B.a(b.o): In function `b':
> >   b.o(.text+0x1b): undefined reference to `a'
> >   collect2: ld returned 1 exit status
> > 
> > As you can see, libtool re-orders the -( and -) flags, destroying
> > their function.  This is a bug in libtool (and it's making my
> > life quite difficult at the moment).
> 
> Why not invoke libtool as:
>   $ libtool gcc -o foo c.o -Wl,"-(",A.a,B.a,"-)"
> 
It actually turns out they weren't using ".a" files but ".la" files
instead.

I've received the following follow-up:

8<8<8<8<8<8<8<
Your proposed solution will not work.  The complete command-line from my
application is:
   $(LIBTOOL) --mode=link $(CC) $(STATIC_FLAG) $(AM_CFLAGS) $(CFLAGS) \
 $(LDFLAGS) -o $@ -Wl,-Tinclude/asm/link-script "-Wl,-(" \
 src/libflexc0.la $< src/libflexc1.la "-Wl,-)" @GC_LIB@ @LIBS@

Note that the ".la" files cannot be passed unmodified to the linker.
libtool *must* munge these appropriately *without* affecting the order
in which the -( flags are passed.  The patch I provided does solve this
problem.
>8>8>8>8>8>8>8

Any further ideas?

Scott
-- 
Scott James Remnant Have you ever, ever felt like this?  Had strange
http://netsplit.com/  things happen?  Are you going round the twist?


signature.asc
Description: This is a digitally signed message part
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool