Unga <unga888@xxxxxxxxx> writes: > 1) grep -o '/usr/lib.*/crt[1in].*succeeded' dummy.log > /usr/lib/gcc/i386-unknown-freebsd7.0/4.3.1/../../../crt1.o succeeded > /usr/lib/gcc/i386-unknown-freebsd7.0/4.3.1/../../../crti.o succeeded > /usr/lib/gcc/i386-unknown-freebsd7.0/4.3.1/../../../crtn.o succeeded > > /usr/lib/gcc/i386-unknown-freebsd7.0/4.3.1/../../../crt1.o is > actually /usr/lib/crt1.o, why not refer directly? It has to do with preserving the ability to move the entire gcc installation tree to a new location and have it continue to work. > How it refer /usr/lib/libc.so is as -lc (/usr/lib/gcc/i386-unknown-freebsd7.0/4.3.1/../../../libc.so)! Look at the -L options passed to the linker to see what happens there. > How to fix this? It's not a bug. Don't fix it. > 2) Some files are installed in /usr/lib/gcc/i386-unknown-freebsd7.0/ > and /usr/libexec/gcc/i386-unknown-freebsd7.0/. I prefer files to be > installed in /usr/lib/, /usr/libexec/, etc. Eg. crt* files > (crtbegin.o, crtend.o, etc) to be installed in just /usr/lib/ . How > to get this done? You can just move them by hand if you like. gcc will still be looking for those directories, though. Those directories exist so that you can install multiple versions of gcc for multiple targets on one machine. > 3) I don't think I need header files in > /usr/lib/gcc/i386-unknown-freebsd7.0/4.3.1/include and > /usr/lib/gcc/i386-unknown-freebsd7.0/4.3.1/include-fixed. Normally > they pollute build environment. Any way to not install them too? Again, you can mix them by hand if you like. Be sure that there aren't files with the same name in the two directories, although I don't think that happens these days. These issues all arise in order to support complex installation scenarios. They aren't useful for simple cases like yours, but on the other than they also don't hurt. The best approach is to not let it bother you. Ian
