solaris recording name conflict when building newer versions of system libraries

[Tim Mooney]

All-

I'm getting the "recording name conflict" error from the Solaris linker,
as invoked by libtool 2.4.2, and I'm hoping someone can provide some
suggestions for how to work around this issue.

I've been building software on Solaris for years, including software
that uses libtool.  I remember what it was like before libtool, so I'm
thankful that libtool exists, even when current libtool is doing something
I dislike.  :-)

I'm starting to build some software on OpenIndiana, which is one of the
distributions that came out of the former OpenSolaris initiative.  I'm
using Oracle's Studio 12.3 compiler suite and the standard linker (not GNU
ld).

Unlike e.g. Solaris 10, OpenIndiana comes with quite a lot of opensource
software installed under /usr.  This is causing some build problems for
me that I generally did not encounter under previous versions of Solaris.

I'm trying to build newer versions of some of packages, for installation
under /local, but I'm encountering a problem at link time because the
linker detects that there's already a shared object in the system
directory with the same soname.

In this particular case, I'm trying to build a newer version of cairo,
but during the build, tools that should link with the newly-built
libcairo fail:

libtool: link: cc -xO4 -xipo=2 -D_REENTRANT -D_PTHREADS -D_REENTRANT 
-D_POSIX_PTHREAD_SEMANTICS -I/local/gnu/include/gio-unix-2.0/ 
-I/local/gnu/include/glib-2.0 -I/local/gnu/lib/64/glib-2.0/include 
-I/local/include/pixman-1 -I/usr/include/librsvg-2.0 -I/usr/include/gtk-2.0 
-I/usr/lib/amd64/gtk-2.0/include -I/usr/include/gtk-2.0 
-I/usr/include/pango-1.0 -I/usr/include/cairo -I/usr/include/freetype2 
-I/usr/include/libpng14 -Xa -xO4 -xipo=2 -xstrconst -KPIC -mt -xtarget=native 
-m64 -xarch=native -I/local/include -I/local/gnu/include -I/local/include 
-D_POSIX_PTHREAD_SEMANTICS -o .libs/any2ppm any2ppm-any2ppm.o  -L/local/lib/64 
-L/local/gnu/lib/64 ../util/cairo-script/.libs/libcairo-script-interpreter.so 
-L/usr/local/lib/64 -L/usr/lib/amd64 
/local/src/RPM/BUILD/cairo-1.12.14/src/.libs/libcairo.so 
../src/.libs/libcairo.so -ldl -lGL -lrsvg-2 -lgdk-x11-2.0 -lgdk_pixbuf-2.0 
-lpangocairo-1.0 -lpango-1.0 /local/gnu/lib/64/libgio-2.0.so -lsocket -lresolv 
/local/gnu/lib/64/libgmodule-2.!
0.so -lXext -lXinerama -lXi -lXrandr -lXcursor -lXcomposite -lXdamage -lXfixes 
-lcairo /local/gnu/lib/64/libgobject-2.0.so /local/gnu/lib/64/libgthread-2.0.so 
-lffi /local/gnu/lib/64/libglib-2.0.so -lpthread -lthread 
/local/gnu/lib/64/libintl.so -lc /local/lib/64/libpixman-1.so -lfontconfig 
-lexpat -lfreetype -lbz2 -lpng14 -lz -lXrender -lX11 -lrt -lm -mt 
-R/local/lib/64 -R/local/gnu/lib/64 -R/usr/lib/amd64
ld: warning: file ../src/.libs/libcairo.so: linked to 
/local/src/RPM/BUILD/cairo-1.12.14/src/.libs/libcairo.so: attempted multiple 
inclusion of file
ld: fatal: recording name conflict: file 
'/local/src/RPM/BUILD/cairo-1.12.14/src/.libs/libcairo.so' and file 
'/usr/lib/amd64/libcairo.so' provide identical dependency names: libcairo.so.2  
(possible multiple inclusion of the same file)
ld: fatal: file processing errors. No output written to /dev/null
/opt/SUNWspro/prod/bin/ipo: Error inside  /usr/ccs/bin/ld
cc: ipo failed for .libs/any2ppm
gmake[4]: *** [any2ppm] Error 2

Anyone have any suggestions for how I work around this?

Unfortunately, many of the OpenIndiana system packages don't split into
"runtime" and "devel" packages, so where it would be possible to work
around something like this on other platforms by removing the system's devel
package, here I can't.  The package '/library/desktop/cairo' includes all
of cairo, including the parts that other platforms would split into a
separate devel package.

I can get the link to proceed if I manually copy what libtool is doing,
and then change

        /local/src/RPM/BUILD/cairo-1.12.14/src/.libs/libcairo.so 
../src/.libs/libcairo.so

to

        -L/local/src/RPM/BUILD/cairo-1.12.14/src/.libs -lcairo

The question is, is there any way to get libtool to do that automatically
on Solaris?

If I need to hack my local copy of libtool to do that (and then
re-libtoolize projects that run into this issue, so that they're using
my hacked libtool), can anyone point me at places in the libtool source
where I should look to make this change?

Tim
--
Tim Mooney                                             address@hidden
Enterprise Computing & Infrastructure                  701-231-1076 (Voice)
Room 242-J6, IACC Building                             701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164