[stunnel-users] [BUG] SSL directory scan breaks cross-compilation

Mon Nov 3 18:19:31 CET 2014

Michal Trojnara wrote:
> John Spencer wrote:
>> Michal Trojnara wrote:
>>> John Spencer wrote:
>>>
>>>> the concept of searching for a library directory is completely 
>>>> broken. if just adding -lssl -lcrypto to LDFLAGS doesnt find
>>>> the openssl libraries at link time, the user's compiler
>>>> toolchain is wrongly set up, and its not the job of a package
>>>> to work around that by searching through a number of
>>>> directories. it's the user's job to fix his toolchain by
>>>> supplying the right -L paths in case he's got his library
>>>> installed in a non-standard location.
>>> So is the concept of installing headers by default in 
>>> /usr/local/ssl/include rather than /usr/local/include...
>> who does that ?
> 
> OpenSSL does.  This is the default directory.  8-)

that's an utterly idiotic default and no-one in his right mind will use 
that default for a system-wide install.

autoconf based software usually defaults to a /usr/local prefix, with 
the idea that if the user compiles his sw by hand, he doesnt want to 
overwrite the default install. but in that case it makes much more sense 
to install into $HOME or into another directory that doesn't need 
elevated privs.
so 99% of software builds (the majority being automated ones) don't use 
that default. they all specify a --prefix.

> 
>> either way, if a user installed a custom ssl version into
>> $prefix/local instead of the default prefix, he will definitely not
>> expect that the configure script will detect his non-standard local
>> version and use it automatically.
> 
> In fact stunnel only searches *standard* directories used by various
> port systems.  It may happen that a users chose those same directory,
> but this is not why I wrote this detection loop.
> 
>> but in general, openssl needs no special include dirs, no special 
>> CFLAGS, and works by just adding "-lssl -lcrypto -lz" to the
>> linker command line (the -lz covers static linking as openssl
>> depends on zlib). from C code it's supposed to be used like: 
>> #include <openssl/ssl.h> i.e. referencing the openssl dir in the
>> standard include dir. no need to add any fancy -I references for
>> the preprocessing.
> 
> This is an interesting observation.  Now do you usually build OpenSSL
> on platforms that do not have it pre-packaged?

i'm not aware of a unix platform missing pre-packaged openssl, and on 
those (unless created by a fool) the libs and headers are naturally 
installed into the proper include and lib dirs used by the toolchain.
you usually only want to compile openssl by hand if the prepackaged 
version is outdated or misses some compile-time features you want.

but in that case you *want* to install into a non-standard location and 
are *aware* of that.

and then to compile other software against that openssl version, you 
will supply the proper -I and -L flags yourself.

to clarify: a standard toolchain path is one that the toolchain checks 
without the user having to add special flags, usually /usr/lib and 
/usr/include.

> 
> - From the OpenSSL "INSTALL" file:
> 
> #  Quick Start
> #  -----------
> #
> #  If you want to just get on with it, do:
> #
> #   $ ./config
> #   $ make
> #   $ make test
> #   $ make install
> #
> #  [If any of these steps fails, see section Installation in Detail
> below.]
> #
> #  This will build and install OpenSSL in the default location, which
> is (for
> #  historical reasons) /usr/local/ssl. If you want to install it
> anywhere else,
> #  run config like this:
> #
> #   $ ./config --prefix=/usr/local --openssldir=/usr/local/openssl

and ? even though it being the default location of a *manual* and 
mindless openssl install, its not going into the standard directories, 
so it is a non-standard usage and the user of the non-standard stuff 
will have to be explicit to use it.

or do you want to tell me you prefer to satisfy a tiny percentage of 
clueless users that compile stuff without knowing what they do (hence 
automatic library search in non-standard (as in toolchain) directories) 
and break the build for all legitimate crosscompile users ?

if that's a good idea, i wonder why no one else does it.

> 
>> interesting. i'm seeing this "-I=" usage the first time. do you
>> have a reference explaining it ?
> 
> man gcc

$ man gcc | wc -l
64396

neither i nor grep found it in the 65KLOC wall of text. would you mind 
pasting the paragraph ?

--JS