So, if you specify ./configure --with-ossl-root=/usr/local/ssl it should look for the .h in /usr/local/ssl/include/openssl and the .a .so in /usr/local/ssl/lib
which should work just fine... -----Burton -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Falk Hayn Sent: Thursday, February 27, 2003 11:01 AM To: [EMAIL PROTECTED] Subject: [Ntop-dev] ntop / openSSL 0.9.7: well defined directory structure Burton, my 1st try to build had the libs in /usr/local/src/openssl/openssl-0.9.7/ssl/lib /usr/local/ssl/lib /usr/local/ssl/lib/libcrypto.a /usr/local/ssl/lib/libssl.a /usr/local/ssl/lib/pkgconfig /usr/local/ssl/lib/pkgconfig/openssl.pc and the headers /usr/local/ssl/include /usr/local/ssl/include/openssl /usr/local/ssl/include/openssl/aes.h /usr/local/ssl/include/openssl/asn1.h /usr/local/ssl/include/openssl/asn1_mac.h /usr/local/ssl/include/openssl/asn1t.h /usr/local/ssl/include/openssl/bio.h ---snip---- These were the package defaults. To move away from this, im still doing a 2nd build of openssl 0.9.7a issuing the follwoing options: ./config shared no-asm --prefix=/usr/local > config.results 2>&1 make > make.results 2>&1 make test > make.test.results 2>&1 make install > make.install.results 2>&1 We will see what the outcome is. Do You agree with this options ? After the build and install completed, I will keep You posted. > Ok, but where does it put the lib? It's not the root that's causing > problems, it's the middle part. > > --with-ossl-root=/usr/local/ssl would be a valid prefix if the .hs are in > .../include/openssl and the .so in .../lib > > > > "You define the openssl build options in a clear fashion, so the user > built > matches Your expectations." is cr*p. > > According to the INSTALL file distributed w/ 0.9.7a, the parameters are: > > --prefix=DIR Install in DIR/bin, DIR/lib, DIR/include/openssl. > Configuration files used by OpenSSL will be in DIR/ssl > or the directory specified by --openssldir. > > --openssldir=DIR Directory for OpenSSL files. If no prefix is specified, > the library files and binaries are also installed there. > > That's what ntop's configure IS ALREADY tuned for. > > Look, the dang thing is supposed to be a system library. So it's SUPPOSED > to be available via a standard gcc compile/link. > > gcc -lssl file.c > > That's it. That's all I have to do for a libpcap test program or > whatever. > If you set --prefix=/usr or --prefix=/usr/local it works. The > --openssldir > is for the configuration files, which ntop doesn't give a rat's furry > behind > about. > > It's only openSSL under some stupid OS/packagers that installs itself in > fried locations and expects the compile line to jump through hoops. > Handling this stuff is already 6% of the TOTAL lines in configure.in -- > how > many more stupid places do we have to look? Splitting the option would > DOUBLE or TRIPLE the # of lines (I'd have to add --with-ossl-libroot and > maybe a --with-ossl-hroot). > > If you don't tell us a specific place to look, we already check -- BEYOND > the usual AC_CHECK_HEADER() and AC_CHECK_LIB tests that should find it > routinely: > > /usr/include > /usr/include/openssl > /usr/include/ssl > /usr/local/include > /usr/local/include/openssl > /usr/local/include/ssl > > /usr/lib/libssl.so || /usr/lib/libssl.a > /usr/local/lib/libssl.so || /usr/local/lib/libssl.a > /usr/lib64/libssl.so || /usr/lib64/libssl.a > > If you DO tell us where to look, we check, based off --with-ossl-root > value: > > ./include > ./include/openssl > ./include/ssl > > and .so || .a in: > > . > ./lib > ./lib/openssl > > > WHY ISN'T THAT ENOUGH???? > > > -----Burton _______________________________________________ Ntop-dev mailing list [EMAIL PROTECTED] http://listgateway.unipi.it/mailman/listinfo/ntop-dev
