This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: crosstool-NG and glibc 2.3.x


Hello Jozef!

On Sunday 28 October 2007 21:28:26 Jozef Matula wrote:
> Sorry to bother you with my e-mail directly - I ought to send it to
> CrossGCC newsgroup may be, but I hope this is the better way.

No bother! But crossgcc is a better place, because there are very
knowledgeable chaps there that would be able to answer tricky questions.
So CCing.

> I've been using crosstool to generate C & C++ 3.4.6 toolchains for glibc
> 2.3.2 on i686 and x86_64. But when trying to compile GCC 4.2 with
> crosstool I realised that GCC can't be built with binutils 2.18.
> Unfortunately C++ 4.2 with binutils 2.17 is terribly slow on linking
> which takes ages.
> 
> Then I found your crostool-NG and GCC 4.2 with binutils 2.18 was just a
> peace of cake! Big thanks to you.

:-)

> But I have several implied issues or let's say non-trivial questions -
> I'm not that newbie in crosscompilation so I don't need a complete
> solution, I would appreciate at least your opinion, if not the solution
> proposal ;-)
> 
> Issue 1)
> I want to run my crosscompiled project binaries on older libc's - for
> example Red Hat Enterprise 4, which is not that old, uses libc 2.3.4.
> And because your crosstool-NG starts with glibc 2.5, the resulting
> binaries don't work.

I tend to get rid of of ageing components. At least, you'll find glibc
2.3.6 hidden behind the obsolete features, which you can un-hide in
the "Path and Misc options" menu. For older versions, you'd have to add
them manually (use the tools/addToolVersion.sh script, if need be).

> In my use case I don't need to deploy libc on target system, I just need
> libc as an avatar to be able to compile and link further libraries -
> actually I extend each my toolchain with
>   for host-platform:
>     automake, autoconf, libtool, pkgconfig, gmp, mpfr
>   for target-platform:
>     bzip2, zlib, ncurses, expat, xfree86, freetype, glib, pango, cups
> My resulting toolchain is capable to build more complicated libraries
> (like Trolltech's Qt or Python) and doesn't depend on preinstalled
> autotools. I want to be able to "copy" toolchain anywhere and be able
> to use it without any third party libraries (therefore I equip the
> toolchain with autotools and only "make" is required to be on host
> system).

I don't really understand your use-case, but let's assume you do! :-)

> I spent two days by hacking several crosstool 0.43 glibc patches, so
> finally I have a set of patches for crosstool-NG to generate glibc 2.3.3
> with linuxthreads compileable with GCC 4.2.2 for i686 target.
> But to be honest this was quite quite a lot of work just to get GCC 4.2.2
> working with binutils 2.18...
> 
> My question is why you start with glibc 2.5? I understand you don't need
> to bother with glibc dependencies on particular GCC versions. But
> original crosstool supports much older libraries. Implication is that
> toolchains created by crosstool-NG can't produce binaries for
> "stable" Linux distributions.

I primarly wrote crosstool-NG to try to push crosstool forward by making it
much more maintainable. I wanted to learn and understand how a toolchain was
built and worked. I mostly succeded (IMHO), but pushing crosstool-NG forward
is really a hard job, which I don't have time to pursue more than the now
occasional patch here and there. After all, my real main concern was to have
ARM and MIPS uClibc-based cross-toolchains, tweaked for my specific needs.
That I succeded fully, as the toolchains I'm using daily. Keeping around and
suporting ageing versions proved to be very difficult to me, as I lack
proper time... :-( So I dropped them. If you feel the need for them to be
revived, then provide a real good reason, a test report that it works for
you, and I'll put it back.

> (P.S.: I've believed that crosstool uses a dedicated GCC bootstrap
> compiler to build libc independently on final compiler - am I right? Or
> was it just for building of final GCC?)

crosstool-NG still uses a kind of 'bootstrap', or 'core' gcc. But crosstool-NG
does not offer the choice of a different version from the final gcc. I don't
see the point, and I even suspect there are discrepancies in the libc if the
'core' gcc is different from the final one, especially now that glibc has
NPTL, and that does require a /full/ compiler with threading support to build
the glibc start files (whatever that might be).

> Issue 2) GFortran, GMP, and MPFR - I had to add Fortran to my toolchain -
[--SNIP--]
> Because GMP and MPFR are on your TODO list, I wonder how you are going 
> to overcome this? I think both should be stored in the toolchain,
> because each toolchain may have a different version.

Yep. I know that GMP and MPFR are needed. And most notably for gcc 4.3+
where they'll be required for _every_ frontend, not only fortran.

But I still wonder wether they are needed on the host or on the build system.
This is no problem for standard cross-toolchains, but for those building
canadian-cross, it is.

So the short term solution I envisioned was to build the two libraries
natively on the build/host system for now, and install them in ${CT_PREFIX_DIR}
and point ./configure for gcc to ${CT_PREFIX_DIR} for additional librairies,
and make sure it doesn't by chance pick the libs from the host in /usr/lib
(which would simply ruin efforts doen to isolate all the toolchain components).

Once we know how to build canadian-cross, then we'd fix the GMP and MPFR
problem for good. But until then...

> If you don't agree with my approach, can you just point me to a proper
> place or way how could I override LDFLAGS for final GCC build?

Did my suggestion makes sense to you as well? If so, I'd gladly accept
patches! ;-)

> Unfortunatelly I don't have the gift to explain things simply, so I
> apologize for this long e-mail and I hope you got until here while
> reading :-)

No worry, I appreciate feedback and questions about crosstool-NG. :-)

> The issue 1) is not really an issue, I can live with the state as it is
> now. If you are interested I can send you my .config and patches.

.config and patches welcome!

> The issue 2) is again something I worked around already (manual rebuild
> of f951) but I'm interested in how you plan to handle GMP, MPFR in the
> future.

See above.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +0/33 662376056 | Software  Designer | \ / CAMPAIGN     |   ^                |
| --==< Â_Â >==-- Â------------.-------:  X  AGAINST      |  /e\  There is no  |
| http://ymorin.is-a-geek.org/ | (*_*) | / \ HTML MAIL    |  """  conspiracy.  |
Â------------------------------Â-------Â------------------Â--------------------Â


--
For unsubscribe information see http://sourceware.org/lists.html#faq


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]