Fwd: sparc elf

[Niklaus]

Hi Kai,

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 <karuottu@mbnet.fi> 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
> '$prefix/$target/sys-include'
> 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:
>  /usr/local/include/c++/3.2.3
>  /usr/local/include/c++/3.2.3/sparc-solaris2.7
>  /usr/local/include/c++/3.2.3/backward
>  /usr/local/include
>  /usr/local/lib/gcc-lib/sparc-solaris2.7/3.2.3/include
>  /usr/local/sparc-solaris2.7/sys-include
>  /usr/local/sparc-solaris2.7/include
> End of search list.
> ^C
>
> 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
> '$prefix/$target',
> then symlink the 'include' to be seen also as the 'sys-include' there, then
> configure your GCC, write 'make ; make install' and everything should
> succeed!
>
> 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
> 'libc.so.1'
> 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
> should
> be much easier than one could think, is the common clue...
>
>
>

--
For unsubscribe information see http://sourceware.org/lists.html#faq