Closed danmcd closed 2 months ago
One illumos-core member suggests I fix libcurl's location.
IMO we better keep $(MACH64) as long as we need to keep 32-bit libs...
If you look, MACH64 is only defined per-package in -extra:
smartos-build-2(projects/illumos-extra)[0]% git grep MACH64
libexpat/Makefile: DESTDIR=$(DESTDIR) VERS=$(VER.64) MACH64=amd64 \
libz/Makefile: BASE=$(BASE) DESTDIR=$(DESTDIR) VERS=$(VER.64) MACH64=amd64 \
libz/install-zlib-64:ROOTLIBDIR=${DESTDIR}/lib/${MACH64} # passed in by make $(MACH64)
libz/install-zlib-64:LIBDIR=${PREFIX}/lib/${MACH64}
libz/install-zlib-64:_install L ../../../lib/${MACH64}/libz.so.1 ${LIBDIR}/libz.so.1
nss-nspr/Makefile: DESTDIR=$(DESTDIR) MACH64=amd64 ksh93 ./install-nss-64 $(VER.64)
openssl1x/install-sfw-64:LIBDIR=${DESTDIR}/lib/amd64 # MACH64 passed in by makefile
openssl3/install-sfw-64:LIBDIR=${DESTDIR}/lib/amd64 # MACH64 passed in by makefile
smartos-build-2(projects/illumos-extra)[0]%
The openssl ones have their comment as a future reminder.
As with OpenSSL, nothing 3rd-party should be linking against libcurl, and we don't supply the headers in any way that would make doing so easy.
The only thing that might reasonably link against it would be a binary compiled on another illumos that someone copied onto SmartOS. I'm not sure if we should consider that supported or not.
As with OpenSSL, nothing 3rd-party should be linking against libcurl, and we don't supply the headers in any way that would make doing so easy.
Correct!
The only thing that might reasonably link against it would be a binary compiled on another illumos that someone copied onto SmartOS. I'm not sure if we should consider that supported or not.
Definitely unsupported... we don't ship headers AND WE DO NOT SHIP the
As of this moment, curl is being built 64-bit but also
/usr/lib/libcurl.so...
itself is 64-bit, which while allowable (esp. for a library we aren't providing with interfaces) violates the spirit of placing this 64-bit library in /usr/lib/amd64/. I'm not sure how I feel about that.