FreeTDS Development Group

[Frediano Ziglio <freddyz77 AT tin.it>]

Il ven, 2004-12-03 alle 17:59, Lowden, James K ha scritto:
> > From: ZIGLIO, Frediano, VF-IT
> > Sent: Friday, December 03, 2004 5:44 AM
> > 
> > Just to sum up a bit. Problem reside in how iconv are searched and how
> > libtool in NetBSD works.
> > Library directory used in --with-iconv-prefix are added to LDFLAGS
> > (acinclude.m4).
> > In src/apps/Makefile.in LDFLAGS it's expanded BEFORE tsql_LIBADD so
> you
> > have
> > 
> > /bin/sh ../../libtool --mode=link cc  -O2 -pipe -L/usr/local/lib \
> >     -o tsql  tsql.o -lncurses  -lreadline ../tds/libtds.la  -lc
> > 
> > (As you can see -L/usr/local/lib it's before ../tds/libtds.la)
> > 
> > However it's expanded in
> > 
> >   cc -O2 -pipe -o .libs/tsql tsql.o  -L/usr/local/lib -lncurses \
> >     -lreadline -L../tds/.libs -ltds -liconv -Wl,-rpath,/usr/local/lib
> > 
> > As you can see there is -ltds so if a libtds.so.1.0.0 it's present in
> > /usr/local/lib this it's used for linking.
> > A solution (as stated by Joshua) it's to move -L/usr/local/lib after
> > -ltds like
> > 
> >   cc -O2 -pipe -o .libs/tsql tsql.o  -lncurses -lreadline \
> >     -L../tds/.libs -ltds -L/usr/local/lib -liconv
> > -Wl,-rpath,/usr/local/lib
> > 
> > so the solution it's to not add -L/usr/local/lib to LDFLAGS and add
> this
> > to another variable expanded after -ltds.
> > I proposed this patch but I didn't fully test it (I don't have NetBSD
> > and my system use relative path in library include)...
> 
> I don't think your analysis is exactly correct.  There are two issues:
> 
> 1.  The order in which the linker searches directories for a library.
> 2.  The order in which the linker links the objects.  
> 
> AIUI, the linker processes all options before it begins its work.  That
> means all the -L options are applied to the library search path before
> linking actually starts.  It matters what order the -L options are in
> (and what order the -l options are in), but not where -L and -l are
> relative to each other.  
> 
> That is, you get the same effect if you use  
> 
>       "-L A -L B -lx -ly" 
> or 
>       "-L A -lx -ly -L B"
> 
> If we can get -L../tds/.libs placed as the first -L option, and -L
> ../replacements/.libs as the last one, we'd be in good shape.  tsql
> would link first time, every time.  
> 
> We're surely going to have to tell libtool what search path to use.  It
> can't guess.  
> 

I think you are right. 

Now it's -La -lx -Lb -ly and we want something like -Lb -La -lx -ly (-Lb
before -La) from src/app/Makefile.in (similar to all Makefile.in)

tsql$(EXEEXT): $(tsql_OBJECTS) $(tsql_DEPENDENCIES)
        @rm -f tsql$(EXEEXT)
        $(LINK) $(tsql_LDFLAGS) $(tsql_OBJECTS) $(tsql_LDADD) $(LIBS)

LINK = $(LIBTOOL) --mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) \
        $(AM_LDFLAGS) $(LDFLAGS) -o $@

CCLD = $(CC)

LDFLAGS = @LDFLAGS@

tsql_LDFLAGS =

tsql_LDADD = $(READLINE_LIBS) $(LDADD) $(NETWORK_LIBS)

tsql_OBJECTS = tsql.$(OBJEXT)

LIBS = @LIBS@

LDADD = ../tds/libtds.la

So we have, expanding first

tsql$(EXEEXT): tsql.$(OBJEXT) $(tsql_DEPENDENCIES)
        @rm -f tsql$(EXEEXT)
        $(LIBTOOL) --mode=link $(CC) $(AM_CFLAGS) $(CFLAGS) \
        $(AM_LDFLAGS) @LDFLAGS@ -o $@ tsql.$(OBJEXT) $(READLINE_LIBS) 
../tds/libtds.la $(NETWORK_LIBS) @LIBS@

libtool expand (on NetBSD) ../tds/libtds.la in -L../tds -ltds so if we
want to move -L/usr/local/lib after -L../tds we have to move it in
NETWORK_LIBS or in @LIBS@. I suggest to change library inclusion in
priority order putting ours libraries before like

tsql_LDADD = $(LDADD) $(READLINE_LIBS) $(NETWORK_LIBS)

so -Lxx options in READLINE_LIBS/NETWORK_LIBS/LIBICONV (at this point
why not ICONV_LIBS) get lower priority. It's also not recommended to use
LDFLAGS to put global options (info suggest to use AM_LDFLAGS however it
do not suit our purpose), this should be left to user (like CFLAGS) 

freddy77