This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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
So is it better to copy /tmp/lib to $prefix/$target and copy /tmp/usr to $prefix/$target
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |