probably an old question about overriding hardcoded library search paths

probably an old question about overriding hardcoded library search paths

[Charles Smith]

How can I force a private copy of sqlite3 to be linked to my
application?

My ubuntu 10.04 system has sqlite3 in /usr/local/lib and /usr/lib.
I want to link my application with a private version of sqlite3.
Using -L and -l doesn't work because the additional directory is
"appended" to the search path.  The g++ compiler always links with
/usr/local/lib or (if I move that out of the way) /usr/lib.  When I
move both out of the way, the application links successfully.  But
then, the system is useless for most other uses.

Under "3.13 Options for Linking", the gcc manual lists these options.
An excerpt of the result is shown for both.


-nostdlib
    ./flat/layer_mgmt.o: In function `__static_initialization_and_destruction_0':
/usr/include/c++/4.4/iostream:72: undefined reference to `__dso_handle'


-nodefaultlibs
    ...
    /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 22 has invalid symbol index 22




Interestingly "g++ -print-search-dirs" does not show /usr/local/lib.

install: /usr/lib/gcc/i486-linux-gnu/4.4.3/
programs: =/usr/lib/gcc/i486-linux-gnu/4.4.3/:/usr/lib/gcc/i486-linux-gnu/4.4.3/:/usr/lib/gcc/i486-linux-gnu/:/usr/lib/gcc/i486-linux-gnu/4.4.3/:/usr/lib/gcc/i486-linux-gnu/:/usr/libexec/gcc/i486-linux-gnu/4.4.3/:/usr/libexec/gcc/i486-linux-gnu/:/usr/lib/gcc/i486-linux-gnu/4.4.3/:/usr/lib/gcc/i486-linux-gnu/:/usr/lib/gcc/i486-linux-gnu/4.4.3/../../../../i486-linux-gnu/bin/i486-linux-gnu/4.4.3/:/usr/lib/gcc/i486-linux-gnu/4.4.3/../../../../i486-linux-gnu/bin/
libraries: =/usr/lib/gcc/i486-linux-gnu/4.4.3/:/usr/lib/gcc/i486-linux-gnu/4.4.3/:/usr/lib/gcc/i486-linux-gnu/4.4.3/../../../../i486-linux-gnu/lib/i486-linux-gnu/4.4.3/:/usr/lib/gcc/i486-linux-gnu/4.4.3/../../../../i486-linux-gnu/lib/../lib/:/usr/lib/gcc/i486-linux-gnu/4.4.3/../../../i486-linux-gnu/4.4.3/:/usr/lib/gcc/i486-linux-gnu/4.4.3/../../../../lib/:/lib/i486-linux-gnu/4.4.3/:/lib/../lib/:/usr/lib/i486-linux-gnu/4.4.3/:/usr/lib/../lib/:/usr/lib/i486-linux-gnu/i486-linux-gnu/4.4.3/:/usr/lib/i486-linux-gnu/../lib/:/usr/lib/gcc/i486-linux-gnu/4.4.3/../../../../i486-linux-gnu/lib/:/usr/lib/gcc/i486-linux-gnu/4.4.3/../../../:/lib/:/usr/lib/:/usr/lib/i486-linux-gnu/

Is there a way to do this other than understanding the internal architecture of the gcc installation?

TIA

Re: probably an old question about overriding hardcoded library search paths

[Marc Glisse]

On Sun, 11 Nov 2012, Charles Smith wrote:

> How can I force a private copy of sqlite3 to be linked to my
> application?

You can always pass /path/to/libA.a instead of -L/path/to -lA.

> My ubuntu 10.04 system has sqlite3 in /usr/local/lib and /usr/lib.
> I want to link my application with a private version of sqlite3.
> Using -L and -l doesn't work because the additional directory is
> "appended" to the search path.

No. It might give priority to dynamic libraries over static ones though.
See -Bstatic in the documentation of the linker.

-- 
Marc Glisse

Re: probably an old question about overriding hardcoded library search paths

[Charles Smith]

Thank you for your response.  When the -L option is specified, where does the new directory go, if not on the end of the list?

In fact, I'd tried your first suggestion prior to posting and I thought I got multiple definitions.  But in response to your suggestion, I tried again, and it looks like it did work.  So, I must have made a mistake elsewhere.  So it looks at this point.

Thank you.

--- On Sun, 11/11/12, Marc Glisse <marc.glisse@inria.fr> wrote:

