[prev in list] [next in list] [prev in thread] [next in thread] 

List:       sylpheed
Subject:    [sylpheed:21662] 0.9.6 report/proposals
From:       Rumi Szabolcs <rumi_ml () rtfm ! hu>
Date:       2003-09-26 8:16:31
[Download RAW message or body]

Hello!

I have recently installed 0.9.6 onto Solaris 9, including GNU
iconv/gettext, OpenSSL, IPv6, LDAP, gdk-pixbuf, and GPG support.
Sylpheed has been compiled with the Sun Forte 7 compilers with
-O4 optimization and I did not experience any portability problems,
just a few typecast warnings, very good.

I had some problems with the configure script though:

- It is not possible to explicitly set the ssl library prefix
for the ./configure script. There was some auto-detection via
the runtime library path so that -L/opt/openssl/lib made it into
LDFLAGS= in src/Makefile, but for the includes I had to edit the
Makefile and put an -I/opt/openssl/include in there by hand. I'd
suggest adding a --with-ssl-prefix=<path> flag to ./configure
to be able to set it explicitly (and generally, I suggest this
for every library)

- I have explicitly set gpgme prefix using --with-gpgme-prefix,
but this did not fully work as expected. The situation is following:
I've got gpgme 0.4.x installed into a /opt/gnupg tree because
gpa depends on that, and i've got 0.3.x installed into /opt/sylpheed
because sylpheed needs it. /opt/gnupg/lib is in the runtime library
search path. So when I specify --with-gpgme-prefix=/opt/sylpheed to
./configure to use the 0.3.x one explicitly, this correctly makes
it's way into src/Makefile in terms of GPGME_INCLUDES but for the
LDFLAGS, it probably finds the 0.4.x one in the runtime path so that
-L/opt/gnupg/lib happens to land in the LDFLAGS= line in src/Makefile
instead of the explicitly given /opt/sylpheed/lib.

Best regards,

Szabolcs Rumi

[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic