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 Titus, All, On Wednesday 03 February 2010 00:24:24 tvb377@gmx.de wrote: > Sorry, I'm quite new to mercurial. And I guess the last step in > "Contributing" means it wants to send emails, which I cannot provide > on this machine here in reasonable time. Yes, the patches would be mailed, and upon reception, it becomes really trivial to re-aplly the patches, in the same sequence as they are applied on your side, keeping authorship, date... > > > - replace all calls to readlink(1GNU) with compatible variants. > > "readlink -e" and "readlink" are not equivalent. > No, but > a) ct-ng does not use libs it searches for (here only ncurses) by itself. > b) The variable where is dropped for libs, afaik. It is also > questionnable if you would actually need the shared object instead of > the link. > c) I'm not aware of installations where links point to links > [that point to links...] that point to shared objects. > Then the check could in theory fail when removing the -e And we don't care if the user's system is borken. It's his/her burden todetect such a case. Granted. > > gcc -dumpmachine will tell us the tuple for which it was configured, and > > that means the prefix to use to the actual tools, which is what we need. > Hmm, I see the point. But apparently then there is an inconsistency here > on Darwin, be it in the gcc configuration or the configure (I think it > was of gmp) that failed. > Anyway, my change only is for Darwin + BSD. Yes, I saw. I was just explaining why we used gcc -dumpmachine in this case. > > Statically linking should hopefully speed up things. Having a /slow/ > > wrapper is not very interesting, is it? Of course, the ratio > > time-in-wrapper / (time-in-wrapper + time-in-actual-tool) should be > > fairly small, except for very trivial programs, where the total time > > will anyway be almost imperceptible... > imho, statically linking will not buy you a measurable amount of time, > especially not when linking only to such mundane things like libc that > are guaranteed to be in core, anyway. As a side note, I was looking at how libtool works. Jeez... Such a lot of shell scripting just to call the compiler/linker. That's sad... :-( So, yes, our wrapper should be blindly fast when compared to the auto-stuff/libtool fuzz, and especially since libc.so is cached. Besides, static wrapper: 5558KiB shared wrapper: 7KiB Woot! Let's go shared! :-/ > > > - under Darwin, use DYLD_LIBRARY_PATH in wrapper.c > > Separate patch for that as well. > OK. Please note that this patch requires the above cmd line patch. That's why a proper patchseries as prepared by 'hg email' is interesting: the patch order is maintained. > Hope it fits now for you. Please note that > - all patches (except for build-mpfr and using config.guess) > are necessary to run crosstool-ng itself. > - all are tested except the one in populate.in OK, see my comments below... > Sorry for the inconvenience that these are not mercurial-sent patches. I'll deal with that, but it may take a bit longer... OK, for the patches now: --> build-mpfr-on-darwin.patch applied --> corrected-date-sed-expr.patch applied --> uname-portable.patch applied --> nice-to-see-all-envvars.patch applied --> wrapper-compile-commandline.patch diff --git a/scripts/build/internals.sh b/scripts/build/internals.sh --- a/scripts/build/internals.sh +++ b/scripts/build/internals.sh @@ -55,9 +55,8 @@ if [ "${CT_DEBUG_CT}" = "y" ]; then _t="" # If debugging crosstool-NG, don't strip the wrapper fi - CT_DoExecLog DEBUG "${CT_HOST}-gcc" \ - -Wall -Wextra -Wunreachable-code -Werror \ - -O3 -static ${_t} \ + CT_DoExecLog DEBUG "cc" -Wall -Wextra -Werror \ + -O -D$CT_SYS_OS ${_t} \ You broke canadian-cross and cross-native: the wrapper will have to run on the host, not on the build machine. So we must be using ${CT_HOST}-gcc Besides, it's space-damaged at the end of lines (line up \). --> whyclearCT_CFLAGS_FOR_HOST.patch Well, let's be sure the variable is empty before we add to it (in case the user already had it in the enviornment). Notice that we do: CT_CFLAGS_FOR_HOST+=blabla I'll handle the rest of the patchset after FOSDEM, i.e. next week. Regards, Yann E. MORIN. -- .-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v 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] |