Re: Freebsd-7.4 + std gcc 4.2.1 fails to honour -march=i586
In the last episode (Jul 17), Julian H. Stacey said: > Hi all, > ENVIRONMENT: > Standard > gcc version 4.2.1 20070719 [FreeBSD] > that comes with > FreeBSD 7.4-RELEASE > on my 686 host with > CFLAGS += -march=i586 > in > /etc/make.conf > used with > cd /usr/src/bin/who ; make clean ; make cleandir ; make clean ; make > reports > Warning: Object directory not changed from original /usr/src/usr.bin/who > cc -O2 -fno-strict-aliasing -march=i586 -c /usr/src/usr.bin/who/who.c > cc -O2 -fno-strict-aliasing -march=i586-o who who.o > looking with > file who > reports > who: ELF 32-bit LSB executable, Intel 80386, version 1 > (FreeBSD), for FreeBSD 7.4, dynamically linked (uses shared > libs), FreeBSD-style, not stripped > > Problem: > Use it from a 586 7.4-RELEASE host (AMD+NFS) > file /host/sony/usr/src/usr.bin/who/who > /host/sony/usr/src/usr.bin/who/who: ELF 32-bit LSB executable, > Intel 80386, version 1 (FreeBSD), for FreeBSD 7.4, dynamically > linked (uses shared libs), FreeBSD-style, not stripped > /host/sony/usr/src/usr.bin/who/who > fails with > Illegal instruction Were the crt*.o files on your fast machine also compiled with -march=i586 ? If you run gdb on the core file, can you determine what function the bad instruction is in? -- Dan Nelson dnel...@allantgroup.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Freebsd-7.4 + std gcc 4.2.1 fails to honour -march=i586
Hi Dan cc list Dan Nelson wrote: > In the last episode (Jul 17), Julian H. Stacey said: > > Hi all, > > ENVIRONMENT: > > Standard > > gcc version 4.2.1 20070719 [FreeBSD] > > that comes with > > FreeBSD 7.4-RELEASE > > on my 686 host with > > CFLAGS += -march=i586 > > in > > /etc/make.conf > > used with > > cd /usr/src/bin/who ; make clean ; make cleandir ; make clean ; make > > reports > > Warning: Object directory not changed from original /usr/src/usr.bin/who > > cc -O2 -fno-strict-aliasing -march=i586 -c /usr/src/usr.bin/who/who.c > > cc -O2 -fno-strict-aliasing -march=i586-o who who.o > > looking with > > file who > > reports > > who: ELF 32-bit LSB executable, Intel 80386, version 1 > > (FreeBSD), for FreeBSD 7.4, dynamically linked (uses shared > > libs), FreeBSD-style, not stripped > > > > Problem: > > Use it from a 586 7.4-RELEASE host (AMD+NFS) > > file /host/sony/usr/src/usr.bin/who/who > > /host/sony/usr/src/usr.bin/who/who: ELF 32-bit LSB executable, > > Intel 80386, version 1 (FreeBSD), for FreeBSD 7.4, dynamically > > linked (uses shared libs), FreeBSD-style, not stripped > > /host/sony/usr/src/usr.bin/who/who > > fails with > > Illegal instruction > > Were the crt*.o files on your fast machine also compiled with -march=i586 ? No. I hadn't thought of that, Thanks. Trying below. > If you run gdb on the core file, can you determine what function the bad > instruction is in? host=686: cc -O2 -fno-strict-aliasing -march=i586 -g -c who.c cc -O2 -fno-strict-aliasing -march=i586 -g-o who who.o mv who /host/lapn/tmp/who 586: /tmp/who Illegal instruction gdb /tmp/who run Starting program: /tmp/who Program received signal SIGILL, Illegal instruction. 0x08048a5a in _start1 () (gdb) backtrace #0 0x08048a5a in _start1 () #1 0x08048a18 in _start () #2 0x2804f960 in dlclose () from /libexec/ld-elf.so.1 #3 0x0001 in ?? () 686: change make.conf to CFLAGS += -march=i586 -g Search for crt in Makefile: contrib/gccMakefile.in make clean not supported gnu/lib/csu/Makefile lib/csu/i386-elf/Makefile cd /usr/src ; make clean cd lib/csu/i386-elf ; make install install -o root -g wheel -m 444 crti.o crtn.o gcrt1.o \ crt1.o Scrt1.o /usr/lib cd /usr/lib ; ls -l crti.o crtn.o gcrt1.o crt1.o Scrt1.o -r--r--r-- 1 root wheel 5032 Jul 20 11:42 Scrt1.o -r--r--r-- 1 root wheel 4900 Jul 20 11:42 crt1.o -r--r--r-- 1 root wheel 1680 Jul 20 11:42 crti.o -r--r--r-- 1 root wheel 1636 Jul 20 11:42 crtn.o -r--r--r-- 1 root wheel 5117 Jul 20 11:42 gcrt1.o cd /usr/src/usr.bin/who ; make mv who /host/lapn/tmp/who2 586 /tmp/who2 # Runs OK 686 make.conf CFLAGS += -march=i686 -g cd /usr/src/lib/csu/i386-elf make clean ; make ; make install make.conf CFLAGS += -march=i586 -g cd /usr/src/usr.bin/who ; make clean ; make ; mv who /host/lapn/tmp/who3 586 /tmp/who3 gdb /tmp/who3 (gdb) run Starting program: /tmp/who3 Program received signal SIGILL, Illegal instruction. 0x08048a5a in _start1 (cleanup=0x2804f960 , argc=1, argv=0xbfbfe37c) at /usr/src/lib/csu/i386-elf/crt1_c.c:75 75 __progname = s + 1; (gdb) bt #0 0x08048a5a in _start1 (cleanup=0x2804f960 , argc=1, argv=0xbfbfe37c) at /usr/src/lib/csu/i386-elf/crt1_c.c:75 #1 0x08048a18 in _start () at /usr/src/lib/csu/i386-elf/crt1_s.S:42 #2 0x2804f960 in dlclose () from /libexec/ld-elf.so.1 #3 0x0001 in ?? () 686 make.conf CFLAGS += -march=i686 -g cd /usr/src/gnu/lib/csu ; make clean ; make ; make install cd /usr/src/usr.bin/who ; make clean ; make mv who /host/lapn/tmp/who4 586 /tmp/who4 Illegal instruction gdb /tmp/who4 run Starting program: /tmp/who4 Program received signal SIGILL, Illegal instruction. 0x08048a5a in _start1 (cleanup=0x2804f960 , argc=1, argv=0xbfbfe37c) at /usr/src/lib/csu/i386-elf/crt1_c.c:75 75 __progname = s + 1; 686 cc -O2 -fno-strict-aliasing -march=i686 -g -v -o who who.o Using built-in specs. Target: i386-undermydesk-freebsd Configured with: FreeBSD/i386 system compiler Thread model: po
Re: Freebsd-7.4 + std gcc 4.2.1 fails to honour -march=i586
On Wednesday, July 20, 2011 7:33:26 am Julian H. Stacey wrote: > What should FreeBSD do ? > Add a comment to man gcc ... that -march=i586 is not > enough, & feed the comment back to gcc project & see how > they want to handle it ? No, this is not a GCC bug. If you want to use a single build machine that will compile programs for other machines on a network to use, it must use the lowest common denominator for its CPUTYPE in /etc/make.conf. The out-of-the-box crt files from a FreeBSD install will work fine on a 486 and above, so can only get yourself into this quandry by building a new world with a CPUTYPE (or similar CFLAGS) setting in /etc/make.conf that violates this rule. You can fix your machine by fixing the CPUTYPE in your build machine and building and installing a new world (do use NO_CLEAN=yes for your build, do a full build). You will also want to rebuild any other binaries on this machine that you share with other machines. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Freebsd-7.4 + std gcc 4.2.1 fails to honour -march=i586
Hi, Reference: > From: John Baldwin > Date: Wed, 20 Jul 2011 07:48:05 -0400 > Message-id: <201107200748.05786@freebsd.org> John Baldwin wrote: > On Wednesday, July 20, 2011 7:33:26 am Julian H. Stacey wrote: > > What should FreeBSD do ? > > Add a comment to man gcc ... that -march=i586 is not > > enough, & feed the comment back to gcc project & see how > > they want to handle it ? > > No, this is not a GCC bug. If you want to use a single build machine that > will compile programs for other machines on a network to use, it must use the > lowest common denominator for its CPUTYPE in /etc/make.conf. > > The out-of-the-box crt files from a FreeBSD install will work fine on a 486 > and above, so can only get yourself into this quandry by building a new world > with a CPUTYPE (or similar CFLAGS) setting in /etc/make.conf that violates > this rule. > > You can fix your machine by fixing the CPUTYPE in your build machine and > building and installing a new world (do use NO_CLEAN=yes for your build, do a > full build). You will also want to rebuild any other binaries on this > machine > that you share with other machines. > > -- > John Baldwin Hi John, Yes I realise all that now thanks. The point now is man gcc is misleading/ incomplete: "-march=cpu-type Generate instructions for the machine type cpu-type." Those instructions will not make a program that runs on a lesser CPU type without alternate crt for lesse CPU. CFLAGS in make.conf is fine for single developer/ host debugging, but is not appropriate for multi user multi make builds os src/ ports/ other Its seems just that gcc -march fails to select alternate crt. One gross ugly solution needing root would be to create chroots, but Too ugly. I suggest gcc via -march should also be used as a selection for sub dirs for crt ? & we should co-operate with gcc project on that, *BSD & *linux must all face same phenomena so lets not develop a non standard solution. Even if we're too lazy to do anything more, we should at least document it as a patch to man gcc. Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Reply below, not above; Indent with "> "; Cumulative like a play script. Format: Plain text. Not HTML, multipart/alternative, base64, quoted-printable. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Freebsd-7.4 + std gcc 4.2.1 fails to honour -march=i586
> Even if we're too lazy to do anything more, we should at least > document it as a patch to man gcc. PS Please no one take offense at word "Lazy" I'm as lazy as the next man. A good engineer can be a lazy engineer, - if he works to max efficiency :-) Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Reply below, not above; Indent with "> "; Cumulative like a play script. Format: Plain text. Not HTML, multipart/alternative, base64, quoted-printable. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Freebsd-7.4 + std gcc 4.2.1 fails to honour -march=i586
on 20/07/2011 15:34 Julian H. Stacey said the following: > Even if we're too lazy to do anything more, we should at least > document it as a patch to man gcc. Talk to GCC people now? -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Freebsd-7.4 + std gcc 4.2.1 fails to honour -march=i586
On Wednesday, July 20, 2011 8:34:57 am Julian H. Stacey wrote: > Hi, > Reference: > > From: John Baldwin > > Date: Wed, 20 Jul 2011 07:48:05 -0400 > > Message-id: <201107200748.05786@freebsd.org> > > John Baldwin wrote: > > On Wednesday, July 20, 2011 7:33:26 am Julian H. Stacey wrote: > > > What should FreeBSD do ? > > > Add a comment to man gcc ... that -march=i586 is not > > > enough, & feed the comment back to gcc project & see how > > > they want to handle it ? > > > > No, this is not a GCC bug. If you want to use a single build machine that > > will compile programs for other machines on a network to use, it must use > > the > > lowest common denominator for its CPUTYPE in /etc/make.conf. > > > > The out-of-the-box crt files from a FreeBSD install will work fine on a 486 > > and above, so can only get yourself into this quandry by building a new > > world > > with a CPUTYPE (or similar CFLAGS) setting in /etc/make.conf that violates > > this rule. > > > > You can fix your machine by fixing the CPUTYPE in your build machine and > > building and installing a new world (do use NO_CLEAN=yes for your build, do > > a > > full build). You will also want to rebuild any other binaries on this > > machine > > that you share with other machines. > > > > -- > > John Baldwin > > > Hi John, > Yes I realise all that now thanks. > The point now is man gcc is misleading/ incomplete: > "-march=cpu-type >Generate instructions for the machine type cpu-type." > Those instructions will not make a program that runs on a lesser CPU type > without alternate crt for lesse CPU. > > CFLAGS in make.conf is fine for single developer/ host debugging, > but is not appropriate for multi user multi make builds os src/ ports/ other > > Its seems just that gcc -march fails to select alternate crt. > > One gross ugly solution needing root would be to create chroots, > but Too ugly. > > I suggest gcc via -march should also be used as a selection for sub > dirs for crt ? & we should co-operate with gcc project on that, > *BSD & *linux must all face same phenomena so lets not develop > a non standard solution. I think this is a harder problem than you expect. It is not just the crt files that matter, but every library. You would need CPU-specific versions of every static library on the build system, and possibly you would want to do this for all shared libraries too. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Freebsd-7.4 + std gcc 4.2.1 fails to honour -march=i586
Hi John & all, > On Wednesday, July 20, 2011 8:34:57 am Julian H. Stacey wrote: > > Hi, > > Reference: > > > From: John Baldwin > > > Date: Wed, 20 Jul 2011 07:48:05 -0400 > > > Message-id: <201107200748.05786@freebsd.org> > > > > John Baldwin wrote: > > > On Wednesday, July 20, 2011 7:33:26 am Julian H. Stacey wrote: > > > > What should FreeBSD do ? > > > > Add a comment to man gcc ... that -march=i586 is not > > > > enough, & feed the comment back to gcc project & see how > > > > they want to handle it ? > > > > > > No, this is not a GCC bug. If you want to use a single build machine > > > that > > > will compile programs for other machines on a network to use, it must use > > > the > > > lowest common denominator for its CPUTYPE in /etc/make.conf. > > > > > > The out-of-the-box crt files from a FreeBSD install will work fine on a > > > 486 > > > and above, so can only get yourself into this quandry by building a new > > > world > > > with a CPUTYPE (or similar CFLAGS) setting in /etc/make.conf that > > > violates > > > this rule. > > > > > > You can fix your machine by fixing the CPUTYPE in your build machine and > > > building and installing a new world (do use NO_CLEAN=yes for your build, > > > do a > > > full build). You will also want to rebuild any other binaries on this > > > machine > > > that you share with other machines. > > > > > > -- > > > John Baldwin > > > > > > Hi John, > > Yes I realise all that now thanks. > > The point now is man gcc is misleading/ incomplete: > > "-march=cpu-type > >Generate instructions for the machine type cpu-type." > > Those instructions will not make a program that runs on a lesser CPU type > > without alternate crt for lesse CPU. > > > > CFLAGS in make.conf is fine for single developer/ host debugging, > > but is not appropriate for multi user multi make builds os src/ ports/ other > > > > Its seems just that gcc -march fails to select alternate crt. > > > > One gross ugly solution needing root would be to create chroots, > > but Too ugly. > > > > I suggest gcc via -march should also be used as a selection for sub > > dirs for crt ? & we should co-operate with gcc project on that, > > *BSD & *linux must all face same phenomena so lets not develop > > a non standard solution. > > I think this is a harder problem than you expect. Yes, Needs to be thought through, that's why I posted 13:33:26 +0200 : > > Question: with more complex programs than who, might there > > be sensitivity to other libs too ? Per Andriy's : > Talk to GCC people now? I'm not clear what's best, but yes, when its clear, then talk to gcc people. > It is not just the crt files > that matter, but every library. You would need CPU-specific versions of every > static library on the build system, Would be preferable. Though as we default to link dynamic, not as essential as crt.o . We could also have some ifdef to avoid by default generating for all of [3-6]86 that would save space & time, If the directory was not filled, a user of gcc --march=i586 would then fail to link from /usr/lib/i586/ & could receive a good error, instead of a 686 crt.o with no error. > and possibly you would want to do this for > all shared libraries too. I guess we could skip those, Presuming a target system should have a matched set for the right CPU & release etc. I'm not sure about the recent plethora of lib stuff /lib Seems to be all .so so I guess not affected. /libexec ld-elf.so.1 ld-elf32.so.1 # no man ld-elf /usr/lib This is where I'd suggest sub dirs of [3-6]86 with default machine native either in top dir or perhaps a native/ sub dir, or sym linked whatever gcc & out & other projects find best ? /usr/lib32 ... Sigh ! same as above ? .. /usr/libdata /ldscripts & /lint ? /usr/libexec Presumably can ignore this as real programs. & ignore inderminent localy variant dirs shown by cd /usr/local ; find . -type d -name \*lib\* -print Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Reply below, not above; Indent with "> "; Cumulative like a play script. Format: Plain text. Not HTML, multipart/alternative, base64, quoted-printable. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Freebsd-7.4 + std gcc 4.2.1 fails to honour -march=i586
Hi, Alexander Kabaev wrote: > On Wed, Jul 20, 2011 at 2:04 PM, Julian H. Stacey wrote: > > Hi John & all, > > > > > > >> It is not just the crt files > >> that matter, but every library. You would need CPU-specific versions of > >> every > >> static library on the build system, > > > > Would be preferable. > > Though as we default to link dynamic, not as essential as crt.o . > > We could also have some ifdef to avoid by default generating for > > all of [3-6]86 that would save space & time, > > If the directory was not filled, a user of gcc --march=i586 would > > then fail to link from /usr/lib/i586/ & could receive a good error, > > instead of a 686 crt.o with no error. > > > > > >> and possibly you would want to do this for > >> all shared libraries too. > > > > I guess we could skip those, Presuming a target system should have a > > matched set for the right CPU & release etc. > > > > > > I'm not sure about the recent plethora of lib stuff > > /lib > > Seems to be all .so so I guess not affected. > > /libexec > > ld-elf.so.1 ld-elf32.so.1 # no man ld-elf > > /usr/lib > > This is where I'd suggest sub dirs of [3-6]86 > > with default machine native either > > in top dir > > or perhaps a native/ sub dir, > > or sym linked > > whatever gcc & out & other projects find best ? > > /usr/lib32 > > ... Sigh ! same as above ? .. > > /usr/libdata /ldscripts & /lint > > ? > > /usr/libexec > > Presumably can ignore this as real programs. > > > > & ignore inderminent localy variant dirs shown by > > cd /usr/local ; find . -type d -name \*lib\* -print > > Hi Alexander, Your mailer has gone wrong. It lost cc freebsd-hackers@freebsd.org (restored) & below the word 'plethora' in my posting was a plain tab indented section. Your mailer mangled each tab to a string of 5 chars: " \xa0" > Where does that end? We have tons of -march options, would you create > the subdir for each combination of ABI and CPU users can potentially > think > of? Insanity lies that way. Don't panic, I agree, Only a few rare cross generator hosts might want the severe bloat of all arch libs installed. But no reason we coudn't have an infrastructure of lib dir name structure expectancy for where to look for stuff _If_ it's installed. Maybe NetBSD & Linux people may have also had ideas on that ? It would prevent gcc -march=586 silently failing, producing unusable binaries, as wrong crt.o is linked in. Would this be best: Extend gcc -march=cpu , so in addition to telling compiler to generate cpu specific code rather than default native, it also automatically passes paths to linker to use eg Not /usr/lib/ but /usr/lib/cpu/ thus forcing a link failure if directory non existant or empty. No default auto populating with every other arch. Certainly not for sparc, amd, etc. Not even for *86 by default (Unless, maybe just for crt.o as sample ? they're not big ...) Later we could add to Makefile structure, to populate lib sub dir[s] on request, if optional extra env. var[s] trigger an ifdef build of extra libs. Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Reply below, not above; Indent with "> "; Cumulative like a play script. Format: Plain text. Not HTML, multipart/alternative, base64, quoted-printable. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Freebsd-7.4 + std gcc 4.2.1 fails to honour -march=i586
Hi freebsd-toolch...@freebsd.org, freebsd-i...@freebsd.org cc: freebsd-hackers@freebsd.org Sun Jul 17 01:19:37 UTC 2011 I wrote to freebsd-hackers@ with Subject: Freebsd-7.4 + std gcc 4.2.1 fails to honour -march=i586 Summary: I found a problem with CFLAGS += -march=i586 on an i686 linking a crt.o for an i686, then not running on an i586, I suggested maybe -march could be extended to also select seperate lib sub directories to at least trigger a link failure, rather than a silent apparent good compile of a bad binary. Others on freebsd-hackers@ made various follow up. People on freebsd-toolchain@ & freebsd-i386@ might have valuable input ? Not wanting to split the thread between lists, or cross post, More than this one) or lose people on freebsd-hackers@, Could you please look at http://lists.freebsd.org/pipermail/freebsd-hackers/2011-July/035889.html & reply-to: freebsd-hackers@freebsd.org Thanks ! (PS I'm not on freebsd-toolchain@ & freebsd-i386@, but am on freebsd-hackers@ ) Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Reply below, not above; Indent with "> "; Cumulative like a play script. Format: Plain text. Not HTML, multipart/alternative, base64, quoted-printable. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Freebsd-7.4 + std gcc 4.2.1 fails to honour -march=i586
On 2011-07-21 14:17, Julian H. Stacey wrote: Summary: I found a problem with CFLAGS += -march=i586 on an i686 linking a crt.o for an i686, then not running on an i586, IMHO this is a bit of a PEBKAC issue. If you change CPUFLAGS to target a specific CPU, you should really rebuild all of world with it, not just a single program. In fact, you should rebuild all your ports too. I suggested maybe -march could be extended to also select seperate lib sub directories to at least trigger a link failure, rather than a silent apparent good compile of a bad binary. I think this would add a whole lot of complexity for very little gain, and still not save you from potential problems. You would really have to use the same approach for all system libraries, otherwise you might link in something from e.g. libc or libcrypto that was optimized for the wrong CPU. And I'm not even mentioning objects and/or libraries from ports... :) The compiler cannot automagically determine whether any object or library file you link into your program is fit to run on the CPU you are targeting, unless you would add information specifying the CPU type (and other particulars) to the object files themselves. In the end, it is up to you to make sure you do not mix "incompatible" object code. Having said all this, if you are worried particularly about the crt*.o files, then we could simply always build those with 'lowest common denominator' flags, like we do with e.g. the dynamic linker. I doubt very much that the startup code gains any performance by optimizing for higher CPU types. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Freebsd-7.4 + std gcc 4.2.1 fails to honour -march=i586
On Jul 20, 2011, at 9:13 AM, John Baldwin wrote: > I think this is a harder problem than you expect. It is not just the crt > files > that matter, but every library. You would need CPU-specific versions of every > static library on the build system, and possibly you would want to do this for > all shared libraries too. gcc has support for what it calls multilib. It was originally for MIPS where there were 3 ABIs that needed to be supported simultaneously (o32, n32 and n64). However, it is general enough to adapt to your needs, I think. The harder part is fixing things like the ports and such to that as well... The medium hard part is fixing buildworld to generate all this stuff in the right places. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
