Hello,
it is good news the activemq-cpp is already in EPEL6. There is so far a
local copy of activemq in EMI project. We need to update it there, so we
could try to get activemq-cpp into EPEL5 instead. :-)
I think the rpmlint error is just the false alarm, primary goal is to
check rpath in the libraries. Original apr package in Fedora has this
error too. Actually it looks like it is a minor bug in apr-util - it
depends on flags from apr to build its own library libaprutil.la, the
-rpath option is needed for the libtool.
There are my packages for SL5 using the latest apr and apr-utils from
Fedora 18:
http://scientific.zcu.cz/repos/activemq/
(based on the changes from
http://cern.ch/straylen/rpms/apr14/)
I used the chrpath to remove rpath from apr-util and activemq-cpp.
There has been a minor problem in activemq-cpp-devel too: it contains
headers depending on apr-util-devel. I added the dependencies to rpm,
pkg file and config file.
Should we push the packages into EPEL5? (Or should I try? Although I
haven't submit a package to Fedora/EPEL yet.)
Thank you,
Frantisek
I want to add activemq-cpp to to EPEL5 which has been requested a
number of times, this
requires a newer apr and apr-utils.
I've a sticky problem with apr apr-utils.
Work in progress is here.
http://cern.ch/straylen/rpms/apr14/
which builds okay and well as a parallel package but I can't get it
past rpmlint.
In particular apr14.spec I added
sed -i 's/-rpath//' $RPM_BUILD_ROOT%{_bindir}/apr
%{altver}-%{aprver}-config
to drop the "-rpath" from subsequent builds using apr14.
However apr-util13 then fails to build due to trying to install some
.la that are never created.
If I don't removed "-rpath" from apr14 then apr-utils13 builds okay
but contains an rpath in the
result.
If I could persuade apr-util13 to not even attempt to create the .la
files or at least not to install
them this would probably work.
--
Steve Traylen