Cactus should not pass its makefile options to make commands

Issue #1253 closed
Roland Haas created an issue

The Cactus make file supports a couple of options that are specified as options on the command line (from option lists etc). make currently exports these as shell environment variables to the sub-makes (which is fine) and also to any executed command (which can cause problems).

There are some options that are directly used by the make file: * options (ie. used to specify and options list) * PROMPT * SILENT * VERBOSE

OpenSSL's config script (contains a bug/or uses the same mechanism) and will interpret "options" as an option of its own. This is not visible when using simfactory it seems the reason is that simfactory first creates a configuration via

echo yes | make sim-config options=optionlist.cfg

then build and configures the thorns in a second step via a

make sim

Using however

make sim-config options=optionlist.cfg PROMPT=no

yields an error message from OpenSSL's config script

OpenSSL: Configuring...
Operating system: x86_64-whatever-linux2
Configuring for linux-x86_64
target already defined - linux-x86_64 (offending arg: simfactory/mdb/optionlists/bethe.cfg)

Keyword:

Comments (8)

  1. Frank Löffler
    • removed comment

    The problem here is OpenSSL's 'config' script (from the OpenSSL distribution). It also uses the $options environment variable to specify openssl-configure-options (see line 45). Rather than changing the pass-down of Cactus options which might be useful, it should also work to unset the variable $options before executing './config --prefix=${OPENSSL_DIR}' in the configure.sh script of the thorn. Can you try that?

  2. Roland Haas reporter
    • removed comment

    Adding and "unset options" just before calling "./config" in ExternalLibraries/OpenSSL/configure.sh avoids the issue and lets OpenSSL compile (this was the first thing I changed, even before backtracking why "options" was set in the manual make call and unset in simfactory, sorry for not pointing this out :-) ).

    This issue is a bit similar to #332.

  3. Frank Löffler
    • removed comment

    If this works as you indicated, I propose to resolve the specific issue here by unsetting options. This is the less invasive change and as you pointed out, we already have at least one other ticket to deal with the more general problem.

  4. Roland Haas reporter
    • removed comment

    I attach a patch that unsets "options" just before calling OpenSSL's "config" script (and leaves "options" unset for the remainder of the file).

    Will apply on or after Friday unless objections are raised.

  5. Frank Löffler
    • changed status to open
    • removed comment

    That was exactly what I was proposing without actually creating a patch because it's so simple. Thanks, and please apply.

  6. Roland Haas reporter
    • changed status to resolved
    • removed comment

    Applied as rev 39 of OpenSSL (and even more emails are being created :-) ). Yes, this patch likely fell under the "trivial" clause of our commit policy (and if I could find it I would even provide a link to it).

  7. Log in to comment