On Sun, Jun 11, 2006 at 04:33:05PM +0200, Steinar H. Gunderson wrote:
> chmod 644 debian/tmp/usr/lib/bigloo/2.7a/*
> find debian/tmp -name '*.css' | xargs chmod 644
> chmod: missing operand after `644'
>
> I'll investigate, but this seems rather odd to me.
The only .css file that is supposed to be in debian/tmp/ comes from
bde/bmem/, but for some reason, make consistently just ignores bde/bmem/.
Some investigation of bde/Makefile reveals:
dobmem:
@ if [ "$(LDPRELOADSUPPORT)" = "yes" ]; then \
(cd bmem && $(MAKE)) || exit 1; \
fi
I might not be the biggest fan of this kind of hiding stuff from the build
log. Anyhow, simple testing indicates that LDPRELOADSUPPORT is simply "no" on
my amd64 machine. And why is this? The output from the earlier buildd logs
contains:
nanosleep: yes
normal sleep: no
shared library: yes
ld preload: yes
dlopen: yes [-ldl]
but on my amd64 machine, I get
nanosleep: yes
normal sleep: no
shared library: no (because I don't know ld option)
dlopen: yes [-ldl]
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! :-) ) 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?
/* Steinar */
--
Homepage: http://www.sesse.net/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
