ExternalLibraries/OpenSSL does not compile in 64-bit mode on Mac OS

Create issue
Issue #339 closed
Ian Hinder created an issue

Compiling OpenSSL using ExternalLibraries leads to the following warning, followed by a build failure:

  • cd openssl-1.0.0d
  • ./config --prefix=/Users/ian/Cactus/et/configs/fink/scratch/external/OpenSSL Operating system: i686-apple-darwinDarwin Kernel Version 10.6.0: Wed Nov 10 18:13:17 PST 2010; root:xnu-1504.9.26~3/RELEASE_I386 WARNING! If you wish to build 64-bit library, then you have to invoke './Configure darwin64-x86_64-cc' manually. You have about 5 seconds to press Ctrl-C to abort. Configuring for darwin-i386-cc

I don't know how to detect that the compiler is building in 64-bit mode in order to add the corresponding flag to the Configure line.

Keyword: ExternalLibraries/OpenSSL

Comments (14)

  1. Ian Hinder reporter
    • removed comment

    A workaround is to set

    OPENSSL_DIR = /usr

    in your optionlist. It seems that the library and headers are installed on Mac OS (possibly as part of the developer tools which are needed anyway to compile). Actually, the OpenSSL.sh script should look there first by default if OPENSSL_DIR is unset. It fails to find the library because it looks for a file called libssl.a when it should be looking for libssl.dylib.

  2. Erik Schnetter
    • removed comment

    I know of no good way to detect this automatically.

    We can look at the output of "uname" to find out whether we are on Mac OS, and we could build a simple object file and then examine it with "file" to find out.

    A short-term work-around is to list ExternalLibraries/OpenSSL in the "disabled-thorns" section of the machine's MDB if you use Simfactory.

  3. Ian Hinder reporter
    • removed comment

    If you're going to do that, you may as well set OPENSSL_DIR = /usr. Is there a way to determine the shared-library extension? So then you could look for libssl.${SHLIBEXT} in the OpenSSL configure script.

    As for detecting if you are on 64 bit, the test you are suggesting is a good idea, and could be part of the Cactus configure process. It could set variables CCTK_64BIT and CCTK_32BIT. I imagine we might need to know this for other things as well.

  4. Erik Schnetter
    • removed comment

    Yes, there is a way to look for different extensions. I remember implementing this for some external library, but I don't remember for which one, and I can't find the code at the moment. It is simple -- another loop for the possible suffixes, and a library counts as found if any suffix is found.

    Yes, we need to know whether we are on a 64 bit system on AIX as well. We have to set special CFLAGS and ARFLAGS there. I believe we grep for '64' in CFLAGS on AIX to find this out.

  5. Ian Hinder reporter
    • removed comment

    There is an autoconf build_cpu macro, which gives the architecture. I suspect that it tells you the architecture that is going to be compiled for, but it's possible that it gives you the capability of the CPU. Another option would be to use a C program which output sizeof(int *) rather than using "file" on the resulting binary, as this would be more portable. In configure.in, there is mention of SIZEOF_POINTER, but I don't know how to propagate that as a make variable to the OpenSSL script. using "export CCTK_POINTER_SIZE=@SIZEOF_POINTER@" in make.config.defn.in didn't work - it doesn't get expanded in make.config.defn. I probably need to assign it explicitly using an autoconf macro, but I don't know how to do that.

  6. Erik Schnetter
    • removed comment

    SIZEOF_POINTER is a configuration variable that the user has to set when cross-compiling, i.e. when Cactus cannot determine the pointer size automatically. We should not use it. We should probably use SIZEOF_CHAR_P, which is set in the call AC_CHECK_SIZEOF(char *, $SIZEOF_POINTER). I assume that autoconf converts "char *" automatically into the string "CHAR_P". AC_CHECK_SIZEOF probably also marks this variable (namely SIZEOF_CHAR_P) as one of the variables that is substituted. It should be expanded in make.config.defn.in.

    If not, then the command to explicitly mark a variable for substitution is AC_SUBST; this is used in many places. The actual substitution happens at the end of configure.in in the call to AC_OUTPUT. cctk_Config.h is probably treated specially; the fact that it should also be autogenerated is probably declared via AC_CONFIG_HEADER in the very beginning.

  7. Ian Hinder reporter
    • removed comment

    It seems that I have to manually set the shell variable, otherwise we get a #define but not a make variable assignment. I have opened ticket #342 with a patch which provides CCTK_POINTER_SIZE in the flesh. I am attaching a patch to OpenSSL.sh which reads this variable, but I have no idea how to choose the architecture in the config process. The patch does not work - it seems there is a darwin-specific patch to the config file in the dist directory which I can't make head nor tail of. Perhaps you can take a look?

  8. Erik Schnetter
    • removed comment

    The existing MacOS patch omits certain compiler flags that are available only with the standard Mac OS X C compiler, but which are not available with other C compilers. These flags are not necessary any more on modern Mac OS X systems.

  9. Ian Hinder reporter
    • removed comment

    So I can remove the patch from the thorn and use the unpatched library?

  10. Erik Schnetter
    • removed comment

    No; since the flags are not supported by the compiler, the patch to remove the flags is necessary. However, if newer versions of OpenSSL build without this patch with a generic (non-Apple-modified) gcc, then the patch can go.

  11. Ian Hinder reporter
    • removed comment

    The attached patch enables autodetection of the dylib extension on Mac OS. OK to apply?

    It seems to me that the autodetection logic is the sort of thing that is usually handled by autoconf or pkg-info, and we probably don't want to reimplement it. The current method has several failings. For example, it does not find shared libraries (.so) and it does not find libraries in lib64. Should we use pkg-info instead?

    $ pkg-config --libs openssl -lssl -lcrypto -lz

    and similarly for --cflags.

  12. Frank Löffler
    • changed status to resolved
    • removed comment

    I agree that using pkg-config would be a better way to go, but for now I've applied this patch.

  13. Log in to comment