Fwd: sparc elf
Sat Jun 17 13:35:00 GMT 2006
Thanks for all the help.
Few more questions that i have are ,
1) There are 2 directories /tmp/lib which contains libc.so.1 linked to libc.so
and /tmp/usr/lib which contains libC-xyz.so
The header files are in /tmp/usr/include (extraced from SUNWhea).
So is it better to copy /tmp/lib to $prefix/$target
and copy /tmp/usr to $prefix/$target
or am i doing something wrong.
On 6/16/06, Kai Ruottu <email@example.com> wrote:
> Niklaus kirjoitti:
> > Hi Kai,
> > I just copied header from SUNWhea and SUNWcslib. I coped the headers
> > into /tmp/usr/include and c libraries into /tmp/usr/lib and some in
> > /tmp/lib/.
> > So what configure options should i use here other than the below
> > /home/pro/gcc-3.4.6/configure --target=sparc-solaris2.8
> > --prefix=/home/pro/sparc-sol/ --disable-shared
> > --with-headers=/tmp/usr/include/
> You should also copy/move the '/tmp/usr/lib' stuff into the expected
> '$prefix/$target/lib', here '/home/pro/sparc-sol/sparc-solaris2.8/lib'.
> But you should remove the tailing '/' from your $prefix value otherwise
> you will have two slashes in the search paths.
> Generally you could also remove the '--with-headers=' option. It doesn't
> do anything else than copies the pointed stuff into the
> and puts an empty 'COPIED' file there. So if you can copy the 'lib', then
> you maybe can copy the 'include' too! But maybe you want to use the
> 'official' directory, '$prefix/$target/include'. The '.../sys-include'
> is used
> during the GCC build for some totally weird reason. No explanation seen
> ever. Anyway a cross-GCC searches them both as default :
> E:\usr\local\lib\gcc-lib\sparc-solaris2.7\3.2.3>cc1plus -v
> GNU CPP version 3.2.3 (with Broadcom and MinGW patches) (cpplib) (sparc ELF)
> ignoring nonexistent directory "NONE/include"
> #include "..." search starts here:
> #include <...> search starts here:
> End of search list.
> So symlinking the 'include' to be seen also as the 'sys-include' will
> replace the
> task done with the '--with-headers='. The 'sys-include' is the
> equivalent to
> the native SYSTEM_INCLUDE_DIR which most systems don't have or
> use... Some systems like Cygwin, MinGW, BeOS and Mach have two
> separate header directories and this possibility was taken into account....
> Wrong place for the headers but people very seldom report this GCC
> "feature" as a bug :-( With the embedded targets this 'feature' really can
> become a bug, the final target headers will be put into the 'include' in the
> newlib install, if the generic ones needed during the GCC build are still
> in 'sys-include' ('--with-headers=' was used), then these generic ones
> will be found before the final ones!
> So just move/copy the 'include' and 'lib' dirs into your chosen
> then symlink the 'include' to be seen also as the 'sys-include' there, then
> configure your GCC, write 'make ; make install' and everything should
> Oops, also the '--disable-shared' is totally vain, rather use the
> '--enable-shared --enable-threads' !
> The symlinks in the 'lib' of course should be ok, for instance the
> being symlinked to be seen as the 'libc.so'. And every other '.so.1' or
> '.so.2' seen as a '.so' via symlinks.... I don't remember anything else but
> maybe I forgot some "trivial" thing... That all the possible problems
> be much easier than one could think, is the common clue...
For unsubscribe information see http://sourceware.org/lists.html#faq
More information about the crossgcc