[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gcl-devel] Re: Issue to build GCL on Mandrake linux distro
From: |
Paul Zimmermann |
Subject: |
Re: [Gcl-devel] Re: Issue to build GCL on Mandrake linux distro |
Date: |
Wed, 19 Nov 2003 17:40:18 +0100 |
Dear Camm,
From: Camm Maguire <address@hidden>
Date: 19 Nov 2003 09:35:16 -0500
Greetings, and thanks as always for your helpful reports!
As you know by now, axiom starts by building GCL. I cannot tell from
the log you've posted whether this stage has been completed or not.
Clearly the problem happens during the GCL configure (i.e.
before GCL is built).
It is most helpful for me (as a GCL developer) to see output from the
GCL ./configure stage through the creation of
lsp/gcl-2.6.1/unixport/saved_gcl.
The sed commands are issued by configure, not make, as they make the
"make" related files and headers from the corresponding ".in"
files. The "unterminated sed command" indicates that one of the
variables configure tried to determine automatically has been
corrupted, usually by capturing stray puctuation characters. With
great probability, this is the step trying to determine where your
static bfd and iberty libs are kept. This is normally
/usr/lib/libbfd.a and /usr/lib/libiberty.a. configure tries to
determing this by creating a dummy foo.c file:
echo 'int main() {bfd_init();bfd_openr("/dev/null",0);return 0;}'
>foo.c
and then parsing the output of
gcc -Wl,-M -static -o foo.o foo.c -lbfd -liberty
to see where gcc found the libs. This command is run through:
2>&1 | tr '()' '\012\012' | $AWK '{print $NF}' | sort | uniq
in 2.6.1-18. I've recently added for the utexas people an additional
filter:
2>&1 | grep -v : | tr '()' '\012\012' | $AWK '{print $NF}' | sort | uniq
If you wanted, you could change the line in configure.in to look like
the above, run autoconf, and then ./configure in the gcl-2.6.1
directory and see if the "unterminated sed" message vanishes.
Alternatively, you can make the foo.c, run the gcc command, pipe it
though your existing filter, and let me know the results. We can then
get this to work automatically on Mandrake.
One problem is that when I run ./configure in gcl-2.6.1, it works...
but it does not when called by the main Axiom "make" (file
lsp/Makefile) so it is not only a gcl problem...
I modified lsp/Makefile so that it does not extract gcl-2.6.1.tgz,
thus does not override gcl-2.6.1/configure.in, and copied the file
$tmp/subs-$ac_sed_frag.sed in /tmp/toto.sed before sed -f was called.
The culprit is the following:
[...]
s,@ECHO_T@,,;t t
s,@LIBS@, -lm ../libbfd.a
/usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.2/../../../libbfd.a
/usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.2/../../../libiberty.a -lreadline
-lncurses,;t t
s,@VERSION@,2.6.1,;t t
[...]
When I compiled the above foo.c, I get:
norroy% gcc -Wl,-M -static -o foo.o foo.c -lbfd -liberty
Archive member included because of file (symbol)
/usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.2/../../../libbfd.a(init.o)
/tmp/cc6jJptq.o (bfd_init)
/usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.2/../../../libbfd.a(opncls.o)
/tmp/cc6jJptq.o (bfd_openr)
... (and so on)
(No need to say the grep -v patch does not work.)
When the configure is started as "stand-alone" from lsp/gcl-2.6.1,
the config.status does not contain ../libbfd.a:
[...]
s,@ECHO_T@,,;t t
s,@LIBS@, -lm /usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.2/../../../libbfd.a
/usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.2/../../../libiberty.a -lreadline
-lncurses,;t t
s,@VERSION@,2.6.1,;t t
[...]
Investigating a little further, it seems that when called from the Axiom make,
there is a mess in the output of gcc -Wl,-M -static -o foo.o foo.c -lbfd
-liberty, which makes you think that "../libbfd.a" is a valid path:
[...]
/usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.2/../..//usr/bin/ld: cannot find -lc
../libbfd.a(archive64.o)
[...]
This seems to be a gcc bug (should flush stderr before calling ld).
Does not seem easy to provide a workaround...
Hope it helps,
Paul