Re: [Pan-users] Configure failure of 0.135

[Duncan]

Ron Johnson posted on Tue, 13 Sep 2011 23:26:50 -0500 as excerpted:

> I think that ./configure doesn't require that the ssl dev files exist.
> When I installed libssl-dev (Debian-based distro), then pan built
> correctly.
> 
> Here's what the failed build looked like:
> 
> $ git clone git://github.com/judgefudge/pan2 $ cd pan2 $ ./autogen.sh
> <big snippage>
> config.status: executing default-1 commands config.status: executing
> po/stamp-it commands
> 
> 
> Configuration:
> 
>          Source code location:        . Compiler:             g++
>          With GtkSpell:          yes
> 
> 
> Now type `make' to compile Pan
> 
> 
> $ make <massive snippage>
>    AR     libpangui.a CXX    gui.o CXX    pan.o CXXLD  pan
> /usr/bin/ld: cannot find -lssl collect2: ld returned 1 exit status
> make[3]: *** [pan] Error 1 make[3]: Leaving directory
> `/Data/ron/source/pan2/pan/gui'
> make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory
> `/Data/ron/source/pan2/pan'
> make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory
> `/Data/ron/source/pan2'
> make: *** [all] Error 2

That appears to be the final link in the build phase (it does something 
with translations afterward, but no more compiling or linking).

The problem is, pan itself doesn't require the ssl library (-lssl) at all 
to build or link, and indeed, doing a search (case insensitive) in my pan 
build output for ssl comes up entirely empty, no -lssl, no other strings 
with ssl in the name, either.  Further, there's no ssl in the output from 
ldd /usr/bin/pan, either, so if it's linking against an ssl library, it's 
one that doesn't have ssl in the name, at least on Gentoo.

I don't even know for sure what library it's looking for, tho I can guess 
either openssl or nss (mozilla's secure connection library 
implementation), based on the fact that -lssl implies an ssl.h headerfile, 
and querying the installed package database for owners of ssl.h returns 
those two (plus one for claws-mail, obviously unrelated) hits.

That suggests a distro-related dependency, likely a library pulled in as 
an indirect dependency by some random *.la file, but never actually 
linked against by pan.

FWIW, I run Gentoo, here, with --as-needed in my LDFLAGS to avoid 
overlinking (that helps reduce the rebuilds necessary when a core library 
like expat is upgraded by SEVERAL fold! it's in the Gentoo default LDFLAGS 
now but wasn't back when I added it to my own), and with an install-mask 
that eliminates all *.la files (with the exception of libtool's own 
libltdl.la, since many configure scripts use its existence to check for 
libtool itself) before they're installed to the live filesystem, as I 
don't do static builds and the *.la files seem to cause more troubles 
than they solve for modern dynamic-linked builds... as it seems they may 
be doing for you right now.

Gentoo, as a from-source distro, of course always installs the header-
files, etc, no separate -dev package for them.  However, back in the days 
when I ran a binary distro (late 2001 to early 2004, Mandrake), the 
technique I generally used to solve such distro-specific dependencies 
before building an upstream version was to build the distro's own src-
pkg, whatever version it was, first.  After I'd built the version the 
distro supplied from the distro sources, all the packages including -dev 
packages necessary for building it were obviously installed, and all I 
had to worry about when building the upstream version was any new or 
upgraded dependencies (with the upgraded ones much simpler too, since I 
already had a clue what I needed, I just had to find newer versions), 
making the process *MUCH* simpler. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman