Re: Buildung gcc-3.3.x with glibc-2.2.3

[Kai Ruottu <karuottu at mbnet dot fi>]

Oliver Eggers wrote:
> I need to setup a cross-compiling environment with gcc-3.3.x and 
> glibc-2.2.3, because I have a target hardware using glibc-2.2.3. I 
> cannot update the target linux-system to '> glibc-2.2.3' and resources 
> are limited, so I cannot put glibc-2.2.5 on the target additionally.

 What you are telling here, puts your aims being more or less insane...

 You have glibc-2.2.3 on the target system as prebuilt, so why do you
want to rebuild it again?  And maybe with different patches than when
the original glibc was built. And with a totally different GCC version.
Please check the build parameters used when the glibc on the target was
built, using the following command on the target platform:

/lib > ./libc.so.6

It should give something like:

GNU C Library stable release version 2.2.5, by Roland McGrath et al.
Copyright (C) 1992-2001, 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 2.96 20000731 (Red Hat Linux 7.3 2.96-110).
Compiled on a Linux 2.4.9-9 system on 2002-04-15.
Available extensions:
        GNU libio by Per Bothner
        crypt add-on version 2.1 by Michael Glad and others
        The C stubs add-on version 2.1.2.
        linuxthreads-0.9 by Xavier Leroy
        BIND-8.2.3-T5B
        NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
        Glibc-2.0 compatibility add-on by Cristian Gafton
        libthread_db work sponsored by Alpha Processor Inc
Report bugs using the `glibcbug' script to <bugs@gnu.org>.

 Or use 'strings' with the 'libc.so.6' taken from the target system
and search for something like the previous...

 Do you only have the runtime shared libs available for the target
system or what?  Are the development parts ('*crt*.o', '*.a', the
headers,...) missing or what? Aren't there any install CDs etc. where
the missing parts could be or what?

 Generally you should build your crosstools for the aimed target,
take all the required stuff for the target from it, the base C library,
all the extra C libraries (termcap, curses,...), all the X11 libraries,
all the GUI-toolkit libraries etc.  Not to try to rebuild any of the
already built target stuff without any sane reason. And rebuild only
binutils, GCC and GDB/Insight for the target on the new host. The tool
versions used to build the native target platform are of course
preferred, but in my RedHat 7.3 case, not so many probably prefer the
gcc-2.96-110, if wanting to produce crosstools for RedHat 7.3...

 I would guess the glibc-2.2.3 been built with gcc-2.95.3 or with
egcs-1.1.2, so you basically should have the same GCC version if
wanting to rebuild glibc-2.2.3. Additionally with it you can have
any amount of newer GCC versions, but for building glibc-2.2.3 you
should have something as old as it is... Unfortunately old sources
too often require the tools which were available when the sources
were released....

 I had quite a similar problem with the educational DLX target, the
'current' GCC port for it being the gcc-2.7.2.3... So compiling the
gcc-2.7.2.3 sources using gcc-2.95.3 or some gcc-3.x version could
fail miserably... I didn't even try, just copied the libc5 based
gcc-2.7.2.3 from SuSE 5.2 into my RedHat 7.3 and built the 'dlx-elf'
targeted gcc-2.7.2.3 with it. But maybe I can find a newer DLX-GCC
port somewhere or can get the port moved at least to gcc-2.95.3...
Some years ago I moved the Hitachi H8/500 port from gcc-2.7-94g1 or
something to gcc-2.95.3, so doing the same with DLX shouldn't be
impossible...

> In file included from ../include/pthread.h:1,
>                  from ../linuxthreads/sysdeps/pthread/bits/libc-lock.h:23,
>                  from gconv_db.c:26:
> ../linuxthreads/sysdeps/pthread/pthread.h:163: error: parse error before 
> "__thread"
> Maybe someone has a patch or solution for this error.

 Ok, this is a well-known bug with the older glibc versions... The new
GCCs define '__thread' for their own purposes while the glibc headers
use it as a variable name in their protos. You should change the
'__thread' there to be '__thr', '__thread_name' or something else which
doesn't clash with anything already defined. I have in my fixed
glibc-2.1.3 headers your 'pthread.h' lines 160 - 166 patched to be:

/* Create a thread with given attributes ATTR (or default attributes
   if ATTR is NULL), and call function START_ROUTINE with given
   arguments ARG.  */
extern int pthread_create __P ((pthread_t *__thr,
                                __const pthread_attr_t *__attr,
                                void *(*__start_routine) (void *),
                                void *__arg));

ie. the '__thread' changed to '__thr'... There are other places where
this same bug exists, the given errors will point to them...

 If you are a programmer, fixing clashing things like this should be
one part of your daily job and you shouldn't need to ask anything like
this here. For me this looks like obvious, the '__thread' has something
wrong. If you had compared this place with the newer glibc stuff
(2.2.5... 2.3.2), you could have seen it being fixed there... Or if
searching for '__thread' among your new GCC sources could have told it
being defined there:

/home3/src/gcc-3.3.3/gcc > grep __thread *
ChangeLog.7:    * fixinc/inclhack.def (thread_keyword): Match `*__thread'.
ChangeLog.7:    * fixinc/inclhack.def (thread_keyword): Match __thread
as last arg.
ChangeLog.7:    (grokdeclarator): Grok __thread.
ChangeLog.7:    * c-parse.in (reswords): Add __thread.
c-decl.c:             /* Diagnose "__thread extern".  Recall that this list
c-decl.c:                   error ("`__thread' before `extern'");
c-decl.c:                   error ("`__thread' before `static'");
c-decl.c:    /* "static __thread" and "extern __thread" are allowed.  */
c-decl.c:         error ("function definition declared `__thread'");
c-decl.c:           error ("function-scope `%s' implicitly auto and
declared `__thread'",
c-parse.c:  { "__thread",               RID_THREAD,     0 },
c-parse.in:  { "__thread",              RID_THREAD,     0 },
c-parse.y:  { "__thread",               RID_THREAD,     0 },

 As the ChangeLog tells, fixing the target headers during the GCC build
should have removed this bug from the already installed glibc headers...
Using 'grep' to see if something has been used somewhere else for some
other purposes, should be guite routine work...

 But you must fix the glibc-2.2.3 sources to work with the newer GCCs or
you must use some older GCC to rebuild the target's glibc-2.2.3... if it
is absolutely necessary...

Cheers, Kai





------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com