The attached patch applied over toolchain and eutils eclasses allows compilation of gcc on g/fbsd (at least i hope, i'm building it right now, anyway they are prerequisites). They don't hurt linux systems as they simply add a case for x86-fbsd useflag, uses gmake instead of make (which is available everywhere to the same executable), and changes the way --enable-clocale is passed. That's the main problem of building gcc (better, libstdc++) on fbsd's libc. HTH, Diego
Created attachment 55399 [details, diff] toolchain-eclass.patch
Created attachment 55400 [details, diff] eutils-eclass.patch
the first few hunks for toolchain.eclass are ok, the part where make is changed to gmake is not ok many many other packages execute `make` so you're going to have to come up with a transparent fix for that the get_number_of_jobs function shouldnt be used anymore ... i think just gcc/glibc still use it (which should be changed)
There should be an alias which tells make=gmake on fbsd profile iirc. This make it completely transparent to quite every ebuild. GCC, instead, seems to loose the alias somewhere during the build process, and then uses ${MAKE} to call it, calling BSD-make. That's why I changed make -> gmake.
Yeah, there is an make=gmake alias in our profile [1], unfortunately some packages insists in ignoring it causing us a few troubles. SpanKY, would it be ok to use gmake only when on x86-fbsd and leave make as default to the other systems? 1. http://www.gentoo.org/cgi-bin/viewcvs.cgi/bsd/fbsd/overlay/profiles/default-bsd/fbsd/5.3/profile.bashrc?root=gentoo-projects&view=markup
i would prefer we figure out why the alias disappears ;)
That's not so bad.. it could be done intentionally to avoid some strange aliased make combinations. gmake is the official name anyway, so moving everything pace-by-pace to use gmake instead of make is a way to resolve the problems.
Created attachment 55460 [details, diff] toolchain-eclass2.patch Another patch needed to toolchain-eclass.patch, note that cp -a doesn't exists on bsd cp, so we need to change it to the options which are aliased by -a. Also -d option is not usable on bsd cp, but that's not a problem, as usually -pPR is enough.
Created attachment 55461 [details, diff] eutils-eclass2.patch That is also needed, it makes emktemp know about bsd mktemp command which is slightly different from the debian's one. Sorry for the style of the patch but i forgot to do a copy of the eclass before change it and i've diffed it against the old revision in my svn rep.
Created attachment 55466 [details, diff] toolchain-eclass3.patch Hope this is the last :) This removes the use of env -uRESTRICT, using env RESTRICT="" as -u is not POSIX compliant and fails on bsd, and chown to root:wheel instead of root:root which is not valid on bsd.
ive merged the fixes for 'cp -a' and 'env -u' ... i changed the profile-bootstrap logic to look at arch (if arch is x86, then attempt a profile bootstrap) i also changed the MAKE_COMMAND stuff ... emake is always used now, but if you're doing a profiled bootstrap, we append -j1 to MAKEOPTS for the locale/gnu thing, wouldnt this work better ? [[ ${CTARGET} == *-gnu ]] && confgcc="${confgcc} --enable-clocale=gnu" i dont know what CHOST bsd and osx use ... but i assume it doesnt end in '-gnu' ?
the mktemp() patch for eutils.eclass looks wrong ... old behavior: if exe == touch then exe = -p new behavior: if exe == touch && userland == bsd then exe = -p if exe == touch && userland != bsd then exe = -t so if we look at the GNU userland, the behavior is now to pass '-t' instead of '-p' ...
Sorry about the emktemp patch, I wrote a version here and one on the g/fbsd box and I inverted the logico. About checking for CHOST, actually the problem there is with GNU/kFBSD which uses glibc under FreeBSD kernel. I don't know which CHOST uses for it. CHOST for FBSD on an Athlon is i686-unknown-freebsd. Maybe we could make it "autotest" for the locale, as it does on non-gnu systems right now. It should work well.
CHOST for x86-fbsd is currently i686-unknown-freebsd5.3. AFAIK the GNU/kFreeBSD system would use something along the lines of i686-unknown-freebsd-gnu; IIRC absinthe would probably be the one to tell you that. That would be using glibc though, so the gnu locales would presumably be correct in that case.
Created attachment 57406 [details, diff] toolchain eclass patch
Created attachment 57407 [details, diff] eutils eclass patch Ok I'm now trying to build gcc 4.0.0 (as 3.4 ICEs out) and that's the current status: get_number_of_jobs is still fooled up, should that be removed from gcc? I've changed the locale part to check if in CTARGET there's -gnu so that it doesn't rely on fbsd/ppc-macos. I've fixed emktemp call. The root:root -> root:wheel change is still needed.
Created attachment 57440 [details, diff] mktemp-bsd-eutils.patch make sure this mktemp still works please
emktemp now gives a strange error... the problem is that I can't find where is getting called during emerge gcc.
Yuhu? Now that gcc and libstdc++ dependency are fixed (thanks SpanKY to allow me to do that :) ) we really need to merge at least all the fix but emktemp (which still fails with latest patch but doesn't change the fact that it works fine... don't know where on earth it's called anyway). Actually get_number_of_jobs can check for "${KERNEL}" == "FreeBSD" instead of "${ARCH}" == "x86-fbsd" so we are safe for eventual amd64-fbsd and following.
Actually, FreeBSD doesn't require /proc filesystem to be mounted, in spite of linux, so get_number_of_jobs is simply broken. SpanKY, can you remove it soon?
Considering this fixed at this point.
At least the emktemp fixed for eutils isn't applied to the eutils.class . Reopening, this breaks configuration of mysql on my machine.
Manually editing the changes from "eutils eclass patch" into my eutils.eclass fixes the problem.
Diego can handle the -t/-p issue on CHOST==*bsd* systems
Okay fixed.
Don't think this is quite closed yet. I was cross-compiling baselayout 1.11.14-r3 to a mips64el TARGET and emktemp busted. I get: mktemp: cannot make temp dir tmp: Invalid argument Doing a little instrumentation I find that the actual command begin executed is: TMPDIR="/local/nightly/20060216/build/roots/mips64el//tmp/devnodes.XXXXXXXXX" mktemp -d tmp Manually changing it to: TMPDIR="/local/nightly/20060216/build/roots/mips64el//tmp" mktemp -dt devnodes.XXXXXXXXX does what I expect is intended. This a Linux system with debianutils-2.14.1-r1
Created attachment 79994 [details, diff] eutils.eclass-linux-bsd.patch I could reproduce the problem by changing the ROOT variable. In fact, I was trying to find a way to use only one command for them all (changing only one parameter), but it's seems to be a bit hard. Please, try the patch, which come back the Linux way and keep the BSD way.
Works for me both cross-compiling and native emerge on Linux
If there's no problem with the patch, can someone put this in the portage so more people won't have problems, please? Thanks.
Committed now.
