> 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
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.