[netCDF #BVL-677462]: Binaries define rpath on x86_64

> On 09/23/2011 06:07 AM, Unidata netCDF Support wrote:
> >> On 04/19/2011 04:59 PM, Unidata netCDF Support wrote:
> >>>> I think this may be caused by an out of date libtool.  Anyways, the 
> >>>> binaries
> >>>> don't need to define an rpath of /usr/lib64 because that is the standard 
> >>>> path.
> >>>>
> >>>> netcdf.x86_64: E: binary-or-shlib-defines-rpath /usr/bin/nccopy 
> >>>> ['/usr/lib64']
> >>>> netcdf.x86_64: E: binary-or-shlib-defines-rpath /usr/bin/ncgen 
> >>>> ['/usr/lib64']
> >>>> netcdf.x86_64: E: binary-or-shlib-defines-rpath /usr/bin/ncdump 
> >>>> ['/usr/lib64']
> >>>> netcdf.x86_64: E: binary-or-shlib-defines-rpath /usr/bin/ncgen3 
> >>>> ['/usr/lib64']
> >>>>
> >>>> --
> >>>> Orion Poplawski
> >>>> Technical Manager                     303-415-9701 x222
> >>>> NWRA/CoRA Division                    FAX: 303-415-9702
> >>>> 3380 Mitchell Lane                  address@hidden
> >>>> Boulder, CO 80301              http://www.cora.nwra.com
> >>>>
> >>>>
> >>>
> >>> Howdy Orion!
> >>>
> >>> I am taking another pass at the configure.ac and Makefile.am files to 
> >>> simplify, standardize, and cut out the clutter. The idea is to make it 
> >>> easier to maintain, support, and also to have it seemlessly build and 
> >>> test windows DLL on my linux box. I will be checking in some changes to 
> >>> the main trunk, and they will start showing up in the main snapshot 
> >>> release later this week.
> >>>
> >>> I will make sure that I have the latest libtool before doing that...
> >>>
> >>> Thanks,
> >>>
> >>> Ed
> >>>
> >>> Ticket Details
> >>> ===================
> >>> Ticket ID: BVL-677462
> >>> Department: Support netCDF
> >>> Priority: Emergency
> >>> Status: Closed
> >>
> >> Ed -
> >>
> >> FYI - I'm still seeing this in last night's snapshot.
> >>
> >>
> >> --
> >> Orion Poplawski
> >> Technical Manager                     303-415-9701 x222
> >> NWRA/CoRA Division                    FAX: 303-415-9702
> >> 3380 Mitchell Lane                  address@hidden
> >> Boulder, CO 80301              http://www.cora.nwra.com
> >>
> >>
> >
> > Howdy Orion!
> >
> > Is this still happening for you? I am using libtool 2.4, which seems to be 
> > the latest version...
> >
> > Ed
> >
> > Ticket Details
> > ===================
> > Ticket ID: BVL-677462
> > Department: Support netCDF
> > Priority: Critical
> > Status: Closed
> 
> It is still happening.  I see in liblib/Makefile.in:
> 
> libnetcdf.la: $(libnetcdf_la_OBJECTS) $(libnetcdf_la_DEPENDENCIES)
> 
> $(libnetcdf_la_LINK) -rpath $(libdir) $(libnetcdf_la_OBJECTS)
> $(libnetcdf_la_LIBADD) $(LIBS)
> 
> but I have no idea where the rpath is coming in from.
> 
> Anyways, it appears that perhaps I was giving libtool more credit than it
> deserves and there is a way I can remove the rpath from my builds, so I guess
> I wouldn't worry about it too much.
> 
> Another issues I just noticed - a number of source files have execute
> permission in the netcdf-4.2-daily tarball.
> 
> --
> Orion Poplawski
> Technical Manager                     303-415-9701 x222
> NWRA/CoRA Division                    FAX: 303-415-9702
> 3380 Mitchell Lane                  address@hidden
> Boulder, CO 80301              http://www.cora.nwra.com
> 
> 

Don't know what is going on with executable code files, but I have noted it as 
a bug to fix:
https://www.unidata.ucar.edu/jira/browse/NCF-128

If you figure out what is happening with the rpath problem, please do let me 
know. The liblib/Makefile.am is the one that assembles all the convenience 
libraries into the final library. If there's a problem, that's where it will 
be...

Thanks!

Ed

Ticket Details
===================
Ticket ID: BVL-677462
Department: Support netCDF
Priority: Critical
Status: Closed