I'm building my own openmpi packages derived from upstream SRPMs.
Problem: The ones built with Intel's compiler can only be installed by force, because Intel doesn't register their provided libs with rpm.
Any idea how this can be done?
(Alternative ideas are appreciated as well -- as long as they don't read as: make Intel fix this.)
-Michael
On Sun, 26 Feb 2012 19:45:54 +0100 Michael Lampe wrote:
I'm building my own openmpi packages derived from upstream SRPMs.
Problem: The ones built with Intel's compiler can only be installed by force, because Intel doesn't register their provided libs with rpm.
Any idea how this can be done?
A dependency is supposed to be something that's required for a program to work. Removing the dependency from the rpm won't magically make a program work if it really does require the functionality provided by that dependency.
If it's not actually required for some reason, then install the .src.rpm, edit the spec file to remove or modify the dependency list, and compile new source and binary rpms.
Frank Cox wrote:
A dependency is supposed to be something that's required for a program to work. Removing the dependency from the rpm won't magically make a program work if it really does require the functionality provided by that dependency.
It's there.
Just not registered with rpm. -- Intel's fault, I cannot do anything about it.
I'm heading for a compromise ...
On Sun, 26 Feb 2012 20:14:50 +0100 Michael Lampe wrote:
Frank Cox wrote:
A dependency is supposed to be something that's required for a program to work. Removing the dependency from the rpm won't magically make a program work if it really does require the functionality provided by that dependency.
It's there.
Just not registered with rpm. -- Intel's fault, I cannot do anything about it.
Then the solution I posted will solve the problem.
The easiest way to do it is this:
yum install rpmdevtools rpmdev-setuptree rpm -i nameofsrcrpm.src.rpm cd ~/rpmbuild/SPECS vi nameofspecfile.spec
Edit the dependency list to suit.
rpmbuild -ba nameofspecfile.spec
That's it. You now have a new .src.rpm and binary rpm.
Frank Cox wrote:
Edit the dependency list to suit.
Maybe I was too dumb to properly explain it:
The Intel stuff is there implicitly. And it _is_ needed. Both for building and then running.
But it's not registered with rpm by Intel!
So I _can_ build, but the resulting RPM cannot be installed -- if not forced. (No problems then as everything _is_ there.)
The compromise I see is removing these explicit dependencies. They are fulfilled, but not formally available.
On 02/26/2012 08:39 PM, Michael Lampe wrote:
Frank Cox wrote:
Edit the dependency list to suit.
Maybe I was too dumb to properly explain it:
The Intel stuff is there implicitly. And it _is_ needed. Both for building and then running.
But it's not registered with rpm by Intel!
So I _can_ build, but the resulting RPM cannot be installed -- if not forced. (No problems then as everything _is_ there.)
The compromise I see is removing these explicit dependencies. They are fulfilled, but not formally available.
I totally lost you. Please provide specifics, what package, is it in rpm or not, details please, so we do not chase out own tails.
Ljubomir Ljubojevic wrote:
I totally lost you.
No problem. Play the game of chess like your namesake did so well. :)
Please provide specifics, what package, is it in rpm or not, details please, so we do not chase out own tails.
Gimme a trick: How to unregister an implicit but formally unavailable runtime dependency in a spec file?
It's there at build time and therfore automatically used. Package builds fine. But it can only be installed by force, because the implicit dependency is explicitly recorded in the RPM. I want to get rid of that, because fixing Intel's stuff is not an option.
Still unclear??
On Sun, 26 Feb 2012 21:05:22 +0100 Michael Lampe wrote:
Gimme a trick: How to unregister an implicit but formally unavailable runtime dependency in a spec file?
I've given you the solution twice. Here is a more detailed description of the exact lines that you need to edit in the spec file:
http://www.rpm.org/max-rpm/s1-rpm-depend-manual-dependencies.html
Frank Cox wrote:
Gimme a trick: How to unregister an implicit but formally unavailable runtime dependency in a spec file?
I've given you the solution twice. Here is a more detailed description of the exact lines that you need to edit in the spec file:
http://www.rpm.org/max-rpm/s1-rpm-depend-manual-dependencies.html
We are talking about different things:
My stuff is linked against 'libfoo'. When the package is finally build, it records this depedency because of that. Now this package requires libfoo to be installed. It's there but not registered with rpm!
That's what I want to get rid of. Something like 'Unrequire' perhaps. Or another trick: IIRC, at some time taking the x bit from libs achieved that, but it's not working anymore since quite some time.
----- "Michael Lampe" lampe@gcsc.uni-frankfurt.de escreveu:
De: "Michael Lampe" lampe@gcsc.uni-frankfurt.de Para: "CentOS mailing list" centos@centos.org Enviadas: Domingo, 26 de Fevereiro de 2012 17:29:05 (GMT-0300) Auto-Detected Assunto: Re: [CentOS] Is there a way to _remove_ dependencies from an RPM built from source?
Frank Cox wrote:
Gimme a trick: How to unregister an implicit but formally
unavailable runtime dependency in a spec file?
I've given you the solution twice. Here is a more detailed description of the exact lines that you need to edit in the spec file:
http://www.rpm.org/max-rpm/s1-rpm-depend-manual-dependencies.html
We are talking about different things:
My stuff is linked against 'libfoo'. When the package is finally build, it records this depedency because of that. Now this package requires libfoo to be installed. It's there but not registered with rpm!
That's what I want to get rid of. Something like 'Unrequire' perhaps. Or another trick: IIRC, at some time taking the x bit from libs achieved that, but it's not working anymore since quite some time.
Ok,
Have you tried to make a fake src.rpm package that "provides" this 'libfoo' and install it ? It didn't need to install anything just tell to the rpm library that it "provides" 'libfoo'.
Another way is to just force the install, but, doing it you will have some problems during updates.
Antonio Jr.
Antonio da Silva Martins Junior wrote:
Have you tried to make a fake src.rpm package that "provides" this 'libfoo' andinstall it ? It didn't need to install anything just tell to the rpm library that it "provides" 'libfoo'.
Normally, I leave the building straightforward.
Of course, I can also climb to the roof, use the fire exit, arrive at the backyard and find my way out somehow from there.
Another way is to just force the install, but, doing it you will have some problemsduring updates.
Of course, I just do that. Since years, and there are no problems with updates.
Only with EL6 and the automatic 'yum ckeck' I'm getting pissed somehow:
** Found 11 pre-existing rpmdb problem(s), 'yum check' output follows:
libcilkrts.so.5()(64bit), libifcoremt.so.5()(64bit), ...
I know that already!
So I was humbly asking for some trick here.
There must be some, even if Google didn't find me one.
On Sun, Feb 26, 2012 at 2:57 PM, Michael Lampe lampe@gcsc.uni-frankfurt.de wrote:
Have you tried to make a fake src.rpm package that "provides" this 'libfoo' and install it ? It didn't need to install anything just tell to the rpm library that it "provides" 'libfoo'.
Normally, I leave the building straightforward.
Of course, I can also climb to the roof, use the fire exit, arrive at the backyard and find my way out somehow from there.
Not sure I get the analogy. You are apparently working with 2 uncoordinated rpm builders, so your choices are to get the original authors to coordinate the provides/depends, fix it yourself, or ignore the brokeness.
So I was humbly asking for some trick here.
Normally if an rpm requires something that isn't in the base distro, another rpm from the same 3rd party packager will provide it. If you don't install the expected combinations, you can expect things to break - or to have to go through some contortions to keep everything happy.
Les Mikesell wrote:
Have you tried to make a fake src.rpm package that "provides" this 'libfoo' andinstall it ? It didn't need to install anything just tell to the rpm library that it "provides" 'libfoo'.
Normally, I leave the building straightforward.
Of course, I can also climb to the roof, use the fire exit, arrive at the backyard and find my way out somehow from there.
Not sure I get the analogy. You are apparently working with 2 uncoordinated rpm builders, so your choices are to get the original authors to coordinate the provides/depends, fix it yourself, or ignore the brokeness.
I can only do no. 3 -- take things as they are and try to make the best of it.
The uncoordinated rpm builders are Redhat and especially Intel.
Removing the build deps from runtime is possible. Only Google finds you a lot of nonsense. Plain bullshit, old stuff from yesteryear, or stuff from the future (CentOS wise).
To recap: I'm in the middle and still want to build a sensible rpm for openmpi with intel:
%define _use_internal_dependency_generator 0 %define __find_requires %{nil}
Order is important. After that, '__find_requires' can even be made into a script, that falls back on '/usr/lib/rpm/redhat/find-requires' and filters out what is disturbing.
Hey! I love rpm! Whenever I feel real bad, I turn to rpm! (And then start to ask for help ...)
:)
On Mon, 2012-02-27 at 02:52 +0100, Michael Lampe wrote:
To recap: I'm in the middle and still want to build a sensible rpm for openmpi with intel:
%define _use_internal_dependency_generator 0 %define __find_requires %{nil}
--- If you did not want any deps then all you had to do was:
%{!?disable_auto_requires: %define disable_auto_requires 0} to %{!?disable_auto_requires: %define disable_auto_requires 1}
in the spec file if you got the srpm from the open-mpi.org site. Which leads to this being changed.
%if %{disable_auto_requires} AutoReq: no %endif
On Sun, 2012-02-26 at 21:29 +0100, Michael Lampe wrote:
AutoProvReq: no || 0
On Sun, 2012-02-26 at 23:11 +0100, Markus Falb wrote:
On 26.2.2012 21:55, John Stanley wrote:
On Sun, 2012-02-26 at 21:29 +0100, Michael Lampe wrote:
AutoProvReq: no || 0
Why the || 0 ?
You can use '0' or no.
for el5 try
AutoReq: no AutoProv: no
On Sun, 2012-02-26 at 21:05 +0100, Michael Lampe wrote:
Ljubomir Ljubojevic wrote:
I totally lost you.
No problem. Play the game of chess like your namesake did so well. :)
Please provide specifics, what package, is it in rpm or not, details please, so we do not chase out own tails.
Gimme a trick: How to unregister an implicit but formally unavailable runtime dependency in a spec file?
It's there at build time and therfore automatically used. Package builds fine. But it can only be installed by force, because the implicit dependency is explicitly recorded in the RPM. I want to get rid of that, because fixing Intel's stuff is not an option.
Would it be be possible to create a dummy rom that requires the intel-rpm but does provide the dependency?
On Sun, Feb 26, 2012 at 1:39 PM, Michael Lampe lampe@gcsc.uni-frankfurt.de wrote:
Frank Cox wrote:
Edit the dependency list to suit.
Maybe I was too dumb to properly explain it:
The Intel stuff is there implicitly. And it _is_ needed. Both for building and then running.
But it's not registered with rpm by Intel!
So I _can_ build, but the resulting RPM cannot be installed -- if not forced. (No problems then as everything _is_ there.)
The compromise I see is removing these explicit dependencies. They are fulfilled, but not formally available.
I haven't tried this, but I would expect it to be possible to build a dummy package that claims to supply the dependency you need (which might itself depend on whatever the intel package does claim to provide, or just check and print an error message if it doesn't see the files in the right place).
On Sunday 26 February 2012 20:39:03 Michael Lampe wrote:
So I can build, but the resulting RPM cannot be installed -- if not forced. (No problems then as everything is there.)
Why don't you add the files needed as dependencies to the spec file? (it's one of the beautis of the rpm system over deb)
Marc Deop wrote:
On Sunday 26 February 2012 20:39:03 Michael Lampe wrote:
So I can build, but the resulting RPM cannot be installed -- if not forced. (No problems then as everything is there.)
Why don't you add the files needed as dependencies to the spec file? (it's one of the beautis of the rpm system over deb)
Duplicate them, or what? They are already there. Only not registered with rpm. (Intel's compiler comes with several runtime libs, and openmpi is not a program, but an additional runtime for building one's own programs.)
The best approximation is to remove the intel deps. Can be done. Other's did it before, and I did it too. Only I don't even have a borderline addiction to rpm.
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Michael Lampe
I'm building my own openmpi packages derived from upstream SRPMs.
Problem: The ones built with Intel's compiler can only be installed by force, because Intel doesn't register their provided libs with rpm.
Any idea how this can be done?
(Alternative ideas are appreciated as well -- as long as they don't read as: "make Intel fix this".)
-Michael
This Intel knowledgebase article lists which libraries are redistributable from their compiler collection:
http://software.intel.com/en-us/articles/redistributable-libraries-for-the-i...
and this article on Intel's web site addresses which components may be redistributed by the end-developer to the end-user:
http://software.intel.com/en-us/articles/redistribution-of-application-binar...
"Intel's redistributable compiler libraries package may be added to the distributed application package for any end-user application built or partially built with an Intel compiler that is distributed by an Intel customer who holds an Intel Commercial or Academic license for the associated Intel compiler product. The Intel redistributable compiler libraries package may be distributed as a separate non-modified module to the end-users of the distributed application."
In the paragraph above, Intel explicitly states that you may redistribute the libraries as a separate non-modified module to end users of your distributed application. This means that you could package the redistributable libraries into a sub-package (for example, as 'openmpi-libs') and list the sub-package as a dependency in the main package. If you need some help on how to create a sub-package within your SPEC file, I would be glad to provide some pointers -- as a systems integrator, I've had to maintain both existing RPMs and create new ones from scratch where there wasn't one.
Reading between the lines here, Intel may also have an implied restriction that the libraries only be redistributed with your application. When in doubt, ask. A link to Intel's forum for their C++ compiler is here: http://software.intel.com/en-us/forums/intel-c-compiler/
Regarding 'implicit' dependencies being recorded by RPM into the package, refer to the RPM documentation for an explanation of how RPM (rpmbuild) determines the dependencies and how it records these into the package being built:
http://www.rpm.org/max-rpm/s1-rpm-depend-auto-depend.html
Internally, the rpmbuild utility uses a shell script to call the 'ldd' (list dynamic dependencies) utility to list and parse which shared libraries that an executable (or library) has been linked against.
Cheers!
Simba Engineering
Other helpful information:
Refer to this tech note available on Intel's web site for more information about using Intel compilers (C++, Fortran) with RedHat / CentOS / Fedora Linux: http://software.intel.com/en-us/articles/using-intel-compilers-for-linux-und...
On 02/26/2012 12:45 PM, Michael Lampe wrote:
I'm building my own openmpi packages derived from upstream SRPMs.
Problem: The ones built with Intel's compiler can only be installed by force, because Intel doesn't register their provided libs with rpm.
Any idea how this can be done?
(Alternative ideas are appreciated as well -- as long as they don't read as: make Intel fix this.)
OK. So the problem is that you have libs on your machine that are not registered in the RPM database.
If those libs were registered then you are saying that this would solve your problem?
If so, then all you need to do is to put the info into the database. The problem here is with the shared libraries being on your machine and not in the RPM database. That is the issue you need to solve, or you will have to deal with it on each and every other thing you build.
How were the Intel shared libs installed on your machine? (Via an RPM or via a manual "configure/make/make install"). If the files were installed via a make install and not an RPM, the fix is to install them via an RPM or to create entries for them in the database.
I see that there are RPM files for the intel compiler ... do these not register in the database?
If you know the names of all the files, you can create an RPM that has all those files and install it with an "rpm -Uvh --justdb <rpm-filename>" to not touch the filesystem but to update those files into the rpm database.
Or, you could actually create a proper RPM for the Intel files and install them via the RPM.
-
Antonio da Silva Martins Junior -
Frank Cox -
John Stanley -
Johnny Hughes -
Les Mikesell -
Ljubomir Ljubojevic -
Louis Lagendijk -
Marc Deop -
Markus Falb -
Michael Lampe -
Phoenix, Merka