OpenSSL doesn't patch with +universal variant

[frew@…]

With the current version, OpenSSL fails to apply the patch-Makefiles-universal-* patches. Although I haven't actually seen the old version, it appears that the configuration script now adds the -arch (i386|ppc) flags without the need for a patch. I will attach patches (rooted on the directory with the Portfile) to correct the patches so that they apply correctly. lipo -info on the resulting library states that it has both platforms.

Let me know if I can be of any additional help.

[frew@…]

Patch for patch-Makefiles-universal-i386

[frew@…]

Patch for patch-Makefiles-universal-ppc

[ryandesign (Ryan Carsten Schmidt)]

The error encountered with the current portfile is:

$ sudo port upgrade
--->  Fetching openssl
--->  Verifying checksum(s) for openssl
--->  Extracting openssl
--->  Applying patches to openssl
--->  Configuring openssl
Error: Target org.macports.configure returned: shell command "patch < /Users/rschmidt/macports/dports/devel/openssl/files/patch-Makefiles-universal-i386" returned error 1
Command output: patching file Makefile
Hunk #1 FAILED at 60.
Hunk #2 FAILED at 142.
2 out of 2 hunks FAILED -- saving rejects to file Makefile.rej
patching file Makefile.shared

Error: Unable to upgrade port: 1
$

[mww@…]

With the patches this (still) fails for me (on i386) with:

make -f ../Makefile.shared -e \
        APPNAME=openssl OBJECTS="openssl.o verify.o asn1pars.o req.o dgst.o dh.o dhparam.o enc.o passwd.o gendh.o errstr.o ca.o pkcs7.o crl2p7.o crl.o rsa.o rsautl.o dsa.o dsaparam.o ec.o ecparam.o x509.o genrsa.o gendsa.o s_server.o s_client.o speed.o s_time.o apps.o s_cb.o s_socket.o app_rand.o version.o sess_id.o ciphers.o nseq.o pkcs12.o pkcs8.o spkac.o smime.o rand.o engine.o ocsp.o prime.o" \
        LIBDEPS="-Wl,-search_paths_first $LIBRARIES -L/opt/local/lib  -lz" \
        link_app.${shlib_target}
( :; LIBDEPS="${LIBDEPS:--Wl,-search_paths_first -L.. -lssl  -L.. -lcrypto -L/opt/local/lib  -lz}"; LDCMD="${LDCMD:-cc}"; LDFLAGS="${LDFLAGS:--fPIC -fno-common -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -arch ppc -O3 -DB_ENDIAN}"; LIBPATH=`for x in $LIBDEPS; do if echo $x | grep '^ *-L' > /dev/null 2>&1; then echo $x | sed -e 's/^ *-L//'; fi; done | uniq`; LIBPATH=`echo $LIBPATH | sed -e 's/ /:/g'`; LD_LIBRARY_PATH=$LIBPATH:$LD_LIBRARY_PATH ${LDCMD} ${LDFLAGS} -o ${APPNAME:=openssl} openssl.o verify.o asn1pars.o req.o dgst.o dh.o dhparam.o enc.o passwd.o gendh.o errstr.o ca.o pkcs7.o crl2p7.o crl.o rsa.o rsautl.o dsa.o dsaparam.o ec.o ecparam.o x509.o genrsa.o gendsa.o s_server.o s_client.o speed.o s_time.o apps.o s_cb.o s_socket.o app_rand.o version.o sess_id.o ciphers.o nseq.o pkcs12.o pkcs8.o spkac.o smime.o rand.o engine.o ocsp.o prime.o ${LIBDEPS} )
/usr/bin/ld: warning /opt/local/lib/libz.dylib cputype (7, architecture i386) does not match cputype (18) for specified -arch flag: ppc (file not loaded)
/usr/bin/ld: warning prebinding disabled because of undefined symbols
/usr/bin/ld: Undefined symbols:
_deflate
_deflateEnd
_deflateInit_
_inflate
_inflateEnd
_inflateInit_

