[Dovecot] configure forgets to add -lgcc_s under Solaris 10
Hi all!
I built dovecot-1.2.14 on Solaris 10 with gcc as well as cc and had reproducible crashes of imap-login:
Aug 31 19:00:05 dovecot: Info: Dovecot v1.2.14 starting up Aug 31 19:00:10 imap-login: Info: Login: user=<someuser>, method=PLAIN, rip=<remote_ip>, lip=<local_ip> Aug 31 19:00:10 IMAP(someuser): Error: ld.so.1: imap: fatal: libgcc_s.so.1: open failed: No such file or directory Aug 31 19:00:10 dovecot: Error: child 26222 (imap) killed with signal 9
To solution was to set the environment variable LIBS to "-lgcc_s" before running configure. I think this is a bug as this library should be added automatically by configure to the Makefile when considered necessary. The same problem applies to Dovecot-2.0.1 also, which gave the same error message.
regards, Stephan
P.S. I found a similar message of this issue for version 1.0.rc27 but the suggestions didn't help (i.e. /usr/sfw/lib is already in the RPATH).
On Tue, 2010-08-31 at 19:03 +0200, Stephan Schulz wrote:
To solution was to set the environment variable LIBS to "-lgcc_s" before running configure. I think this is a bug as this library should be added automatically by configure to the Makefile when considered necessary.
But when is it necessary?.. Looks like in my Solaris installation it's been automatically added to dovecot-auth and managesieve binaries, but not elsewhere and Dovecot works just fine. The one special thing about imap/pop3-login binaries is OpenSSL, maybe that's trying to include it automatically?..
Am 31.08.2010 19:23, schrieb Timo Sirainen:
On Tue, 2010-08-31 at 19:03 +0200, Stephan Schulz wrote:
To solution was to set the environment variable LIBS to "-lgcc_s" before running configure. I think this is a bug as this library should be added automatically by configure to the Makefile when considered necessary.
But when is it necessary?.. Looks like in my Solaris installation it's been automatically added to dovecot-auth and managesieve binaries, but not elsewhere and Dovecot works just fine. The one special thing about imap/pop3-login binaries is OpenSSL, maybe that's trying to include it automatically?..
I build the binary with and without OpenSSL support but I get the same result. What else can I try (aside from using LIBS)? What is speaking agains adding the -lgcc_s if configure finds itself on Solaris?
regards, Stephan
On Tue, 2010-08-31 at 19:57 +0200, Stephan Schulz wrote:
What is speaking agains adding the -lgcc_s if configure finds itself on Solaris?
Because it seems like unnecessary workaround. I haven't heard anyone else complain about this than you in the recent years (other than I guess the one other person whose mail you linked to). I'd at least want to understand why this isn't a problem for all Solaris users. Can you compile *anything* without -lgcc_s?
Timo Sirainen wrote:
On Tue, 2010-08-31 at 19:57 +0200, Stephan Schulz wrote:
What is speaking agains adding the -lgcc_s if configure finds itself on Solaris?
Because it seems like unnecessary workaround. I haven't heard anyone else complain about this than you in the recent years (other than I guess the one other person whose mail you linked to). I'd at least want to understand why this isn't a problem for all Solaris users. Can you compile *anything* without -lgcc_s?
I have compiled many many things on Solaris (9 and 10 on SPARC), including Dovecot. I've never had this particular issue. Part of the deal is that I have an environment file that I always source before doing any build work. It sets up all the paths that I need and makes sure the tools and libraries are going to be found. It defines CC, CFLAGS, CPPFLAGS, LDFLAGS and so on. It removes any inconsistencies from the system behavior when I am building software. When I forget to do that, configure will give me odd ball results. Then I just start over and do it right.
Make sure the path to the lib that contains libgcc_s.so, etc., is in your LD_LIBRARY_PATH, CFLAGS and LDFLAGS before running configure. Alternatively, you can use crle (man crle) to set up your load environment. But, I prefer to just build the software correctly in the first place.
On one of my older Solaris 9 systems, using a Sunfreeware version of gcc (and all the gnu tools), I have:
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/usr/ucb:/usr/ccs/bin export PATH LD_LIBRARY_PATH=/usr/local/lib:/usr/lib:/usr/sfw/lib export LD_LIBRARY_PATH CPPFLAGS="-I/usr/local/include" export CPPFLAGS CFLAGS="-L/usr/local/lib -R/usr/local/lib" export CFLAGS LDFLAGS="-L/usr/local/lib -R/usr/local/lib" export LDFLAGS CC=gcc export CC
On my newer Solaris 10 systems it is more complicated, because I'm using gccfss.
Am 31.08.2010 20:14, schrieb Timo Sirainen:
On Tue, 2010-08-31 at 19:57 +0200, Stephan Schulz wrote:
What is speaking agains adding the -lgcc_s if configure finds itself on Solaris?
Because it seems like unnecessary workaround. I haven't heard anyone else complain about this than you in the recent years (other than I guess the one other person whose mail you linked to). I'd at least want to understand why this isn't a problem for all Solaris users. Can you compile *anything* without -lgcc_s?
Yes, I have no problem compiling and using for example GNU-grep, GNU-patch, GNU-make, pkg-config, GNU-tar or the latest xz-utils without having to set the LIBS environment variable. (I hope that this is a little bit representative.)
@Chris: I have setup an environment like you mentioned already. The output of dump -Lv dovecot also reveals that /usr/sfw/lib is in RUNPATH as well as in RPATH. I also checked that libgcc_s.so.1 is really there.
regards, Stephan
On Wed, 2010-09-01 at 08:10 +0200, Stephan Schulz wrote:
Yes, I have no problem compiling and using for example GNU-grep, GNU-patch, GNU-make, pkg-config, GNU-tar or the latest xz-utils without having to set the LIBS environment variable. (I hope that this is a little bit representative.)
But do their binaries link to libgcc_s?
Am 01.09.2010 17:46, schrieb Timo Sirainen:
On Wed, 2010-09-01 at 08:10 +0200, Stephan Schulz wrote:
Yes, I have no problem compiling and using for example GNU-grep, GNU-patch, GNU-make, pkg-config, GNU-tar or the latest xz-utils without having to set the LIBS environment variable. (I hope that this is a little bit representative.)
But do their binaries link to libgcc_s?
I checked back and of the above mentioned programs in fact only GNU-tar (version 1.23) links against libgcc_s.
regards, Stephan
participants (3)
-
Chris Hoogendyk
-
Stephan Schulz
-
Timo Sirainen