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] |
"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] |