[mww@…]

I've fixed this w/o the architecture specific patches - works fine for me on 10.5.1/i386

[rasmus@…]

Doesn't this force -arch ppc for all universal builds even if ppc isn't one of the targets? At least that is what I am seeing. My universal targets are i386 and x86_64 and it is attempting to build a ppc version for me which obviously doesn't work since the dependencies don't have that architecture.

[mww@…]

Replying to rasmus@lerdorf.com:

Doesn't this force -arch ppc for all universal builds even if ppc isn't one of the targets? At least that is what I am seeing. My universal targets are i386 and x86_64 and it is attempting to build a ppc version for me which obviously doesn't work since the dependencies don't have that architecture.

yes it does, but port(1) doesn't feature configurability which architectures to build nor a way to read this option;

[rasmus@…]

Replying to mww@macports.org:

yes it does, but port(1) doesn't feature configurability which architectures to build nor a way to read this option;

Yet, you mean? I thought the plan was to move towards a user-configurable set of architectures. Or is the plan to go to all 4 and not let the user tweak it? Also, as I am sure you are aware, the Portfile has:

foreach arch {i386 ppc} {

system "cd ${workpath}/${arch} && ./Configure darwin-${arch}-cc ${configure.pre_args} ${configure.args}"

}

Looking at the commented out foreach loops in that file that contain all 4 architectures, it sort of suggests that you might be able to add x86_64 to the ./Configure loop which of course won't work because that creates darwin-x86_64-cc and the build will fail since it should be darwin64-x86_64-cc

Even if people figure that out, they get bitten by the fact that openssl spits out different versions of /opt/local/include/openssl/opensslconf.h between the 32 and 64-bit builds. The differences being:

@@ -130,3 +130,3 @@

#ifndef DES_LONG

-#define DES_LONG unsigned long +#define DES_LONG unsigned int

#endif

@@ -136,3 +136,3 @@

#define CONFIG_HEADER_BN_H

-#define BN_LLONG +#undef BN_LLONG @@ -144,5 +144,5 @@

• for debuging the bignum libraries */

-#undef SIXTY_FOUR_BIT_LONG +#define SIXTY_FOUR_BIT_LONG

#undef SIXTY_FOUR_BIT

-#define THIRTY_TWO_BIT +#undef THIRTY_TWO_BIT

#undef SIXTEEN_BIT

@@ -160,3 +160,3 @@

#define CONFIG_HEADER_BF_LOCL_H

-#define BF_PTR +#define BF_PTR2

#endif /* HEADER_BF_LOCL_H */

Is there a plan for stuff like that? Like an include64 directory or something?

[ryandesign (Ryan Carsten Schmidt)]

All this is in very early stages of thinking. The openssl port was only just rewritten for more sane universal binary building. The commented-out list of 4 architectures is a reminder from the port author to himself that support for all 4 architectures still needs to be considered. I have already pointed out that we do not want the list of architectures hardcoded into each port. Therefore the variable configure.universal_archs is now available in base. However that version of MacPorts has not yet been released so the portfile cannot be updated to use that variable. Also, there is not yet a mechanism for users to configure what they want in that variable. I'm not yet convinced we should allow users to configure this.

All of this discussion is inappropriate in this ticket. This ticket was filed becauset he universal variant of openssl did not work. It was fixed so that it now works and the ticket was closed. All subsequent discussion is an unrelated issue. Since there's not yet consensus what needs to be done, if anything, this discussion should be taking place on the macports-devel mailing list. Please subscribe and open the discussion there.

[ryandesign (Ryan Carsten Schmidt)]

I meant to add: to the point of differing headers: the merge_cpp() function in base in trunk includes a comment that support for different headers is still a to-do item. A possible solution is suggested there. See r31954.

[(none)]

Milestone Port Bugs deleted