On Wed, Jan 9, 2013 at 10:42 AM, Jakob Bohm <jb-open...@wisemo.com> wrote: > On 1/8/2013 7:59 PM, Jeffrey Walton wrote: >> >> On Tue, Jan 8, 2013 at 1:14 PM, Carson Gaspar <car...@taltos.org> wrote: >>> >>> On 1/8/13 9:52 AM, Jeffrey Walton wrote: >>>> >>>> ... >> >> OT: Do you think the tools will ever catch up? >> >> Autoconf and friends (including Make) never evolved with the addition >> of shared objects. So there's no way to specify a consistent set of >> LDFLAGS tuned both compiled programs and shared objects (which is >> common with library code that supplies utility programs and test >> programs to exercise the library). For example, a shared object needs >> -fPIC and -shared; while a compiled program needs -fPIE and -pie. So >> how do we pidgin hole this common idiom: >> >> ./configure CFLAGS="-Wall -Wextra \ >> -Wconversion -Wstrict-overflow \ >> <other options> <ASLR>" >> >> where <ASLR> is either -fPIC and -shared; or -fPIE and -pie. I think >> we need two LDFLAGS like variables, or use LDFLAGS as a base and >> ability to specify addition personalities for shared objects and >> compiled programs. >> >> And don't get me started on Debug vs Release builds, Autoconf's lack >> of support, and Make's ignorance to changing flags (-g3 -ggdb -O0 vs >> -g -O2). Its too bad we are stuck with using tools form the 1970s >> while the platform and art has evolved. >> > Please don't blame make for the failures of other programs (such as > the autoconf abomination or the cc library linking flags). > > The two big failures are: > > - Autoconf fundamentally assumes that you will compile the source on > every machine that runs it, that there is no cross compiling and that > any arbitrary aspect of the build machine (such as CPU model, kernel > version or installed software) will be equally true at runtime. Much > effort has since been wasted trying to add back cross-machine and > cross-platform abilities. Its even worse. From a recent conversation with Carson (off list):
] Autoconf is broken: ] https://lists.gnu.org/archive/html/automake/2012-12/msg00018.html. In ] response to my question on supporting Debug, Release, and Test ] configurations: "I haven't hit that kind of projects to be honest — I ] would say they don't fare well into the usual automake configs", ] https://lists.gnu.org/archive/html/automake/2012-12/msg00019.html. ] ] All the tools in this toolchain are a mess, and have not evolved. Its ] crippling to folks like me. > - The cc/gcc library linking flags on POSIX-like systems don't > facilitate explicitly specifying which libraries should be linked > statically and which ones dynamically, whichever comes first on > the search path wins. > > - The linker semantics for shared libraries on POSIX-like platforms > take the list of names exported from a shared object on the build > machine as the definition of which names should be exported from > any compatible shared object, which again makes it harder to build > for use on other machines. To further complicate matters, most > systems generate executable binaries that are susceptible to > accidentally calling a similarly named function in a completely > different shared object which happens to be around at run time. I really believe Make is the root of the problem. It did not evolve, so the other tools, such as Autoconf and Automake, did not have to evolve. I've tried finding work arounds from all the tools in the tool chain form Autoconf to GCC. All they do is finger pointing ("that's better suited to be addressed at <X>"), which does not help me with my task. ] Its too bad we are stuck with using tools form the 1970s ] while the platform and art has evolved. This sums it up for me :) Jeff ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
