Strange Solaris non-problem

Strange Solaris non-problem

[murray]

I am building C++ programs using a free third party toolkit (no source
code) which includes several unique libraries, as well as their own(?)
libC, libCrun and libCstd. They only certify the use of their toolkit
with the Sun compiler, but I have found that since gcc 3.2 I can build
perfectly usable executables using gcc and a handful of alterations to
the makefiles.

I started using their latest version (running on a Blade 1000 Sparc with
Solaris 8), and encountered unresolved symbols which pointed at their
version of libCrun.so. As one of a number of experiments I explicitly
included /usr/lib/libCrun.so (instead of -lCrun) as the last entry in
the list of libraries in the makefile and voila! it builds and runs
correctly.

When I ldd the program it is using the vendors libCrun, not the systems
(in spite of the above).

I have no complaints about the program working, but I don't understand
what just happened. Could someone offer any comment? Have I left a
problem here which might bite me later?

I am using gcc 3.2.2 from SunFreeware, and it uses the as and ld in
/usr/ccs/bin.

regards
Graeme Murray

Re: Strange Solaris non-problem

[John Love-Jensen]

Hi Graeme,

> I have no complaints about the program working, but I don't understand
> what just happened. Could someone offer any comment? Have I left a
> problem here which might bite me later?

Which .so is used is dependent on your LD_LIBRARY_PATH when the application
is run.

If you want a specific path (absolute or relative) for your shared library
resolution, use the -rpath parameter in your build, using GNU ld.

There are a couple security concerns using a relative rpath.  On a secure
machine, that shouldn't be a problem.

--Eljay