gcl-devel
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]