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

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.

   • 2011-03-13T18:12:59+00:00
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.

   • 2011-03-13T18:16:11+00:00
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.

   • 2011-03-13T19:32:22+00:00
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.

   • 2011-03-13T20:36:46+00:00
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.

   • 2011-03-14T04:02:37+00:00
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.

   • 2011-03-14T06:58:28+00:00
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?

   • 2011-03-14T11:57:23+00:00
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.

   • 2011-06-21T07:02:26+00:00
9. 

   Ian Hinder reporter

   • changed status to open
   • assigned issue to
   • removed comment

   • 2011-08-16T12:37:43+00:00
10. 

    Ian Hinder reporter

    • removed comment

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

    • 2011-08-24T14:03:18+00:00
11. 

    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.

    • 2011-08-24T19:32:09+00:00
12. 

    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.

    • 2011-08-27T07:01:20+00:00
13. 

    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.

    • 2012-04-23T11:17:11+00:00
14. 

    Roland Haas

    • edited description
    • changed status to closed

    • 2019-02-21T20:24:39+00:00
15. Log in to comment