[fdo-internals] FDO Thirdparty Dependencies

[Greg Boone]

OK... it looks as if there is a conflict between the version we build locally and the version installed. The installed version is also being linked in to libOWS.

I could change the build to use the installed version.... I know this would make many people happy. 


===================================================================
--- Makefile.am (revision 5807)
+++ Makefile.am (working copy)
@@ -68,9 +68,10 @@
   $(FDOUTILITIES)/Common/libProvidersCommon.la \
   $(FDOTHIRDPARTY)/boost/stage/lib/libboost_thread.a \
   $(FDOTHIRDPARTY)/libcurl/lib/linux/libcurl.a  \
-  $(FDOTHIRDPARTY)/openssl/lib/linux/libssl.a \
-  $(FDOTHIRDPARTY)/openssl/lib/linux/libcrypto.a \
   -lz \
+  -lrt \
+  -lssl \
+  -lcrypto \
   -lpthread



-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Greg Boone
Sent: Friday, November 12, 2010 3:05 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] FDO Thirdparty Dependencies

Hmm..

I might have this wrong. I believe we build our own version of libcrypto.a and link to that, 

libFdoOws_la_LIBADD =  \
  Src/libFdoOwsSrc.la \
  $(FDO)/Unmanaged/Src/libFDO.la \
  $(FDO)/Unmanaged/Src/Geometry/libFDOGeometry.la  \
  $(FDO)/Unmanaged/Src/Common/libFDOCommon.la  \
  $(FDOUTILITIES)/Common/libProvidersCommon.la \
  $(FDOTHIRDPARTY)/boost/stage/lib/libboost_thread-mt.a \
  $(FDOTHIRDPARTY)/libcurl/lib/linux/libcurl.a  \
  $(FDOTHIRDPARTY)/openssl/lib/linux/libssl.a \
  $(FDOTHIRDPARTY)/openssl/lib/linux/libcrypto.a \
  -lz \
  -lpthread

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Greg Boone
Sent: Friday, November 12, 2010 2:47 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] FDO Thirdparty Dependencies

Another CURL issue. We don't disable crypto support in CURL (using --disable-crypto-auth). Thus the -lcrypto option is used in building the CURL library.  

We are now seeing:

undefined symbol: CRYPTO_cfb128_8_encrypt       (/home/fdouser/fdo36bin/lib/libFdoOws-3.6.0.so)
undefined symbol: CRYPTO_cfb128_1_encrypt       (/home/fdouser/fdo36bin/lib/libFdoOws-3.6.0.so)
undefined symbol: CRYPTO_cfb128_encrypt (/home/fdouser/fdo36bin/lib/libFdoOws-3.6.0.so)
undefined symbol: CRYPTO_ofb128_encrypt (/home/fdouser/fdo36bin/lib/libFdoOws-3.6.0.so)
undefined symbol: CRYPTO_cbc128_encrypt (/home/fdouser/fdo36bin/lib/libFdoOws-3.6.0.so)
undefined symbol: CRYPTO_cbc128_decrypt (/home/fdouser/fdo36bin/lib/libFdoOws-3.6.0.so)


Do we need to provide cryptographic authorization support for WMS/WFS? If so, do we provide guidance on installing libcrypto?

Greg


-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Frank Warmerdam (External)
Sent: Friday, November 12, 2010 12:41 PM
To: FDO Internals Mail List
Subject: Re: [fdo-internals] FDO Thirdparty Dependencies

Greg Boone wrote:
> Hi All,
> 
>  
> 
> I am getting some feedback that the 3.6.0 versions of the third-party 
> libraries we build on Linux have certain dependencies that may be 
> unnecessary. These dependencies now require clients to install 
> additional components to allow the providers to successfully install and 
> run.
> 
> CURL: Builds with LDAP support
> 
> GDAL: Builds with ODBC support
> 
> I wanted to poll the developers to determine if we needed to maintain 
> the dependencies, or alter the build settings to remove them.
> 
> CURL is an easier question since it involves a static library rather 
> than a dynamic library.
> 
> For GDAL we build the dynamic library and include it in the FDO 
> distribution.

Greg,

I will note that IMHO ODBC support in GDAL/OGR is of relatively low
value on linux - partcularly because the linux odbc mdb driver is so
weak that use of it almost always fails to work properly.  I would
suggest dropping ODBC support from "standard" linux builds.

I'm not sure what else curl is used for, but it is useful for GDAL
and to the extent you can control how it is built I would suggest
removing complications like LDAP.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent

_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals
_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals
_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals