Archived
This forum has been archived. Please start a new discussion on GitHub.
Ice doesn't build correctly when OpenSSL is in /usr/local/ssl
Ahoy hoy,
Ice doesn't build properly when OpenSSL is installed in an unexpected location, like /usr/local/ssl. This is the default installation directory for both 0.9.6i and 0.9.7.
The problem is that not all of the Makefiles put OPENSSL_FLAGS into the CPPFLAGS variable, and so whatever setting I gave in Make.rules has no effect.
The offending Makefiles are:
src/Glacier/Makefile
src/IcePatch/Makefile
test/IceSSL/certificateAndKeyParsing/Makefile
test/IceSSL/certificateVerifier/Makefile
test/IceSSL/certificateVerification/Makefile
After I added OPENSSL_FLAGS to these files in the right place, everything was OK.
The file "src/IceSSL/Makefile" is an example of a correct CPPFLAGS setting. That one works fine as it is.
Again, this is SuSE 8.0, Pentium, GCC 3.2.1 and OpenSSL 0.9.6i
Regards,
Derek.
PS I am not a crackpot.
Ice doesn't build properly when OpenSSL is installed in an unexpected location, like /usr/local/ssl. This is the default installation directory for both 0.9.6i and 0.9.7.
The problem is that not all of the Makefiles put OPENSSL_FLAGS into the CPPFLAGS variable, and so whatever setting I gave in Make.rules has no effect.
The offending Makefiles are:
src/Glacier/Makefile
src/IcePatch/Makefile
test/IceSSL/certificateAndKeyParsing/Makefile
test/IceSSL/certificateVerifier/Makefile
test/IceSSL/certificateVerification/Makefile
After I added OPENSSL_FLAGS to these files in the right place, everything was OK.
The file "src/IceSSL/Makefile" is an example of a correct CPPFLAGS setting. That one works fine as it is.
Again, this is SuSE 8.0, Pentium, GCC 3.2.1 and OpenSSL 0.9.6i
Regards,
Derek.
PS I am not a crackpot.
0
Comments
-
Thanks for the feedback. Without a user community reporting these things to us, we would never find out. Our machines are simply too contaminated with our development environment :-)0
-
Originally posted by marc
Thanks for the feedback. Without a user community reporting these things to us, we would never find out. Our machines are simply too contaminated with our development environment :-)
Happy to help!
As for "clean" release testing, it' a nuisance unless you are prepared to dedicate a machine to testing, and format the drive each time to be sure of a fresh environment. If you are interested in pursuing that route, I'd recommend you have a look a vmware. You can actually run a virtual machine's file system on top of your existing file system - it just appears as a file on the host file sytem (I think, maybe it's a directory).
I used it to run many "installs" of Windows at once on a Linux box. When a Windows file system went AWOL or the registry got mangled or whatever, I'd just delete *that* file system and move on to another. I could be braver with my experimentations, as I could create file systems just for high-risk mucking around. You could probably check them into CVS if you wanted to track your changes to a system.
You can also, of course, run Linux in a virtual machine, too. I'd give it a try if you want to simulate lots of different "clean" machines without having to go out and buy them!0