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