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

[Oliver Eggers <o dot eggers at nordsys dot de>]

Hi!

Kai Ruottu wrote:
>  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.
>
> [...]
>  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?

Well, I am a developer, but I'm rather a newbie to cross-compiling. And 
I'm not very used to glibc-, binutils- or gcc-internals. So the problems 
that occur during the compilation are not really obvious to me.

The target is from a third-party vendor. We've got a crosscompiling 
environment from that vendor based on gcc 2.95 and glibc 2.2.3.

The points are:

- I *must not* change the libraries on the target. The hardware vendor 
is responsible for the system software and if he puts glibc-2.2.3 on it, 
I am not supposed to change that.

I tried to put glibc-2.2.5 on the target which made my software to run, 
but cause serious effects with other programms and tools which were not 
running anymore. So it's dangerous to change those basic libraries, 
because we don't have tools to setup the system from scratch and we 
would loose guarantee if we crash it by changing basic system software.

- Memory resources are limited on the target, so I don't want to put 
extra libs on it, if I don't need to.

- We have a library from a third party vendor based on the STL's of 
gcc-3.3.x (g++)

- I'm developing for multiple targets: Linux x86, PPC-405, maybe more in 
the future. Using gcc-3.3.x and it's STL-Libraries would be *really nice 
to have* and comfortable.

Thanks to Dan for the first suggestion for patches:

- 'glibc-linuxthreads-2.2.5/threadparam.patch' solved the thread-problem.
- 'sscanf.patch' and 'sprintf-prototype.patch' solved another problem.

Lots of problems seem to be known by others here on the mailing list and 
Dan includes lots of patches, so I tried to post the error messages here 
hoping to find someone who says: 'This is obvious! Try xy as a workaround.'

  Regards - Oliver


>  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

--
// Oliver Eggers / o.eggers@nordsys.de
//
// NORDSYS OHG
// Norddeutsche Systemtechnik
//
// Büro : 0 531 - 12 09 241



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