I am working on updating the port for HPE NonStop Itanium and x86 (Big Endian) platforms. I would like to contribute the changes, once working, to the main repository for inclusion into the code base. For reference, I have been maintaining the openssh-portable port for both platforms through 7.6p1 using OpenSSL 1.0.2. The port for OpenSSL 1.1.1 was just completed and this has enabled me to bring the port up to date. There are a few changes needed based on configure not handling some situations but mostly the key difference is that ROOT is 65535 not 0 on this platform. The compiler we have to use is c99 but can upgrade to c11 or higher in about 3 years when the Itanium platform is deprecated. The team I work on is called ITUGLIB and maintain many of the critical Open Source ports for the platform. Is this contribution desired?
Our general policy is that we'll support something as long as someone is willing to do the work, and that the changes involved don't compromise support for modern platforms. It sounds like you're willing to do the work, so the other question is how invasive the required changes are. Can you share the existing port or the diff against the stock code of the same vintage? It doesn't have to be polished, I just want to get a sense for what's involved. > x86 (Big Endian) I didn't know that was even possible. > The compiler we have to use is c99 right now all of the code (with the exception of some of the experimental post-quantum stuff not compiled by default) is c89 for maximum portability so c99 is fine.
We went to c99 because some of the constructs in the regression suite do not compile with c89. I don't mind going back to c89 but there will be a larger set of changes. I'll share a patch listing here once I get this compiling correctly. Note: the Big-Endian part has worked since 6.x - does not seem to take any specific mods to get that working.
One thing that has me confused: cc -c99 -I. -I. -I/usr/local-ssl1.1/include -Wnowarn=262,1252 -I/usr/local-ssl1.1/include -DSSHDIR=\"/usr/local-ssl1.1/etc\" -D_PATH_SSH_PROGRAM=\"/usr/local-ssl1.1/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/local-ssl1.1/libexec/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/usr/local-ssl1.1/libexec/sftp-server\" -D_PATH_SSH_KEY_SIGN=\"/usr/local-ssl1.1/libexec/ssh-keysign\" -D_PATH_SSH_PKCS11_HELPER=\"/usr/local-ssl1.1/libexec/ssh-pkcs11-helper\" -D_PATH_SSH_SK_HELPER=\"/usr/local-ssl1.1/libexec/ssh-sk-helper\" -D_PATH_SSH_PIDDIR=\"/var/run\" -D_PATH_PRIVSEP_CHROOT_DIR=\"/var/empty\" -DHAVE_CONFIG_H -fPIC -shared -o regress/misc/sk-dummy/sk-dummy.so regress/misc/sk-dummy/sk-dummy.lo regress/misc/sk-dummy/fatal.lo ed25519.lo hash.lo ge25519.lo fe25519.lo sc25519.lo verify.lo \ -L. -Lopenbsd-compat -lopenbsd-compat -L. -Lopenbsd-compat/ -L/usr/local-ssl1.1/lib -L/usr/local-ssl1.1/lib -lcrypto -lz c99: error: Invalid input file extension"regress/misc/sk-dummy/sk-dummy.lo". c99: error: Invalid input file extension"regress/misc/sk-dummy/fatal.lo". c99: error: Invalid input file extension"ed25519.lo". c99: error: Invalid input file extension"hash.lo". c99: error: Invalid input file extension"ge25519.lo". c99: error: Invalid input file extension"fe25519.lo". c99: error: Invalid input file extension"sc25519.lo". c99: error: Invalid input file extension"verify.lo". I'm not sure how to fix this in your build structure.
Created attachment 3443 [details] Git diff for patches associated with the NonStop port
(In reply to Randall S. Becker from comment #3) > One thing that has me confused: > > cc -c99 -I. -I. -I/usr/local-ssl1.1/include -Wnowarn=262,1252 > -I/usr/local-ssl1.1/include -DSSHDIR=\"/usr/local-ssl1.1/etc\" > -D_PATH_SSH_PROGRAM=\"/usr/local-ssl1.1/bin/ssh\" > -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/local-ssl1.1/libexec/ssh- > askpass\" > -D_PATH_SFTP_SERVER=\"/usr/local-ssl1.1/libexec/sftp-server\" > -D_PATH_SSH_KEY_SIGN=\"/usr/local-ssl1.1/libexec/ssh-keysign\" > -D_PATH_SSH_PKCS11_HELPER=\"/usr/local-ssl1.1/libexec/ssh-pkcs11- > helper\" > -D_PATH_SSH_SK_HELPER=\"/usr/local-ssl1.1/libexec/ssh-sk-helper\" > -D_PATH_SSH_PIDDIR=\"/var/run\" > -D_PATH_PRIVSEP_CHROOT_DIR=\"/var/empty\" -DHAVE_CONFIG_H -fPIC > -shared -o regress/misc/sk-dummy/sk-dummy.so > regress/misc/sk-dummy/sk-dummy.lo regress/misc/sk-dummy/fatal.lo > ed25519.lo hash.lo ge25519.lo fe25519.lo sc25519.lo verify.lo \ > -L. -Lopenbsd-compat -lopenbsd-compat -L. -Lopenbsd-compat/ > -L/usr/local-ssl1.1/lib -L/usr/local-ssl1.1/lib -lcrypto -lz > c99: error: Invalid input file > extension"regress/misc/sk-dummy/sk-dummy.lo". > c99: error: Invalid input file > extension"regress/misc/sk-dummy/fatal.lo". > c99: error: Invalid input file extension"ed25519.lo". > c99: error: Invalid input file extension"hash.lo". > c99: error: Invalid input file extension"ge25519.lo". > c99: error: Invalid input file extension"fe25519.lo". > c99: error: Invalid input file extension"sc25519.lo". > c99: error: Invalid input file extension"verify.lo". > > I'm not sure how to fix this in your build structure. these .lo files are identical to their .o counterparts except they were compiled with -fPIC for linkage into a shared object (.so) for use by dlopen(3). If your system is not going to use client-side FIDO security key support, then it's fine to simply skip this (--disable-security-key at configure time, though possibly we need some makefile surgery too)
(In reply to Damien Miller from comment #5) [...] > these .lo files are identical to their .o counterparts except they > were compiled with -fPIC for linkage into a shared object (.so) for > use by dlopen(3). There's a similar problem with AIX, which has an, err, interesting linker. The traditional solution to this is libtool, but that AFAICT that'd require overhauling the entire build system.
AFAIK (and have tested) c89,c99 do not support .lo files on input. This is a gcc extension for -fPIC files. For c89, -fPIC still generates .o files and accepts PIC .o files on input when building .so DLLs.