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 ?

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. instead, he will supply his custom libdir via LDFLAGS=-L/whatever/local/lib to configure, just like he does for all the other packages using his custom ssl lib.

also note that $prefix can be anything. in case of sabotage linux it's empty (i.e. there's /bin, /lib, /include, /share, ..., but no /usr/lib, ...), there is no /usr (it solely exists as a symlink to / in order to help dealing with broken hardcoded assumptions).

there was some /usr hype ("the /usr move") promoted lately by the systemd folks and their redhat-financed propaganda machinery, but that is not a guarantuee that everyone and his dog follows poettering's recommendation. if the prefix was /usr everywhere, the --prefix option for configure would make little sense i guess...

...

also, there's pkg-config (which supports crosscompilation via a PKG_CONFIG_SYSROOT_DIR env var) in case a library needs elaborate CFLAGS.

Do you suggest that stunnel should also require pkg-config as a building prerequisite?

require ? no. i'm not an expert in writing autoconf scripts (i usually just use plain Makefiles), but i'm pretty sure that autoconf ships with predefined pkg-config helper macros/scripts that fall back to some sensible mechanism when it is not installed. however it's available almost everywhere, because you simply cannot build the majority of OSS without it (most notably anything building on glib).

there's a lot of sw out there that uses autoconf to detect openssl, and almost all of them do it right. maybe looking at their configure scripts could give clues about the right way to check for it.

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.

...

the libtool turns -lssl into /lib/libssl.so, because it's on old version of libtool that doesnt respect the --with-sysroot configure flag.

since this didnt happen with 5.02, it looks strongly as if the latest release was created on a different box with a way older autoconf and libtoolize installed than 5.02.

Thank you. I'll make sure the next release is built with a newer libtool.

great!

...

another issue is that -I/usr/kerberos/include is passed to the build. this is another hardcoded and wrong path somewhere in the buildsystem which would break my build in case i had kerberos installed on my box. in that case it would pull in host headers rather than headers from my x-compile sysroot. fortunately i don't have it.

Your other headers would also need to include a kerberos header, and your your OS would need to have RedHat-specific /usr/kerberos/include, right? I doubt it to be a real risk, so I implemented the simplest possible workaround (vide: KISS principle).

i'm not sure about kerberos. is it really redhat-only (i doubt it)? if so, the assumption that the prefix is always /usr is probably legit. but that could change as well, and it of course breaks cross-compilation even on a redhat box. the right way to deal with it is probably to just use the usual autoconf/pkg-config mechanisms to check for it.

What about changing -I/usr/kerberos/include to -I=/usr/kerberos/include (i.e. relative to sysroot)?

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

Thanks, --JS

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