> With the current build system, user-defined CFLAGS are accepted as any > unrecognized command line argument passed to Configure. This seems a > little dangerous to me since it means a simple typo could end up > getting passed to the C compiler.
Is it more dangerous than interactive access? But on serious note I don't quite grasp the problem. How do you pass CFLAGS? Or rather how is it specific to OpenSSL? I mean you either set CFLAGS environment variable and call 'make -e' or call 'make CFLAGS=something', right? But this is the way *make* is. Or is suggestion that we should implement own internal .ext1.ext2 rules independent on CFLAGS? > As well, the current build system forcibly enables optimization (-O3) > or debug symbols (-g) depending on the build type (--release or > --debug). Could you elaborate on the problem? If you need release build with debug symbols you can simply add -g when configuring... > There does not appear to be any method for the user to pass additional > LDFLAGS to the build system. You can pass them as arguments to ./Configure script. It recognizes -L, -l and -Wl,. > I would like to propose the following changes: > > 1. Read CFLAGS and LDFLAGS from the environment within the Configure script. > 2. Allow the user to opt-out of the default release or debug cflags, > perhaps by adding a third build type (neither release nor debug). > > These changes would my job as a distro maintainer on Gentoo Linux just > a little bit easier. Or maybe ("maybe" is reference to "I don't quite grasp" above) what we are talking about is Configure reading CFLAGS and LDFLAGS and *adding* them to generated Makefile. I mean we are not talking about passing them to 'make', but "freezing" them to their values at configure time. Could you clarify? -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4664 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev