Nick Ioffe wrote:
But libgpc installed as static despite WITH_SHARED=yes option. After checking p/rts/Makefile I've pointed out that in that file WITH_SHARED= i.e. is just empty.
You've got to pass this to the make in gcc or gcc/p/rts. The toplevel make doesn't know about it.
After fixing it and making inside the rts I've got the following: nm: libgpc.so.2.1.20030509 not found.
It was because of -Wl,-soname=libgpc.`cat ...` option specified to xgcc on the linking step.
This option might be system-dependent. I've only tested this on Linux so far.
Eliminating it didn't help, now I got another error: LD: DP relative code in file /var/tmp/xxx.o - shared library ...
Adding the -fPIC option used in building the *.lo files to linking command helped.
OK, I'll add that.
Now the question - why configure doesn't do all these things?
Because nobody has implemented it. If you like to do it ...
However, it may be better to wait until support for older gcc versions has dropped (because you don't have to support the different directory structures then) or even until gpc is integraated in gcc (because the directory structure will change again, and rts won't be a subdirectory of p then). Perhaps then the gcc Makefiles will take care of it all, and we don't need extra work ...
Also before that I got some strange errors when configure erroneusly created rts-config.h file - it didn't found open64 and usleep functions in /usr/local/include/fcntl.h - it was discovered by compiler.
What exactly was set? HAVE_OPEN64 and/or OPEN64_DECLARED?
Frank