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

[Dan Kegel <dank at kegel dot com>]

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

I do this all the time; it's really convenient to just build
an entire toolchain using crosstool.  You just need to
take some care to match versions of glibc, and he's trying to do that.
If you need to link to libraries on the target that aren't
part of glibc, and that you don't build yourself,
it probably makes sense then to grab all of /usr/include,
/lib and /usr/lib, and refer to them with -I and -L when linking.
That does mean some duplication with the glibc crosstool built,
but it hasn't been harmful so far in my (tiny) experience
with this m.o.

> 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 agree with most of what you're saying, except in a perfect world,
one would have sources and a build system for all the libraries on
the target, so it wouldn't matter whether you rebuilt everything
or just grabbed it from the target.

>  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...

I recently backported the patches needed to build glibc-2.1.3
with gcc-3.3.3.  It didn't take too long.   They're now part of
crosstool.

> > 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...

Right; I gave him a link to the patches that fix this in my reply.

>  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.

And/or you should be good enough with google to track down where
these bugs have been discussed before.  I often start by
just doing a search for the key part of the error message, minus
maybe the path and line number, e.g.
  "pthread.h error: parse error before __thread"
That usually tracks the patch down.


BTW, Kai and I are usually in disagreement about how to build toolchains.
I was really surprised when he admitted once that crosstool was a good
thing :-)
- Dan

--
My technical stuff: http://kegel.com
My politics: see http://www.misleader.org for examples of why I'm for regime change

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