Hi!
I've tried to make my libgpc be shared.
I work on HP SuperDome - hppa2.0w-hp-hpux11.00 (or at least the configure calls it so).
I've tried to install gpc based on gcc-2.95.X unsuccesfully so I've installed gpc-20030509 based on gcc-3.2.1.
Everything worked OK.
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.
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.
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.
Now the question - why configure doesn't do all these things?
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.
Any ideas, why?
Thank you in advance,
Nick
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
-----Original Message----- From: Frank Heckenbach frank@g-n-u.de To: ioffe_nick@mail.ru, gpc@gnu.de Date: Thu, 24 Jul 2003 18:22:36 +0200 Subject: Re: Linking the libgpc to be shared
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
-- Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707
1. The OPEN64_DECLARED. ---------------------- Also I've discovered some syntax changes that cause me some hardwork in fixing the project: 1. one import and then list of all modules delimited by ';' more than one import like import try; import gpc; doesn't work. 2. repeated routine declaration - now I have to get rid of all the parameters in implementation part - otherwise I get "routine declaration doesn't match previous declaration" error
Is there any way of keeping the sources untouched and still to compile it with 20030507?
Thank you, Nick
Nick Ioffe wrote:
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?
- The OPEN64_DECLARED.
You mean OPEN64_DECLARED was set and HAVE_OPEN64 not, right? And what exactly was the error message by the compiler?
Also I've discovered some syntax changes that cause me some hardwork in fixing the project:
- one import and then list of all modules delimited by ';' more than one import like import try; import gpc; doesn't work.
Yes, that's according to EP.
- repeated routine declaration - now I have to get rid of all the parameters in implementation part - otherwise I get "routine declaration doesn't match previous declaration" error
Repeated parameters still work. If you get an error, the declarations either don't actually match, or there's a GPC bug, but I can't tell without an example.
Frank
----- Original Message ----- From: "Frank Heckenbach" frank@g-n-u.de To: ioffe_nick@mail.ru; gpc@gnu.de Sent: Thursday, July 24, 2003 19:59 Subject: Re: Re[2]: Linking the libgpc to be shared
Nick Ioffe wrote:
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?
- The OPEN64_DECLARED.
You mean OPEN64_DECLARED was set and HAVE_OPEN64 not, right? And what exactly was the error message by the compiler?
Also I've discovered some syntax changes that cause me some hardwork in
fixing the project:
- one import and then list of all modules delimited by ';' more than one import like import try; import gpc; doesn't work.
Yes, that's according to EP.
- repeated routine declaration - now I have to get rid of all the parameters in implementation part - otherwise I get "routine declaration doesn't match previous declaration" error
Repeated parameters still work. If you get an error, the declarations either don't actually match, or there's a GPC bug, but I can't tell without an example.
Frank
-- Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88
1707
1. The rts-config.h had OPEN64_DEFINED undefined, while HAVE_OPEN64 set to 1. That caused the redeclaration of open64 with some gpc file which is conflicting with /usr/local/include/fcntl.h. 2. It is hard to me to provide the example since the machine I run the gpc is not connected to the Internet. The only thing I can say is that the same module compiled well with gpc- 200205??. I'll try to bring some example...
Thank you very much, again - I appreciate your help a lot, and I wish I could contribute promille of what you're doing here.
Sincerely,
Nick.
nick wrote:
Nick Ioffe wrote:
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?
- The OPEN64_DECLARED.
You mean OPEN64_DECLARED was set and HAVE_OPEN64 not, right? And what exactly was the error message by the compiler?
- The rts-config.h had OPEN64_DEFINED undefined, while HAVE_OPEN64 set to
- That caused the redeclaration of open64 with some gpc file which is
conflicting with /usr/local/include/fcntl.h.
You can look in <build>/gcc/p/rts/config.log for the error messages (search for `open64', two places). (If you did several compilations already, you might have to remove config.cache in that directory and make again, because the messages may have been overwritten.)
Or you could try to compile this C program. Does it work, or are there any errors or warnings?
#define _GNU_SOURCE #define _LARGEFILE64_SOURCE #define _FILE_OFFSET_BITS 64 #include <fcntl.h> typedef void (*fntype); volatile fntype tmp; int main() { tmp = (void (*)) open64; return 0; }
Perhaps it's a directory problem (/usr/local/include seems strange for a system header). Does it help if you set `GCC_FOR_TARGET' to `gcc -I /usr/local/include' (and remove all files in <build>/gcc/p/rts, so the RTS is configured again)?
- It is hard to me to provide the example since the machine I run the gpc
is not connected to the Internet. The only thing I can say is that the same module compiled well with gpc- 200205??. I'll try to bring some example...
With luck, you can reduce it so you easily copy it by typing.
Frank
-
"Nick Ioffe -
Frank Heckenbach -
nick