On June 22 2006, Nico asked a question similar to my current
question... and while he may have been able to resolve the situation
with the reply received from Ron @ sleepycat.com, I'm still
wondering....

My "make" run winds up with the following:

/usr/bin/ld: cannot find -ldb_cxx-4.4
collect2: ld returned 1 exit status

Like Nico, I configured Berkeley DB with C++ support and it appears to
have built normally.
In fact, the seemingly missing file 'libdb_cxx-4.4.so' does exist in my
/usr/local/BerkeleyDB.4.4/lib directory. /usr/local/BerkeleyDB.4.4/lib
is on my PATH environment variable and is what my other environment
variable LD_LIBRARY_PATH is set to. The file and its enclosing
directories are accessible for my user.

Here's the crucial part of Nico's example and post:
g++ -g -o prix_indexer prix_indexer.o helper.o subsequence.o
post_process.o -I/home/nico/prix/h -L/home/nico/bdb/lib
-I/home/nico/bdb/include -lm -lstdc++ -ldb -ldb_cxx -lpthread

If I take Nico's example and assume variables PATH and LD_LIBRARY_PATH
both contain the path that libdb_cxx.so lives in, isn't the "-ldb_cxx"
portion of the command adequate and supposed to resolve it?

Ron suggests that adding something similar as a component of the g++
command will likely fix it:

-L/usr/local/BerkeleyDB4.4 -ldb_cxx-4.4

Well, I would think that it would. I'll try and figure out how to
tell qmake to do that, but in the mean time why should it be necessary
when the PATH and LD_LIBRARY_PATH variables include the proper location
of the shared object?

I'm using Fedora Core 3, btw.

I would appreciate some insight. Ron? Nico? others?
Thank you.

-bC

consultmac2 wrote:
....
While the PATH environment variable would have no effect there (it's
only used for finding executables, not libraries), I would expect
LD_LIBRARY_PATH to have the desired effect. That said, I find the use
of LD_LIBRARY_PATH to usually cause more problems than it solves, at
least on platforms where it's used during both normal and runtime
linking, as it typically leads to the creation of executables that
don't work unless the LD_LIBRARY_PATH is also set at runtime.


I don't know how 'qmake' differs from normal (POSIX standard) make, but
typically this is done by adding the -L option to the LDFLAGS variable
and then including the LDFLAGS variable in the link commands, ala:

LDFLAGS = -L/usr/local/BerkeleyDB4.4

OBJS = foo.o
LIBS = -ldb_cxx-4.4

foo: $(OBJS)
$(CC) $(CPPFLAGS) $(CFLAGS) $(LDFLAGS) -o $@ $(OBJS) $(LIBS)


If the linker on your system isn't behaving the way you expect, you
should consult the newgroups for your OS (in this case,
comp.os.linux.*) or similar support channels. They're much more likely
to be able to provide an authoritative answer on why their tools behave
the way you experience.


Philip Guenther