When linking the shared object with -G on Solaris:
gcc -g2 -O2 -m64 -march=native -fPIC -pthread -Wno-pointer-sign -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes -Wpointer-arith -Wbad-function-cast -Wnested-externs -L/usr/local/lib -m64 -Wl,-R,'$ORIGIN/../lib' -Wl,-R,/usr/local/lib -G -h libnettle.so.7 aes-decrypt-internal.o aes-decrypt.o aes-encrypt-internal.o aes-encrypt.o aes-encrypt-table.o ...
It results in:
ld.so.1: aes-test: fatal: relocation error: R_AMD64_PC32: file ../.lib/libhogweed.so.5: symbol _init: value 0x7f004df15e9d does not fit ../run-tests: line 61: 12934: Killed FAIL: aes ld.so.1: arcfour-test: fatal: relocation error: R_AMD64_PC32: file ../.lib/libhogweed.so.5: symbol _init: value 0x7f004df15a1d does not fit ../run-tests: line 61: 12939: Killed FAIL: arcfour ld.so.1: arctwo-test: fatal: relocation error: R_AMD64_PC32: file ../.lib/libhogweed.so.5: symbol _init: value 0x7f004df153dd does not fit ../run-tests: line 61: 12944: Killed FAIL: arctwo ...
Here's the full paste of the build using -G: https://pastebin.com/SKZxKfdZ.
Please use -shared, not -G. -shared works as expected on Solaris.
Jeff
Jeffrey Walton noloader@gmail.com writes:
When linking the shared object with -G on Solaris:
gcc -g2 -O2 -m64 -march=native -fPIC -pthread -Wno-pointer-sign -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes -Wpointer-arith -Wbad-function-cast -Wnested-externs -L/usr/local/lib -m64 -Wl,-R,'$ORIGIN/../lib' -Wl,-R,/usr/local/lib -G -h libnettle.so.7 aes-decrypt-internal.o aes-decrypt.o aes-encrypt-internal.o aes-encrypt.o aes-encrypt-table.o ...
It results in:
ld.so.1: aes-test: fatal: relocation error: R_AMD64_PC32: file ../.lib/libhogweed.so.5: symbol _init: value 0x7f004df15e9d does not fit ../run-tests: line 61: 12934: Killed FAIL: aes ld.so.1: arcfour-test: fatal: relocation error: R_AMD64_PC32: file ../.lib/libhogweed.so.5: symbol _init: value 0x7f004df15a1d does not fit ../run-tests: line 61: 12939: Killed FAIL: arcfour ld.so.1: arctwo-test: fatal: relocation error: R_AMD64_PC32: file ../.lib/libhogweed.so.5: symbol _init: value 0x7f004df153dd does not fit ../run-tests: line 61: 12944: Killed FAIL: arctwo ...
Here's the full paste of the build using -G: https://pastebin.com/SKZxKfdZ.
Please use -shared, not -G. -shared works as expected on Solaris.
So you're suggesting the following change, right?
diff --git a/configure.ac b/configure.ac index 09f719a0..ba3ab7c6 100644 --- a/configure.ac +++ b/configure.ac @@ -655,13 +655,13 @@ case "$host_os" in LIBNETTLE_FORLINK=libnettle.so LIBNETTLE_SONAME='$(LIBNETTLE_FORLINK).$(LIBNETTLE_MAJOR)' LIBNETTLE_FILE='$(LIBNETTLE_SONAME).$(LIBNETTLE_MINOR)' - LIBNETTLE_LINK='$(CC) $(CFLAGS) $(LDFLAGS) -G -h $(LIBNETTLE_SONAME)' + LIBNETTLE_LINK='$(CC) $(CFLAGS) $(LDFLAGS) -shared -h $(LIBNETTLE_SONAME)' LIBNETTLE_LIBS=''
LIBHOGWEED_FORLINK=libhogweed.so LIBHOGWEED_SONAME='$(LIBHOGWEED_FORLINK).$(LIBHOGWEED_MAJOR)' LIBHOGWEED_FILE='$(LIBHOGWEED_SONAME).$(LIBHOGWEED_MINOR)' - LIBHOGWEED_LINK='$(CC) $(CFLAGS) $(LDFLAGS) -G -h $(LIBHOGWEED_SONAME)' + LIBHOGWEED_LINK='$(CC) $(CFLAGS) $(LDFLAGS) --shared -h $(LIBHOGWEED_SONAME)' LIBHOGWEED_LIBS='libnettle.so $(LIBS)' ;; *)
IIRC, the reason for current use of -G rather than -shared is that it worked better with Solaris cc. But according to
https://docs.oracle.com/cd/E77782_01/html/E77792/gqexw.html#OSGCCgqfch
-shared was added as an alias for -G in Oracle Developer Studio 12.4, and changed to be more gcc-compatible in 12.6.
Are you able to test if building shared libraries still works with these tools? Support for unusual proprietary compilers linkers is not that high a priority, but it would be nice to keep it working, or at least, know when breaking it.
Here's the full paste of the build using -G: https://pastebin.com/SKZxKfdZ.
: checking build system type... i386-pc-solaris2.11 : checking host system type... x86_64-sun-solaris2
Looks like a cross-compile configuration. Is that intentional?
Regards, /Niels
On Sun, Feb 2, 2020 at 11:06 PM Niels Möller nisse@lysator.liu.se wrote:
Jeffrey Walton noloader@gmail.com writes:
When linking the shared object with -G on Solaris:
gcc -g2 -O2 -m64 -march=native -fPIC -pthread -Wno-pointer-sign -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes -Wpointer-arith -Wbad-function-cast -Wnested-externs -L/usr/local/lib -m64 -Wl,-R,'$ORIGIN/../lib' -Wl,-R,/usr/local/lib -G -h libnettle.so.7 aes-decrypt-internal.o aes-decrypt.o aes-encrypt-internal.o aes-encrypt.o aes-encrypt-table.o ...
It results in:
ld.so.1: aes-test: fatal: relocation error: R_AMD64_PC32: file ../.lib/libhogweed.so.5: symbol _init: value 0x7f004df15e9d does not fit ../run-tests: line 61: 12934: Killed FAIL: aes ld.so.1: arcfour-test: fatal: relocation error: R_AMD64_PC32: file ../.lib/libhogweed.so.5: symbol _init: value 0x7f004df15a1d does not fit ../run-tests: line 61: 12939: Killed FAIL: arcfour ld.so.1: arctwo-test: fatal: relocation error: R_AMD64_PC32: file ../.lib/libhogweed.so.5: symbol _init: value 0x7f004df153dd does not fit ../run-tests: line 61: 12944: Killed FAIL: arctwo ...
Here's the full paste of the build using -G: https://pastebin.com/SKZxKfdZ.
Please use -shared, not -G. -shared works as expected on Solaris.
So you're suggesting the following change, right?
Yes, for GCC.
diff --git a/configure.ac b/configure.ac index 09f719a0..ba3ab7c6 100644 --- a/configure.ac +++ b/configure.ac @@ -655,13 +655,13 @@ case "$host_os" in LIBNETTLE_FORLINK=libnettle.so LIBNETTLE_SONAME='$(LIBNETTLE_FORLINK).$(LIBNETTLE_MAJOR)' LIBNETTLE_FILE='$(LIBNETTLE_SONAME).$(LIBNETTLE_MINOR)'
- LIBNETTLE_LINK='$(CC) $(CFLAGS) $(LDFLAGS) -G -h $(LIBNETTLE_SONAME)'
LIBNETTLE_LINK='$(CC) $(CFLAGS) $(LDFLAGS) -shared -h $(LIBNETTLE_SONAME)' LIBNETTLE_LIBS=''
LIBHOGWEED_FORLINK=libhogweed.so LIBHOGWEED_SONAME='$(LIBHOGWEED_FORLINK).$(LIBHOGWEED_MAJOR)' LIBHOGWEED_FILE='$(LIBHOGWEED_SONAME).$(LIBHOGWEED_MINOR)'
- LIBHOGWEED_LINK='$(CC) $(CFLAGS) $(LDFLAGS) -G -h $(LIBHOGWEED_SONAME)'
- LIBHOGWEED_LINK='$(CC) $(CFLAGS) $(LDFLAGS) --shared -h $(LIBHOGWEED_SONAME)' LIBHOGWEED_LIBS='libnettle.so $(LIBS)' ;; *)
IIRC, the reason for current use of -G rather than -shared is that it worked better with Solaris cc. But according to
https://docs.oracle.com/cd/E77782_01/html/E77792/gqexw.html#OSGCCgqfch
-shared was added as an alias for -G in Oracle Developer Studio 12.4, and changed to be more gcc-compatible in 12.6.
Yeah, -G and -shared seems to be a moving target with some features undocumented.
Are you able to test if building shared libraries still works with these tools? Support for unusual proprietary compilers linkers is not that high a priority, but it would be nice to keep it working, or at least, know when breaking it.
Not at the moment.
I have a Solaris 11.3 box, but it does not have Sun Studio on it. Two other testing machines have Sun Studio 12.1 through 12.6, but both are dead at the moment. I need to order some parts.
Maybe the OpenCSW folks have something that can test Sun Studio. They provide free accounts to developers.
Here's the full paste of the build using -G: https://pastebin.com/SKZxKfdZ.
: checking build system type... i386-pc-solaris2.11 : checking host system type... x86_64-sun-solaris2
Looks like a cross-compile configuration. Is that intentional?
Braindead Autotools. Sun provides a multilib system out of the box, running a 64-bit kernel:
jwalton@Solaris:~$ isainfo amd64 i386 jwalton@Solaris:~$ isainfo -b 64
Sun says to build 64-bit binaries on 64-bit systems. Confer, https://docs.oracle.com/cd/E37838_01/html/E66175/features-1.html.
But Autotools detects the system as i386:
$ /usr/share/automake-1.11/config.guess i386-pc-solaris2.11
So I have to tell Autotools to build for a 64-bit system via --host=amd64-sun-solaris
Jeff
Jeffrey Walton noloader@gmail.com writes:
I have a Solaris 11.3 box, but it does not have Sun Studio on it. Two other testing machines have Sun Studio 12.1 through 12.6, but both are dead at the moment. I need to order some parts.
Maybe the OpenCSW folks have something that can test Sun Studio. They provide free accounts to developers.
I don't have any time to spend on testing with these systems or compilers. Do you think it makes sense to change from -G to -shared unconditionally for Solaris? It makes no sense to try to do something more clever based on compiler used, without any contributor able to test it.
Braindead Autotools.
Please, no derogatory comments about autoconf on this list. And as I think I've said before, the term "autotools" is even more irrelevant here.
But Autotools detects the system as i386:
$ /usr/share/automake-1.11/config.guess i386-pc-solaris2.11
Can you check if latest config.guess (https://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.gues...) has this bug? If not, I can simply upgrade to the latest version. If it's still giving the wrong result, it might make your life easier to submit a patch to fix this problem upstream.
One subtlety is that it might cause problems to say x86_64 if the compiler produces 32-bit i386 binaries by default.
You might also want to test if
CC_FOR_BUILD='gcc -m64' ./config.status
makes any difference.
So I have to tell Autotools to build for a 64-bit system via --host=amd64-sun-solaris
If you get into any subtle problems from configure thinking you're crosscompiling, you might want to add --build=amd64-sun-solaris instead or in addition to setting --host.
Regards, /Niels
On Sun, Feb 2, 2020 at 11:48 PM Niels Möller nisse@lysator.liu.se wrote:
Jeffrey Walton noloader@gmail.com writes:
I have a Solaris 11.3 box, but it does not have Sun Studio on it. Two other testing machines have Sun Studio 12.1 through 12.6, but both are dead at the moment. I need to order some parts.
Maybe the OpenCSW folks have something that can test Sun Studio. They provide free accounts to developers.
I don't have any time to spend on testing with these systems or compilers. Do you think it makes sense to change from -G to -shared unconditionally for Solaris? It makes no sense to try to do something more clever based on compiler used, without any contributor able to test it.
Braindead Autotools.
Please, no derogatory comments about autoconf on this list. And as I think I've said before, the term "autotools" is even more irrelevant here.
They've earned it. They own it.
But Autotools detects the system as i386:
$ /usr/share/automake-1.11/config.guess i386-pc-solaris2.11Can you check if latest config.guess (https://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.gues...) has this bug? If not, I can simply upgrade to the latest version. If it's still giving the wrong result, it might make your life easier to submit a patch to fix this problem upstream.
One subtlety is that it might cause problems to say x86_64 if the compiler produces 32-bit i386 binaries by default.
You might also want to test if
CC_FOR_BUILD='gcc -m64' ./config.status
makes any difference.
So I have to tell Autotools to build for a 64-bit system via --host=amd64-sun-solaris
If you get into any subtle problems from configure thinking you're crosscompiling, you might want to add --build=amd64-sun-solaris instead or in addition to setting --host.
According to the Autoconf docs at "Specifying target triplets", --host is for "the type of system on which the package runs". Confer, https://www.gnu.org/software/autoconf/manual/autoconf-2.65/html_node/Specify....
Neither the latest config.sub or config.guess help. Nor does add -m64 to flags. I've tried both.
Maybe someone can report yet another bug to the Autoconf folks that goes unfixed.
Jeff
Jeffrey Walton noloader@gmail.com writes:
Neither the latest config.sub or config.guess help. Nor does add -m64 to flags. I've tried both.
config.guess is the relevant piece of software. If you can submit a patch upstream, as instructed at the top of the file, that would be great. Otherwise, you'll have to stick to workarounds until someone else decides to fix the problem. Solaris on x86 is a somewhat obscure platform, so good supports will depend a lot on the user community to help eachother out.
Regards, /Niels
Jeffrey Walton noloader@gmail.com writes:
On Sun, Feb 2, 2020 at 11:48 PM Niels Möller nisse@lysator.liu.se wrote:
I don't have any time to spend on testing with these systems or compilers. Do you think it makes sense to change from -G to -shared unconditionally for Solaris? It makes no sense to try to do something more clever based on compiler used, without any contributor able to test it.
Since I have no recent experience with Solaris, nor time to gain any experience, I'd like to hear your opinion on the above question, before I commit any change.
Regards, /Niels
On Mon, Feb 3, 2020 at 12:26 AM Niels Möller nisse@lysator.liu.se wrote:
Jeffrey Walton noloader@gmail.com writes:
On Sun, Feb 2, 2020 at 11:48 PM Niels Möller nisse@lysator.liu.se wrote:
I don't have any time to spend on testing with these systems or compilers. Do you think it makes sense to change from -G to -shared unconditionally for Solaris? It makes no sense to try to do something more clever based on compiler used, without any contributor able to test it.
Since I have no recent experience with Solaris, nor time to gain any experience, I'd like to hear your opinion on the above question, before I commit any change.
Fair enough. I think your best option is to do nothing at the moment. The problem is documented, so searchers should find the fix.
And I can work around it in my scripts with the following:
IS_SUNC=$("$CC" -V 2>&1 | grep -i -c -E 'sun|studio') IS_SOLARIS=$(uname -s | grep -i -c 'sunos') ...
if [[ "$IS_SOLARIS" -ne 0 && "$IS_SUNC" -eq 0 ]]; then sed 's/ -G / -shared /g' configure > configure.fixed mv configure.fixed configure; chmod +x configure fi
I _think_ the best (but unavailable) option is an Autoconf test. But Autoconf does not let you compile and link two files (one for a shared object, and one for a test driver). So it is not an option at this moment. Maybe someone can file another bug report :)
Jeff
On 3/02/20 6:41 pm, Jeffrey Walton wrote:
On Mon, Feb 3, 2020 at 12:26 AM Niels Möller wrote:
Jeffrey Walton writes:
On Sun, Feb 2, 2020 at 11:48 PM Niels Möller wrote:
I don't have any time to spend on testing with these systems or compilers. Do you think it makes sense to change from -G to -shared unconditionally for Solaris? It makes no sense to try to do something more clever based on compiler used, without any contributor able to test it.
Since I have no recent experience with Solaris, nor time to gain any experience, I'd like to hear your opinion on the above question, before I commit any change.
Fair enough. I think your best option is to do nothing at the moment. The problem is documented, so searchers should find the fix.
And I can work around it in my scripts with the following:
IS_SUNC=$("$CC" -V 2>&1 | grep -i -c -E 'sun|studio') IS_SOLARIS=$(uname -s | grep -i -c 'sunos') ... if [[ "$IS_SOLARIS" -ne 0 && "$IS_SUNC" -eq 0 ]]; then sed 's/ -G / -shared /g' configure > configure.fixed mv configure.fixed configure; chmod +x configure fiI _think_ the best (but unavailable) option is an Autoconf test. But Autoconf does not let you compile and link two files (one for a shared object, and one for a test driver). So it is not an option at this moment. Maybe someone can file another bug report :)
To build a .c file with different flags include it into the autoconf test as you would an extra .h file:
SAVED_CFLAGS=$CFLAGS CFLAGS="$CFLAGS -shared" AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#include "src/foo.c"]],[[]])], [ AC_MSG_RESULT(yes) ], [ CFLAGS="$SAVED_CFLAGS"; AC_MSG_RESULT(no) ])
Amos
nisse@lysator.liu.se (Niels Möller) writes:
Do you think it makes sense to change from -G to -shared unconditionally for Solaris?
I've done this change, after digging just a little in the docs.
According to https://docs.oracle.com/cd/E77782_01/html/E77792/gqexw.html#OSGCCgqfch, --shared was added as an alias to -G in Oracle Solaris Studio 12.4, and according to https://en.wikipedia.org/wiki/Oracle_Developer_Studio#History, that version was released in 2014. So I don't expect any breakage from this change. Obviosly, it can't be "supported" in any meaningful way without someone actually using these compilers committing to regularly testing Nettle.
Regards, /Niels
nettle-bugs@lists.lysator.liu.se
-
Amos Jeffries -
Jeffrey Walton -
nisse＠lysator.liu.se