> From: Marc Glisse <marc.glisse@inria.fr>
> Subject: Re: probably an old question about overriding hardcoded library search paths
> To: "Charles Smith" <cts.private@yahoo.com>
> Cc: gcc-help@gcc.gnu.org
> Date: Sunday, November 11, 2012, 6:52 AM
> On Sun, 11 Nov 2012, Charles Smith
> wrote:
> 
> > How can I force a private copy of sqlite3 to be linked
> to my
> > application?
> 
> You can always pass /path/to/libA.a instead of -L/path/to
> -lA.
> 
> > My ubuntu 10.04 system has sqlite3 in /usr/local/lib
> and /usr/lib.
> > I want to link my application with a private version of
> sqlite3.
> > Using -L and -l doesn't work because the additional
> directory is
> > "appended" to the search path.
> 
> No. It might give priority to dynamic libraries over static
> ones though.
> See -Bstatic in the documentation of the linker.
> 
> -- Marc Glisse
> 

Re: probably an old question about overriding hardcoded library search paths

[Jonathan Wakely]

On 11 November 2012 15:12, Charles Smith wrote:
> Thank you for your response.  When the -L option is specified, where does the new directory go, if not on the end of the list?

There are two lists, the user-specified directories and the built-in
ones such as /usr/lib. If you use -L it adds a directory to the end of
the first list, but that still comes before the built-in ones.

Re: probably an old question about overriding hardcoded library search paths

[Charles Smith]

I confess I'm confused.

I thought that it worked, but now it's not working any more:

g++ \
        -L"/home/me/dir1" \
        -L"/home/me/dir2" \
        -L"/home/me/dirn" \
        /home/me/opt/lib/libsqlite3.a \
        -o "FLAT"   ./a.o ./b.o    -llib1 -llib2 -llibn
/home/me/dir2/liblib2.a(layer.o): In function `Entity::get_ip_config(char*)':
/home/me/a.cc:86: undefined reference to `sqlite3_open_v2'


--- On Sun, 11/11/12, Marc Glisse <marc.glisse@inria.fr> wrote:

> From: Marc Glisse <marc.glisse@inria.fr>
> Subject: Re: probably an old question about overriding hardcoded library search paths
> To: "Charles Smith" <cts.private@yahoo.com>
> Cc: gcc-help@gcc.gnu.org
> Date: Sunday, November 11, 2012, 6:52 AM
> On Sun, 11 Nov 2012, Charles Smith
> wrote:
> 
> > How can I force a private copy of sqlite3 to be linked
> to my
> > application?
> 
> You can always pass /path/to/libA.a instead of -L/path/to
> -lA.
> 
> > My ubuntu 10.04 system has sqlite3 in /usr/local/lib
> and /usr/lib.
> > I want to link my application with a private version of
> sqlite3.
> > Using -L and -l doesn't work because the additional
> directory is
> > "appended" to the search path.
> 
> No. It might give priority to dynamic libraries over static
> ones though.
> See -Bstatic in the documentation of the linker.
> 
> -- Marc Glisse
> 

Re: probably an old question about overriding hardcoded library search paths

[Jonathan Wakely]

On 11 November 2012 20:27, Charles Smith wrote:
> I confess I'm confused.
>
> I thought that it worked, but now it's not working any more:
>
> g++ \
>         -L"/home/me/dir1" \
>         -L"/home/me/dir2" \
>         -L"/home/me/dirn" \
>         /home/me/opt/lib/libsqlite3.a \
>         -o "FLAT"   ./a.o ./b.o    -llib1 -llib2 -llibn
> /home/me/dir2/liblib2.a(layer.o): In function `Entity::get_ip_config(char*)':
> /home/me/a.cc:86: undefined reference to `sqlite3_open_v2'

You need to list the library after the objects that depend on it.

The linker doesn't know it needs sqlite3_open_v2 until it sees a.o, by
which point it's already looked at libsqlite3.a and decided it doesn't
need any of its symbols.

Re: probably an old question about overriding hardcoded library search paths

[Marc Glisse]

On Sun, 11 Nov 2012, Charles Smith wrote:

> I confess I'm confused.
>
> I thought that it worked, but now it's not working any more:
>
> g++ \
>        -L"/home/me/dir1" \
>        -L"/home/me/dir2" \
>        -L"/home/me/dirn" \
>        /home/me/opt/lib/libsqlite3.a \
>        -o "FLAT"   ./a.o ./b.o    -llib1 -llib2 -llibn
> /home/me/dir2/liblib2.a(layer.o): In function `Entity::get_ip_config(char*)':
> /home/me/a.cc:86: undefined reference to `sqlite3_open_v2'

