[Cryptlib] makefile patches from MacPorts

[Jeffrey Walton]

...
...

There's another hidden issue that's not readily apparent. That's
calling LD directly rather than allowing the compiler driver to invoke
it.

If someone tries to cross-compile out of the box by specifying CFLAGS
and CXXFLAGS (like CFLAGS += --sysroot=...), or someone uses Clang's
sanitizers to test the library (CFLAGS += -fsanitize=undefined
-fsanitize=address), then the linker will fail the link due to missing
libraries.

Passing sysroot and sanitizers through CFLAGS and CXXFLAGS and using
the compiler driver to invoke the linker ensures everything is passed
correctly. You can do it invoking LD directly, its just much more
painful.

I perform sanitizer checks and cross compiles frequently on libraries.
This is a recurring problem in nearly every library I acceptance test
and port.

_______________________________________________
Cryptlib mailing list
***@mbsks.franken.deAdministration via Mail: cryptlib-***@mbsks.franken.de
Archive: ftp://ftp.franken.de/pub/crypt/cryptlib/archives/
http://news.gmane.org/gmane.comp.encryption.cryptlib
Posts from non-subscribed addresses are blocked to prevent spam, please
subscribe in order to post messages.

[Jeffrey Walton]

...
We append to CFLAGS, rather than overwriting them, and remove the line that clears LDFLAGS. It is customary for users to want to be able to specify CFLAGS and LDFLAGS (and CXXFLAGS and CPPFLAGS) at the command line, and we do want to do that in MacPorts.

There's one more small issue here (if interested):

CFLAGS += -c -D__UNIX__ -DNDEBUG -I.

By placing the library's CFLAGS after the user's CFLAGS, the library
effectively overrides anything that conflicts.

I think it should be the other way around: the user's CFLAGS are
appended to the library's CFLAGS so the user's flags have precedence.
We did the same in OWASP's ESAPI C++ so we did not step on user's
CFLAGS/CXXFLAGS. See
https://code.google.com/p/owasp-esapi-cplusplus/source/browse/trunk/GNUmakefile.

Jeff

_______________________________________________
Cryptlib mailing list
***@mbsks.franken.deAdministration via Mail: cryptlib-***@mbsks.franken.de
Archive: ftp://ftp.franken.de/pub/crypt/cryptlib/archives/
http://news.gmane.org/gmane.comp.encryption.cryptlib
Posts from non-subscribed addresses are blocked to prevent spam, please
subscribe in order to post messages.

[Peter Gutmann]

Passing sysroot and sanitizers through CFLAGS and CXXFLAGS and using the
compiler driver to invoke the linker ensures everything is passed correctly.
You can do it invoking LD directly, its just much more painful.

OK, so what changes are necessary to the makefile for this to function the way
you want? Note that is has to be portable (i.e. not Gnu make specific) since
cryptlib has to build on all sorts of weird stuff, which means things like +=
and ?= and the like are out (they've only been in Posix for a few years, see
http://austingroupbugs.net/view.php?id=330, which means there'll still be lots
of makes that don't handle them).

Peter.

_______________________________________________
Cryptlib mailing list
***@mbsks.franken.deAdministration via Mail: cryptlib-***@mbsks.franken.de
Archive: ftp://ftp.franken.de/pub/crypt/cryptlib/archives/
http://news.gmane.org/gmane.comp.encryption.cryptlib
Posts from non-subscribed addresses are blocked to prevent spam, please
subscribe in order to post messages.

[Peter Gutmann]

Post by Jeffrey Walton
CFLAGS += -c -D__UNIX__ -DNDEBUG -I.
By placing the library's CFLAGS after the user's CFLAGS, the library
effectively overrides anything that conflicts.
I think it should be the other way around: the user's CFLAGS are appended to
the library's CFLAGS so the user's flags have precedence. We did the same in
OWASP's ESAPI C++ so we did not step on user's CFLAGS/CXXFLAGS. See
https://code.google.com/p/owasp-esapi-cplusplus/source/browse/trunk/GNUmakefile.

The problem is that this uses += again... the reason why the makefile calls
out to shell scripts is because that was the only way to do things in a
portable manner without lots of ugly hackery. For example in the above
makefile there's extensive use of ifeq (and ifneq, and in general make-as-a-
scripting-language) that won't work with any generic make.

Peter.


_______________________________________________
Cryptlib mailing list
***@mbsks.franken.deAdministration via Mail: cryptlib-***@mbsks.franken.de
Archive: ftp://ftp.franken.de/pub/crypt/cryptlib/archives/
http://news.gmane.org/gmane.comp.encryption.cryptlib
Posts from non-subscribed addresses are blocked to prevent spam, please
subscribe in order to post messages.