Configure is failing on Sparc Solaris 9 platform using gcc 3.3. It fails for both the ssl header and library version. I have taken the configure code for the header version and compiled it this way: gcc -o junk1 -I/usr/local/ssl/include junk1.c junk1.c being the file I copied the configure code into. I have not been able to do the same for the library version code. I have tried the following: gcc -o junk2 -I/usr/local/ssl/include -L/usr/local/ssl/lib -L/usr/local/lib -R/usr/local/lib -lcrypto -lsocket -lnsl -ldl junk2.c Undefined first referenced symbol in file SSLeay /var/tmp//ccq9LJmh.o SSLeay_version /var/tmp//ccq9LJmh.o ld: fatal: Symbol referencing errors. No output written to junk2 collect2: ld returned 1 exit status Running nm on libcrypto.a shows these two global symbols.
That sounds like a compiler or openssl installation problem. Can you recompile openssl? I have just successfully configured openssh on Solaris 8 with gcc-3.3 here, which gave me: Linker flags: -L/usr/local/ssl/lib -R/usr/local/ssl/lib -L/usr/local/lib -R/usr/local/lib Libraries: -lrt -lz -lsocket -lnsl -lcrypto
Well this almost works: gcc -o junk2 -I/usr/local/ssl/include -L/usr/local/ssl/lib -L/usr/local/lib -R/usr/local/lib junk2.c -lrt -lz -lsocket -lnsl -lcrypto It still fails with an unresolved reference to libgcc_s.so.1. This is a new platform being build from the ground up so I suspect a tool issue here. Note the suttle parameter order change of moving the source file a head of the library flags. I hope this does not indicate a reverting to where building software was a fragile task of determining what order you needed to things on the command line. Bottom line, not a bug. Still need to figure out why the C library is not being found when the code is linked with a -R flag. This is why shared libraries are really a failed academic concept.
Mass change of RESOLVED bugs to CLOSED