Re: crossgcc building problem

[Kai Ruottu <kai dot ruottu at luukku dot com>]

miki.shapiro@eAladdin.com wrote:
> 
> Hi
> 
> I'm attempting to build sparc-sun-solaris2.7 targeted gcc-3.0.4 that will
> run on sparc-sun-solaris2.8.
> I have a local gcc 2.95.2 installed from a binary package.
> 
> The problem: when linking the gcc binary (if I understand correctly) - it
> uses the cross-platform linker instead of the local one, thereby making
> a cross-compil*ed* gcc binary, whereas I want a cross-compil*ing* LOCAL gcc
> binary.

 In your log I didn't see anything like that, it only tried to use the new
crosscompiler to build the shared 'libgcc_s.so' for the crosscompiler...
> 
> I have:
> read the FAQ, and a couple more MINI-howtos, so if you send me RTFM'ing,
> sent me to pinpoint locations :-)

 The full GCC-manual, "Using and Porting..." would have been the needed RTFM...
No FAQs, no howtos, nothing else needed if only understanding that the default
$prefix, '/usr/local', can be substituted by something own...
 
 But the Solaris2-target needs some extra info, so please browse the messages
on the archive for this list about producing a solaris2.8 targeted toolchain
for Linux-host (or something). The ideas are just the same...

> c. configured gcc-3.0.4 as follows:
> ./configure --target=sparc-sun-solaris2.7
> --prefix=/usr/local/cpl/sparc-sun-solaris2.7 -v
> --with-headers=/usr/local/cpl/sol7/include
> --with-libs=/usr/local/cpl/sol7/lib
> 
> NOTE: I copied (with subdirs) all libraries and headers from a
> Solaris7/SPARC machine to this Solaris8/SPARC machine to
> /usr/local/cpl/sol7/lib and /usr/local/cpl/sol7/include

 Why you didn't simply copy these directly into the '$prefix/$target' ?,
ie. into:

   /usr/local/cpl/sparc-sun-solaris2.7/sparc-sun-solaris2.7/lib
and
   /usr/local/cpl/sparc-sun-solaris2.7/sparc-sun-solaris2.7/include

Ok, I didn't understand why you will need the double 'sparc-sun-solaris2.7'
here...

 Anyway two important '--with-...' options were replaced with two unnecessary
ones, sigh... (See later)

> At the very end, here's what I got:
> .
> mv tmp-libgcc.map libgcc.map
> /usr/share/src/cross2/gcc-3.0.4/gcc/xgcc

 This is the driver for the just-built new crosscompiler...

> -B/usr/local/cpl/sparc-sun-solaris2.7/sparc-sun-solaris2.7/bin/
> -B/usr/local/cpl/sparc-sun-solaris2.7/sparc-sun-solaris2.7/lib/
> -isystem /usr/local/cpl/sparc-sun-solaris2.7/sparc-sun-solaris2.7/include

and it tries to use the stuff in the $prefix/$target/... (bin, lib, include)

> -shared -nodefaultlibs -Wl,-h,libgcc_s.so.1 -Wl,-z,text -Wl,-z,defs
> -Wl,-M,libgcc.map -o libgcc_s.so

in order to produce the shared 'libgcc_s.so'... But the options used are for
the native Sun-made linker, not for the GNU 'ld'. The 'libgcc.map' will not
be understood as a parameter for '-M' but as a separate file name...

> /usr/local/cpl/sparc-sun-solaris2.7/sparc-sun-solaris2.7/bin/ld:libgcc.map:
> file format not recognized; treating as linker script
> /usr/local/cpl/sparc-sun-solaris2.7/sparc-sun-solaris2.7/bin/ld:libgcc.map:1:
> parse error

And the reason is that you forgot to tell this during 'configure'... You SHOULD
have used the '--with-gnu-as --with-gnu-ld' because you really will use them,
not the Sun-made tools...

> Ideas?

 The 'libgcc.map'-problem was handled a week or so ago... The problems with the
'_ctype_' too (Wrong 'newlib'-related C++-headers were symlinked, not the common
solaris7 & solaris8 ones). And so on... Read the archives, please... And if the
double $target in the paths was a mistake, as I would assume, just remove it when
reconfiguring after a 'make distclean'...

 You also seemed to configure in the source directory, which isn't recommended
nowadays... Please make a separate 'build' directory, for instance a 'gcc-3.0.4/build'
(a subdir into the main source directory) and then run '../configure <parameters>'
from it...

Cheers, Kai



------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com