If A depends on B, put -lA before -lB...

-- 
Marc Glisse

Re: probably an old question about overriding hardcoded library search paths

[Charles Smith]

God, you guys are fast!

Okay, I tried that, and then it came up with - first, the pthread library was missing, and then when I added -lpthread (maybe the dynamic version had brought that in?) - these were missing:
/home/me/opt/lib/libsqlite3.a(sqlite3.o): In function `unixDlError':
/home/me/opt/sqlite-3.6.19/sqlite3.c:25735: undefined reference to `dlerror'
/home/me/opt/lib/libsqlite3.a(sqlite3.o): In function `unixDlSym':
/home/me/opt/sqlite-3.6.19/sqlite3.c:25762: undefined reference to `dlsym'
/home/me/opt/lib/libsqlite3.a(sqlite3.o): In function `unixDlClose':
/home/me/opt/sqlite-3.6.19/sqlite3.c:25766: undefined reference to `dlclose'
/home/me/opt/lib/libsqlite3.a(sqlite3.o): In function `unixDlOpen':
/home/me/opt/sqlite-3.6.19/sqlite3.c:25721: undefined reference to `dlopen'

I added -ldl and it then linked.

Funny.  I guess the dynamic version of sqlite provides those, but my other shared libraries don't?



--- On Sun, 11/11/12, Marc Glisse <marc.glisse@inria.fr> wrote:

> From: Marc Glisse <marc.glisse@inria.fr>
> Subject: Re: probably an old question about overriding hardcoded library search paths
> To: "Charles Smith" <cts.private@yahoo.com>
> Cc: gcc-help@gcc.gnu.org
> Date: Sunday, November 11, 2012, 12:30 PM
> On Sun, 11 Nov 2012, Charles Smith
> wrote:
> 
> > I confess I'm confused.
> >
> > I thought that it worked, but now it's not working any
> more:
> >
> > g++ \
> >        -L"/home/me/dir1" \
> >        -L"/home/me/dir2" \
> >        -L"/home/me/dirn" \
> >       
> /home/me/opt/lib/libsqlite3.a \
> >        -o
> "FLAT"   ./a.o ./b.o    -llib1
> -llib2 -llibn
> > /home/me/dir2/liblib2.a(layer.o): In function
> `Entity::get_ip_config(char*)':
> > /home/me/a.cc:86: undefined reference to
> `sqlite3_open_v2'
> 
> If A depends on B, put -lA before -lB...
> 
> -- 
> Marc Glisse
>

Re: probably an old question about overriding hardcoded library search paths

[Jonathan Wakely]

On 11 November 2012 20:41, Charles Smith <cts.private@yahoo.com> wrote:
> God, you guys are fast!
>
> Okay, I tried that, and then it came up with - first, the pthread library was missing, and then when I added -lpthread (maybe the dynamic version had brought that in?) - these were missing:
> /home/me/opt/lib/libsqlite3.a(sqlite3.o): In function `unixDlError':
> /home/me/opt/sqlite-3.6.19/sqlite3.c:25735: undefined reference to `dlerror'
> /home/me/opt/lib/libsqlite3.a(sqlite3.o): In function `unixDlSym':
> /home/me/opt/sqlite-3.6.19/sqlite3.c:25762: undefined reference to `dlsym'
> /home/me/opt/lib/libsqlite3.a(sqlite3.o): In function `unixDlClose':
> /home/me/opt/sqlite-3.6.19/sqlite3.c:25766: undefined reference to `dlclose'
> /home/me/opt/lib/libsqlite3.a(sqlite3.o): In function `unixDlOpen':
> /home/me/opt/sqlite-3.6.19/sqlite3.c:25721: undefined reference to `dlopen'
>
> I added -ldl and it then linked.
>
> Funny.  I guess the dynamic version of sqlite provides those, but my other shared libraries don't?

The dynamic version probably doesn't provide them, but has a
dependency on libpthread and libdl that causes the runtime linker to
link to it at runtime.  Run ldd on libsqllite3.so and you'll probably
see it depends on libpthread.so and libdl.so, run readelf -d
libsqlite3.so and you'll see the libs it needs.