Subject: rpath flags vs wrapper scripts
To: None <tech-pkg@NetBSD.org>
From: Dan McMahill <dmcmahill@NetBSD.org>
Date: 10/30/2005 17:19:16
I have a problem and am not sure what the best way to fix it is. I'm
working on a couple of new packages for which I am also the author so I
have control over fixing in pkgsrc or the upstream sources depending on
which makes the most sense.
I'll use the real names of the packages even though they have not yet
been comitted to pkgsrc.
cad/libwcalc -- installs a library and some other assorted files
including a wcalc-config script. During the configure stage, libwcalc
tries to determine what rpath flags the compiler may accept using
autoconf and trying to link with things like '-Wl,-rpath -Wl,path' or
'-Rpath' until it finds one that the compiler doesn't complain about.
During the '-Wl,-rpath -Wl,path' test, the wrapper scripts simply eat
this part of the gcc command line so of course no complaint is returned.
The configure script then happily sticks that into the wcalc-config
cad/gtk-wcalc -- builds ok, but when it tries to link it uses
`wcalc-config --libs` as part of its link command line. Now you get
-Wl,-rpath -Wl,/usr/pkg/lib and gcc on solaris pukes with:
ld: fatal: option -dn and -P are incompatible
ld: fatal: Flags processing errors
collect2: ld returned 1 exit status
In fact, a simple thing like:
gcc -o foo foo.c -Wl,-rpath -Wl,path
will cause those same errors.
Looking at the .work.log file shows that -Wl,-rpath -Wl,/usr/pkg/lib was
simply passed on to the compiler command line.
So, whats the best way to fix this?
1) maybe wcalc-config should't try to include any rpath flags and leave
it up to the programs which link to it. Of course since the wrapper
scripts seem to get tripped up sometimes during my rpath tests, I'm not
sure this will work right.
2) some magic variable in cad/libwcalc/Makefile or
cad/gtk-wcalc/Makefile that causes either the first autoconf test to
give more accurate results or to fix up the command on the second?