This is the mail archive of the crossgcc@sources.redhat.com 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]

Re: Cross-compilers _without_ copying all of include & lib


"Paul Smith" <pausmith@nortelnetworks.com> wrote:

> %% Yves Rutschle <y.rutschle@indigovision.com> writes:
> 
>   yr> In that case, I'd suggest trying to simply remove include/ and
>   yr> lib/ and replace them with symlinks to the target's files.
> 
> I have to believe that this situation is common enough that it should be
> possible to do it in GCC without huge amounts of effort... but maybe I'm
> wrong until --sysroot is available :-P.

 Ok, you maybe didn't mean just the symlinking but what on earth is so
hard in it?

> Well, I'm now trying to pre-create the sys-include and lib directories
> as symlinks to the real thing: if I put a file COPIED in those
> directories with the right format, then gcc's configure.in won't try to
> copy them.

 Just never use the '--with-headers=' and '--with-libs' again!  They are
only some wacky rubbish in the very big mess called "Installing GCC"
among the 'gnu.org' documents... This also claims that building GCC
is possible when only having a C compiler... The C part in GCC is a
"C compiler" but building GCC without a C library is still completely
impossible, one requires it when creating executables and even its
headers when compiling anything... Really pure rubbish.  A newbie
only can expect a "C compiler" being capable to create executables.
GCC is such but doesn't include any kind of C library anywhere.

 The '$prefix/$target/include' is AFAIK the de-facto standard place for
the target headers. The ''$prefix/$target/sys-include' has been used to
put the Linux kernel headers there, for instance the RedHat's EDK had
it used this way (EDK = Embedded Development Kit, their Linux-target
tools for embedded x86 and PPC cards). I don't know about the MontaVista
etc. tools, but if they put the Linux standard headers into the 'sys-include',
let people know !  But if '/usr/include' has those 'asm' and 'linux' symlinks,
keeping them in '$prefix/$target/include' could be preferred.

 The fact is that stuff like 'limits.h', 'stdlib.h' and 'unistd.h' will be searched
from the 'sys-include' during the GCC-build, so these should be seen there
too. Builds using my old glibc-2.2.5's in the gcc-3.3.2 showed that fixing
the parameter name '__thread' in protos was necessary, this new GCC
uses it as a type or something. The 'pthread.h' and 'bits/sigthread.h' maybe
were those needing fixing. Nothing else in the glibc-2.2.5 headers.  In these
cases my advice is to let the GCC build to try to fix the headers by symlinking
all the 'include' stuff into the 'sys-include'. Then check the fixes made (into
'$build/gcc/include'), move the fixes to the originals and remove the fixed
headers (from '$build/gcc/include') before installing.  Why to maintain buggy
headers to be fixed again and again is more than unclear...  Maybe the
symlink between 'include' and 'sys-include' could be keeped for later builds.
Or one decides whether it is necessary to let them being 'fixed', scanning them
takes time altough nothing would be fixed... 

> Now the problem I'm having is that on the real system the libraries are
> split between /lib and /usr/lib (as is normal for any Linux system) and
> my symlink can point to only one.  Unfortunately there is data needed
> from both.  Of course, the copy would also have this problem since it
> would copy only one.  Argh.

 Ok, my thought was that the '-print-search-dirs', like:

/home1/kai > ppc-linux-gcc-3.2 -print-search-dirs
install: /usr/local/lib/gcc-lib/ppc-linux-gnu/3.2.3/
programs: =
/usr/local/lib/gcc-lib/ppc-linux-gnu/3.2.3/:
/usr/local/lib/gcc-lib/ppc-linux-gnu/3.2.3/:
/usr/local/lib/gcc-lib/ppc-linux-gnu/:
/usr/lib/gcc/ppc-linux-gnu/3.2.3/:
/usr/lib/gcc/ppc-linux-gnu/:
/usr/local/ppc-linux-gnu/bin/ppc-linux-gnu/3.2.3/:
/usr/local/ppc-linux-gnu/bin/
libraries: =
/usr/local/lib/gcc-lib/ppc-linux-gnu/3.2.3/:
/usr/lib/gcc/ppc-linux-gnu/3.2.3/:
/usr/local/ppc-linux-gnu/lib/ppc-linux-gnu/3.2.3/:
/usr/local/ppc-linux-gnu/lib/

(edited to make this clearer)

would give another version-independent search directory for libraries, not only the
'$prefix/$target/lib'. But as seen, there are three version-dependent directories and
only one version-independent directory...  But of course with every GCC-version the
'$prefix/gcc/$target/$gcc-version'  (here '/usr/lib/gcc/ppc-linux-gnu/3.2.3') could be
symlinked to the '$sysroot/lib' if the '$prefix/$target/lib' will be symlinked to the
'$sysroot/usr/lib'.  It is really weird that there has been years all kind of not used
directories, but when one would like to take one more in use, none of these isn't
perfectly suitable...

 Maybe my 'fixed' search dirs (the ugly relative paths removed) don't have all the
possible standard search directories, but anyway the '-print-search-dirs' could give
some choices. If so, I think the symlink-scheme, 'w2w' (what-to-what),  could have
some kind of suggested standard...

 If at least some people would have required that a cross-GCC SHOULD HAVE
more than one version-dependent search directory, when the native ones have
too ('/lib' and '/usr/lib'), and GCC supports them, that would have been implemented
years ago.  The question is why this didn't happen?  Maybe there hasn't been any
need for NFS-mounted alien filesystems yet...

 The weird '$prefix/$target/lib/$target/$gcc-version' could have been just as well a
'$prefix/$target/sys-lib', and being a place for the 'system libraries, ie. for the runtime
libraries and being searched before the '$prefix/$target/lib'...

 Or the '$prefix/$target' could just have been the default $sysroot-like place with the
'.../lib', .../usr/lib', '.../usr/include' etc. places being searched, if wanted so.

 "It is Earlier When You Think", suits here very well, some people needing these things
would have caused them implemented years ago.  Changing those default search
places in 'gcc/gcc.c' shouldn't be that hard, so that even a novice could do that. Adding
there more could be much harder... When there are now two wacky ones, changing
them could result my 'ppc-linux-gnu' tools to show :

libraries: =
/usr/local/lib/gcc-lib/ppc-linux-gnu/3.2.3/:
/usr/local/lib/gcc/ppc-linux-gnu/3.2.3/:
/usr/local/ppc-linux-gnu/sys-lib/
/usr/local/ppc-linux-gnu/lib/

 The '$prefix/lib/gcc/$target/$gcc-version' seems to replace the old with 'gcc-lib', so if
two target/version dependent places could be required, this could be my suggestion...
Must try changing those default search places for libraries...

> Actually, I'm not so sure about that in one way: it doesn't seem that
> the compiler build/install puts any compiler-specific files in those
> directories.  So, in that sense they are not needed.

 Actually I would check where those 'libstdc++.so's etc. will be installed if using
'make install'... For years I have had my own install-scripts to put the libs etc.
where I want them being installed, not where the GCC-developers want them
being installed!

 By opinion is that the extra libraries, libiberty, libstdc++, libffi,... whatever there
are, belong to the specific target/GCC-version, not only to the specific target!
So putting them into the '$prefix/$target/lib' and maybe overwriting the previous
GCC install stuff there,  is seriously wrong.  But maybe I'm the only one with
several GCC versions for a target (huh, I must be an alien from Mars)...  So I
put this stuff into the '$prefix/lib/gcc-lib/$target/$gcc-version' with my install-
scripts, not into '$prefix/$target/lib' where I think the 'make install' putting them.

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]