Freebsd-7.4 + std gcc 4.2.1 fails to honour -march=i586

[Julian H. Stacey]

Hi,
Alexander Kabaev wrote:
> On Wed, Jul 20, 2011 at 2:04 PM, Julian H. Stacey <jhs at berklix.com> wrote:
> > Hi John & all,
> >
> 
> <SKIP>
> 
> >> 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 at 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.