* Howard Arons (hlarons@ComCAT.COM) [20000214 20:45]:
However, I DO have a directory /usr/lib/gcc-lib/i486-linux/egcs-2.91.66, which contains just a few items:
2304771 Nov 6 11:14 cc1plus 29 Jan 28 09:29 libg++.a -> ../../../libg++-libc6.1-1.a.2 30 Jan 28 09:29 libg++.so -> ../../../libg++-libc6.1-1.so.2 32 Jan 28 09:29 libstdc++.a -> ../../../libstdc++-libc6.1-1.a.2 33 Jan 28 09:29 libstdc++.so -> ../../../libstdc++-libc6.1-1.so.2
Which means you have packages gpplib installed, that's useless without egcs.
If you're using a 2.2.X kernel, delete packages gcc and gccfront and maybe reinstall egcs.
If I understand your suggestion, using the egcs package instead of gcc/gccfront will allow such compiles to work without all this fooling around. I'd like to believe that, and I'm going to try it (after deleting gccfront of course).
gcc is gcc 2.7.2.3 and gccfront the driver (/usr/bin/gcc). As I wrote, these are only needed for compiling 2.0.X kernels. If you don't intend to do that, you may safely delete both packages. BTW, for programs written in C++, you need packages gpp and gpplib and gpp *requires* egcs to be installed.
I wonder if you'd care to comment on one last item: During my 6.3 install, I originally installed egcs. Later I changed my mind and used YaST to delete egcs and install gcc and gccfront. I wonder if YaST's uninstall operation was faulty, leaving some files/dirs around that perhaps shouldn't exist, and causing the problems I've described.
Well, maybe a bit. As It seems that it left the /usr/bin/gcc from egcs in place (this would account for the 'egcs 2.92' version). This frontend of cause won't pass the correct paths to the C runtime objects (crt*.o) and libgcc.a to the programs it calls.
Likewise, add -L directives for the directories that contain libm.a and libc.a to take no chances.
Also wrong. If not linking statically (i.e. -static), ld searches for libc.so and libm.so in the order: specified via -L->/usr/lib->/usr/local/lib.
Bear in mind that it is not the *.so libraries that are not found, it is the library archives (*.a), as specified by the -l arguments to the linker.
Not quite, if you pass a library name via -l and you don't specify static linking, it will first search for the dynamic library (lib.so) and only if it doesn't find that it will use the static lib.
My interest now is in learning whether the problem is mine, xfstt's or SuSE's.
Well, it's a mix of yours and SuSE's, but mostly yours. In 6.4, this won't happen, as we're switching to gcc 2.95.2. So such problems with compiler versions should vanish.
As for 'gcc --print-search-paths', it's not in the man or info pages that I could find, so I have no idea what it does.
Do you have the info files for gcc installed? It's a seperate package (gccinfo.rpm from series doc). This option will make gcc print out the directories it searches for programs and files it needs and also passes to programs it calls. So calling gcc like this would show if it searches in the right places.
BTW, you copied your note to suse-linux, not to suse-linux-e where I posted.
Yeah, I allready noticed that :) This is the result of having two very
similiar aliases for those lists and not really checking the header before
sending the mail.
Philipp
--
Philipp Thomas