Bug 228131 - no shared library provided.
no shared library provided.
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: netcdf (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ed Hill
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-02-09 22:42 EST by Balint Cristian
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-02-10 00:32:48 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Balint Cristian 2007-02-09 22:42:57 EST
Description of problem:
No shared libraries provided.

Version-Release number of selected component (if applicable):
3.6.1

How reproducible:
-

Steps to Reproduce:
1. -
 
 
Actual results:
-

Expected results:
-

Additional info:
 Please update to beta version of 3.6.2, it now has shared library generation 
enabled mainstream according to a mail from author on the mailinglist.
 This is a blocker issue for get gdal library into -extras.
  If dont want to include beta, at least fix generation of shared library.
Comment 1 Ed Hill 2007-02-09 23:19:57 EST
Hi Balint, its possible that I'm missing something here but I doubt it.
  
Before I take any action on this bug I want you to please explain why 
the current netcdf in Fedora Extras blocks the generation of shared 
libs in gdal.  And before you attempt to answer that question, please 
take a very close look at both the nco package and netcdf itself.  
Notice that all the netcdf object code (both the Fortran and C bits) 
are position independent (built with "-fPIC").  As a result, the nco 
package is (readily!) able to build and use shared libraries that 
depend upon the netcdf libs.

So, recognizing the above circumstances, why is it that nco is able 
to build and use shared libs that depend upon netcdf but gdal cannot?
Comment 2 Balint Cristian 2007-02-09 23:57:06 EST
gdal complain about :-)
/usr/bin/ld: cannot find -lnetcdf
and that flag is from the source code, i didnt add it.

  Well, we can live probably with hooks over gdal, but it would be nice
to have netcdf enhanced, why not ? 


/cristian


Comment 3 Ed Hill 2007-02-10 00:32:48 EST
Hi Cristian, I see from the latest SRPM in bz 222042 that all you 
had to do to enable netcdf in gdal was to add:

  export LDFLAGS='-L%{_libdir}/netcdf-3'
  export CPPFLAGS=$CPPFLAGS' -I%{_includedir}/netcdf-3'

to the gdal spec file.  That's good news.  I'm closing this as 
NOTABUG but please feel free to re-open it or to open a new one 
if you encounter an actual netcdf problem.

And, yes, I do intend to update the netcdf package in Fedora to 
3.6.2 when it is no longer a "beta" release.
Comment 4 Balint Cristian 2007-02-10 03:09:27 EST
 That hook what you saw isnt enough, need to cut out -lnetcdf from source, but 
anyway, i still sustain necdf doesnt ship a sane enviroment.
 Maybe to ship shared libs along their soname shoud be a *MUST* and than 
people will start realize ?!


But anyway, nevermind.



Note You need to log in before you can comment on or make changes to this bug.