Re: Help building a 32bit GCC that can generate 32/64bit (x86)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 2011-04-27 at 13:38 -0400, Paul Smith wrote:
> > I'm sorry, you're quite right.  I did not know about that.  You're
> > right, using --enable-targets=all when bootstrapping on a 32-bit ought
> > to give you a compiler which supports the -m64 option.  What failed when
> > you tried that?
> 
> Well to be honest I tried so many different things that I've lost
> track of what failed when.  Let me start fresh and I'll get back to
> you with details if/when I run into things.

OK, it looks like the problem I'm having is that I'm trying to build an
older version of the compiler (I've tried the latest 4.2.x, 4.3.x, and
4.4.x) to match up with compilers that I already have deployed.  When I
try to do this building a cross-compiler, many of the added libraries
simply fail to build properly.  I've discovered that libssp (in 4.2.x
and 4.3.x) and libmudflap (in 4.4.x) fail to build when GCC is
configured as a cross-compiler.  I'd prefer to keep these as we have
used them for testing and debugging in the past.  When trying to create
the shared libraries I get these errors:

.../generic/x86_64-generic-linux-gnu/bin/ld: cannot find crti.o: No such file or directory
.../generic/x86_64-generic-linux-gnu/bin/ld: cannot find -ldl
.../generic/x86_64-generic-linux-gnu/bin/ld: cannot find -lc
.../generic/x86_64-generic-linux-gnu/bin/ld: cannot find crtn.o: No such file or directory

The reason is that although I'm passing --sysroot and the libtool
--mode=link is getting that flag, it is ignored by the libtool in these
directories and not passed to xgcc when trying to create that shared
library.  I've tried setting BOOT_CFLAGS to contain explicit -B /
-isystem settings but that doesn't work either.

I was able to get 4.5.2 to build properly; I suppose these bugs in the
libraries have been fixed.

Does anyone have any idea either where I might find those fixes to think
about backporting them to earlier releases (if they're not too
extensive), and/or some sort of workaround to get this working?  I would
prefer to not be forced to upgrade my compiler as well at this time.

Thanks!



[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux