On Sun, Jun 11, 2006 at 05:18:17PM +0200, Steinar H. Gunderson wrote:
> Not good, not good. (I might add that a build system signalling "can't build
> shared libraries" by "no .css files" might not be perceived as very robust,
> though! :-) )
Right - I, for sure, know the bigloo build system does not exactly
meets the criteria to get labelled as robust, and stderr regularly
getting thrown to /dev/null really does not help...
> More tracing leads to the following invocation from configure:
>
> ./autoconf/ldshare --user=root --tmp=/tmp --cc=gcc --ld=ld --ldopt=
> --ldlibs=-lc --sharedsuffix=so
>
> which seems to do a test if it can compile a shared library, using a command
> line that boils down to this:
>
> + ld -shared -o actestroot.so actestroot-lib.o -lc
> ld: actestroot-lib.o: relocation R_X86_64_32 against `a local symbol' can
> not be used when making a shared object; recompile with -fPIC
> actestroot-lib.o: could not read symbols: Bad value
>
> In other words, it fails due to missing -fPIC on compiling a C library. But
> the build logs seem to indicate that it can indeed use -fPIC; but for some
> reason, on my amd64, it adds -DBGL_NO_PIC instead of -fPIC. More delving into
> the configure system indicates that this is governed by a "$cpicflags". This
> is by default "demanded" and then attempted figured out by the following
> evilness:
>
> # The -pic C compiler options
> if [ "$cpicflags" = "no" ]; then
> cpicflags=""
> else
> if [ "$ldopt" = "no-share" ]; then
> cpicflags="" [later gets changed to -DBGL_NO_PIC]
> else
> [stuff to run autoconf/ccpic here]
>
> Full circle -- it sets ldopt="no-share" because it fails due to missing
> -fPIC, and it won't add -fPIC since ldopt is "no-share".
>
> It seems to be the best thing to do would be to help it on its way, and set
> cpicflags="-fPIC" from the start. Now, this is already done in debian/rules
> for arm:
>
> ARCH=$(shell dpkg-architecture -qDEB_BUILD_ARCH)
> ifeq (${ARCH},arm)
> #CC=gcc-3.2
> EXTRA_CONFIG_FLAGS += --coflags=-O2 --cpicflags=-fPIC
> else
> #CC=gcc
> endif
>
> Makes me wonder why it's not default, if it's a known problem. Simply
> removing the if test and always send -fPIC seems to be the most sane solution
> to me. Any objections?
Well, the whole PIC issue is quite messy and has a heavy history in
this package. The whole idea behind this test was, IIRC, that non-PIC
code is really faster, and upstream really makes lots of such perf
tuning.
But I thought this test was completely uneffective these days, since
all platforms got built with -fPIC - possibly I got it wrong. Forcing
-fPIC may be the easy way out.
Best regards,
--
Yann Dirson <[EMAIL PROTECTED]> |
Debian-related: <[EMAIL PROTECTED]> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
