Bug 221022

Summary: Please build netcdf as a shared library
Product: [Fedora] Fedora Reporter: Julian Sikorski <belegdol>
Component: netcdfAssignee: Ed Hill <ed>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: 6   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-12-30 15:00:28 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Julian Sikorski 2006-12-30 12:23:55 UTC
Description of problem:
I am working on wrapping up a LabPlot package. It depends on a few dozens of
libraries, and netcdf is among these. The problem is that configure does not
detect system-wide netcdf (and tries to use local one) because ld can't find
-lnetcdf. I'm not sure if my request can be fulfilled easily, but I have noticed
that if you build LabPlot with local netcdf shared libLabPlotnetCDF.so.* files
get created.

Comment 1 Ed Hill 2006-12-30 14:05:49 UTC
Hi Julian, I know nothing about LabPlot but I can say that:

 1) The next version of netCDF (due in ~2 months) will have full support
    for shared libs and I intend to upgrade the Fedora Extras version 
    to it shortly after its released (that is, out of beta).

 2) The current netCDF builds static libraries but it builds them as
    position-independent code (-fPIC) so the objects can be used within 
    the shared libraries of dependent software.  For an example, see
    the NCO package which does exactly that--it builds its own shared 
    libs using the netCDF static libs.

 3) Based on your description I think your LabPlot problem can be resolved
    by adding:

       export CPPFLAGS="-I/usr/include/netcdf-3"
       export LDFLAGS="-L/usr/lib/netcdf-3"

    to your environment before the "./configure ..." step.

If (3) doesn't fix things then I can probably help you fix whatever 
configure-and-build system is used by LabPlot.

If (3) does fix it then please respond and I'll close this bug.

Comment 2 Julian Sikorski 2006-12-30 14:52:32 UTC
Thanks for the info, problem solved.