Re: [openib-general] Open MPI rpmbuild fails in OFED-1.2
On Wed, 2007-02-14 at 10:44 -0800, Scott Weitzenkamp (sweitzen) wrote: > Tziporet and Doug, we can discuss this at the OFED conf call on Feb 26, > I suggest we try to improve this area. OK. I'll make sure to attend the Feb 26 meeting. > Scott Weitzenkamp > SQA and Release Manager > Server Virtualization Business Unit > Cisco Systems > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Doug Ledford > > Sent: Wednesday, February 14, 2007 10:36 AM > > To: Jeff Squyres (jsquyres) > > Cc: [EMAIL PROTECTED]; 'Openib-General@Openib.Org' > > Subject: Re: [openib-general] Open MPI rpmbuild fails in OFED-1.2 > > > > On Fri, 2007-02-09 at 13:38 -0500, Jeff Squyres wrote: > > > New SRPM on server that munges the %build section into the > > %install > > > section. > > > > > > Yuck. :-) > > > > Worse than yuck, it's wrong. Your SuSE %build section bug is a result > > of trying to build against something that isn't installed yet but is > > required for the build. You guys chose to split things up > > into modules, > > and that's fine and the way things should be, but that means > > you need to > > install required packages along the way if you want to build against > > them, not try to build against binaries in temporary > > directories. Apart > > from that though, I can assure you that on RHEL and FC, the %build > > section is a requirement if you want valid -debuginfo packages. > > > > I've brought it up at the last two conferences I attented, > > and I usually > > get a brick wall when I do, but the OFED packaging process is > > broken by > > design. As Shaun brought up, one of the benefits of proper RPM > > packaging is reliable, reproducible builds, not to mention the whole > > issue of debugging with gdb is nigh impossible without valid debuginfo > > rpms; all of which are vital to supportability. > > > > I'm looking through the alpha1 tarball right now, I'll comment on it > > later under separate email. But, first glance is that I'll be ripping > > everything out and making it sane again. > > > > Which brings up another point that I've mentioned before but > > nothing has > > happened on: as long as you guys keep making your distribution use an > > installation hierarchy that violates the rules for distributions > > shipping code, places like Novell or Red Hat have one of two choices: > > violate the Linux File Hierarchy Standard in our > > distributions or use a > > different hierarchy than you do. Obviously, we aren't going > > to fore go > > LFHS compliance of our entire product for just this, so we use a > > different hierarchy than you. In the end, this can end up causing > > confusion for customers, as well as inconsistency between what Red Hat > > or Novell or you guys choose to use as the file placement. Something > > needs to be done to standardize installation directories in an > > acceptable place IMO (/usr/local is verboten for a > > distribution to use, > > and theoretically that should include you guys since you are a > > distribution source, the only real reason people are > > compiling your code > > locally is that you don't provide binary RPMs or because they want a > > custom compiler instead of gcc, not because they are trying out new > > software they don't necessarily intend to keep/use or which is new > > enough that no one has formally packaged it up, which is what > > /usr/local > > is for). > > > > > > > > On Feb 7, 2007, at 11:42 AM, Vladimir Sokolovsky wrote: > > > > > > > Hi Jeff, > > > > Please remove %build macro from the RPM spec file. > > > > On SuSE distros it removes RPM_BUILD_ROOT. > > > > > > > > Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.23343 > > > > + umask 022 > > > > + cd /var/tmp/OFEDRPM/BUILD > > > > + /bin/rm -rf /var/tmp/OFED > > > > ++ dirname /var/tmp/OFED > > > > + /bin/mkdir -p /var/tmp > > > > + /bin/mkdir /var/tmp/OFED > > > > + cd openmpi-1.2b4ofedr13470 > > > > + fortify_source=1 > > > > + test '' '!=' '' > > > > ... > > > > > > > > -- > > > > Vladimir Sokolovsky <[EMAIL PROTECTED]> > > > > Mellanox Technologies Ltd. > > > > > > > > -- > > Doug Ledford <[EMAIL PROTECTED]> > > GPG KeyID: CFBFF194 > > http://people.redhat.com/dledford > > > > Infiniband specific RPMs available at > > http://people.redhat.com/dledford/Infiniband > > -- Doug Ledford <[EMAIL PROTECTED]> GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband signature.asc Description: This is a digitally signed message part ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] Open MPI rpmbuild fails in OFED-1.2
On Feb 14, 2007, at 1:44 PM, Scott Weitzenkamp ((sweitzen)) wrote: > Tziporet and Doug, we can discuss this at the OFED conf call on Feb > 26, > I suggest we try to improve this area. I strongly agree with this and all of Doug's points (see my prior e- mails on this subject :-) ). -- Jeff Squyres Server Virtualization Business Unit Cisco Systems ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] Open MPI rpmbuild fails in OFED-1.2
Tziporet and Doug, we can discuss this at the OFED conf call on Feb 26, I suggest we try to improve this area. Scott Weitzenkamp SQA and Release Manager Server Virtualization Business Unit Cisco Systems > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Doug Ledford > Sent: Wednesday, February 14, 2007 10:36 AM > To: Jeff Squyres (jsquyres) > Cc: [EMAIL PROTECTED]; 'Openib-General@Openib.Org' > Subject: Re: [openib-general] Open MPI rpmbuild fails in OFED-1.2 > > On Fri, 2007-02-09 at 13:38 -0500, Jeff Squyres wrote: > > New SRPM on server that munges the %build section into the > %install > > section. > > > > Yuck. :-) > > Worse than yuck, it's wrong. Your SuSE %build section bug is a result > of trying to build against something that isn't installed yet but is > required for the build. You guys chose to split things up > into modules, > and that's fine and the way things should be, but that means > you need to > install required packages along the way if you want to build against > them, not try to build against binaries in temporary > directories. Apart > from that though, I can assure you that on RHEL and FC, the %build > section is a requirement if you want valid -debuginfo packages. > > I've brought it up at the last two conferences I attented, > and I usually > get a brick wall when I do, but the OFED packaging process is > broken by > design. As Shaun brought up, one of the benefits of proper RPM > packaging is reliable, reproducible builds, not to mention the whole > issue of debugging with gdb is nigh impossible without valid debuginfo > rpms; all of which are vital to supportability. > > I'm looking through the alpha1 tarball right now, I'll comment on it > later under separate email. But, first glance is that I'll be ripping > everything out and making it sane again. > > Which brings up another point that I've mentioned before but > nothing has > happened on: as long as you guys keep making your distribution use an > installation hierarchy that violates the rules for distributions > shipping code, places like Novell or Red Hat have one of two choices: > violate the Linux File Hierarchy Standard in our > distributions or use a > different hierarchy than you do. Obviously, we aren't going > to fore go > LFHS compliance of our entire product for just this, so we use a > different hierarchy than you. In the end, this can end up causing > confusion for customers, as well as inconsistency between what Red Hat > or Novell or you guys choose to use as the file placement. Something > needs to be done to standardize installation directories in an > acceptable place IMO (/usr/local is verboten for a > distribution to use, > and theoretically that should include you guys since you are a > distribution source, the only real reason people are > compiling your code > locally is that you don't provide binary RPMs or because they want a > custom compiler instead of gcc, not because they are trying out new > software they don't necessarily intend to keep/use or which is new > enough that no one has formally packaged it up, which is what > /usr/local > is for). > > > > > On Feb 7, 2007, at 11:42 AM, Vladimir Sokolovsky wrote: > > > > > Hi Jeff, > > > Please remove %build macro from the RPM spec file. > > > On SuSE distros it removes RPM_BUILD_ROOT. > > > > > > Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.23343 > > > + umask 022 > > > + cd /var/tmp/OFEDRPM/BUILD > > > + /bin/rm -rf /var/tmp/OFED > > > ++ dirname /var/tmp/OFED > > > + /bin/mkdir -p /var/tmp > > > + /bin/mkdir /var/tmp/OFED > > > + cd openmpi-1.2b4ofedr13470 > > > + fortify_source=1 > > > + test '' '!=' '' > > > ... > > > > > > -- > > > Vladimir Sokolovsky <[EMAIL PROTECTED]> > > > Mellanox Technologies Ltd. > > > > > -- > Doug Ledford <[EMAIL PROTECTED]> > GPG KeyID: CFBFF194 > http://people.redhat.com/dledford > > Infiniband specific RPMs available at > http://people.redhat.com/dledford/Infiniband > ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] Open MPI rpmbuild fails in OFED-1.2
On Fri, 2007-02-09 at 13:38 -0500, Jeff Squyres wrote: > New SRPM on server that munges the %build section into the %install > section. > > Yuck. :-) Worse than yuck, it's wrong. Your SuSE %build section bug is a result of trying to build against something that isn't installed yet but is required for the build. You guys chose to split things up into modules, and that's fine and the way things should be, but that means you need to install required packages along the way if you want to build against them, not try to build against binaries in temporary directories. Apart from that though, I can assure you that on RHEL and FC, the %build section is a requirement if you want valid -debuginfo packages. I've brought it up at the last two conferences I attented, and I usually get a brick wall when I do, but the OFED packaging process is broken by design. As Shaun brought up, one of the benefits of proper RPM packaging is reliable, reproducible builds, not to mention the whole issue of debugging with gdb is nigh impossible without valid debuginfo rpms; all of which are vital to supportability. I'm looking through the alpha1 tarball right now, I'll comment on it later under separate email. But, first glance is that I'll be ripping everything out and making it sane again. Which brings up another point that I've mentioned before but nothing has happened on: as long as you guys keep making your distribution use an installation hierarchy that violates the rules for distributions shipping code, places like Novell or Red Hat have one of two choices: violate the Linux File Hierarchy Standard in our distributions or use a different hierarchy than you do. Obviously, we aren't going to fore go LFHS compliance of our entire product for just this, so we use a different hierarchy than you. In the end, this can end up causing confusion for customers, as well as inconsistency between what Red Hat or Novell or you guys choose to use as the file placement. Something needs to be done to standardize installation directories in an acceptable place IMO (/usr/local is verboten for a distribution to use, and theoretically that should include you guys since you are a distribution source, the only real reason people are compiling your code locally is that you don't provide binary RPMs or because they want a custom compiler instead of gcc, not because they are trying out new software they don't necessarily intend to keep/use or which is new enough that no one has formally packaged it up, which is what /usr/local is for). > > On Feb 7, 2007, at 11:42 AM, Vladimir Sokolovsky wrote: > > > Hi Jeff, > > Please remove %build macro from the RPM spec file. > > On SuSE distros it removes RPM_BUILD_ROOT. > > > > Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.23343 > > + umask 022 > > + cd /var/tmp/OFEDRPM/BUILD > > + /bin/rm -rf /var/tmp/OFED > > ++ dirname /var/tmp/OFED > > + /bin/mkdir -p /var/tmp > > + /bin/mkdir /var/tmp/OFED > > + cd openmpi-1.2b4ofedr13470 > > + fortify_source=1 > > + test '' '!=' '' > > ... > > > > -- > > Vladimir Sokolovsky <[EMAIL PROTECTED]> > > Mellanox Technologies Ltd. > > -- Doug Ledford <[EMAIL PROTECTED]> GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband signature.asc Description: This is a digitally signed message part ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] Open MPI rpmbuild fails in OFED-1.2
New SRPM on server that munges the %build section into the %install section. Yuck. :-) On Feb 7, 2007, at 11:42 AM, Vladimir Sokolovsky wrote: > Hi Jeff, > Please remove %build macro from the RPM spec file. > On SuSE distros it removes RPM_BUILD_ROOT. > > Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.23343 > + umask 022 > + cd /var/tmp/OFEDRPM/BUILD > + /bin/rm -rf /var/tmp/OFED > ++ dirname /var/tmp/OFED > + /bin/mkdir -p /var/tmp > + /bin/mkdir /var/tmp/OFED > + cd openmpi-1.2b4ofedr13470 > + fortify_source=1 > + test '' '!=' '' > ... > > -- > Vladimir Sokolovsky <[EMAIL PROTECTED]> > Mellanox Technologies Ltd. -- Jeff Squyres Server Virtualization Business Unit Cisco Systems ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] Open MPI rpmbuild fails in OFED-1.2
Michael S. Tsirkin wrote: >> Quoting Jeff Squyres <[EMAIL PROTECTED]>: >> 2) we're trying to *use* the software when it is installed in the >> DESTDIR >> --> this means that you have to put special-case in the software so >> that they look for support files in both the DESTDIR *and* the final >> installation directory Either that, or fix your resulting package so that it will work with the final installation directory case (not work with both), and then setup a temporary environment that will allow it to work for the rest of the build process. For the mpitests package being built against our RPM result, this is the approach I took. It took me a little time to figure out how to do this, because it is odd. > How do you mean, use? I assume this means linking against the libraries. In the mpitests RPM build, it could mean using mpicc, etc. from the MPI package while it itself is not working in its final destination directory. No one does this sort of thing normally when building software packages from source code. > Hmm. I guess my question is - this works fine when I run OFED's > configure script, why is SRPM so much more difficult? Anyone can correct me if I am reading this wrong, but I've commented on this at least once before - somewhat indirectly. I've built and supported open source software at the OSU CSE department for a long time - so I've built many different packages from source about a million times. When you build a source code package, obviously you make sure the necessary libraries can be found. These libraries are in some system location - their "final installation directory". If this location is not in the default search path, you can deal with that various ways or add the path to the system's default. If your package builds its own libraries and also uses them, then you deal with that yourself in your package's build system. When you say OFED's configure script, this is the situation I see. Never have I purposely built the libraries required for a package in a temporary location, built the package against those libraries, and then moved everything to a final location. It makes things more difficult. Take our SRPM for example. If you have OFED installed, I am mainly concerned with the stack prefix, by default /usr/local/ofed. If I build our code with the libraries in their final location, I don't have to worry about subtle things like the various scripts having this path hard coded in them. Most packages rightly make the assumption that these paths you use are to dependencies that have already been installed, and if there is some need to incorporate those paths into the package build result, for whatever reason, it's all right to do that. In our SRPM, I need to fix some things in the OFED installer case because the libraries I am building against are not in their final location. These are things that I do not have to do normally, however to be fair - I already have to fix some things because of the RPM BuildRoot usage anyway because our package is not installed in its final destination either in any RPM building scenario. It only goes into its final destination directory when you install the actual RPM. With RPMs, this is a good, safe way to build _individual_ packages. In the SuSE case, the %build section is assuming this and cleaning things up before you start, because - why would there be anything in there BuildRoot already? Is this right or wrong? That's a matter of opinion. There's information in various RPM building resources that mention some of this stuff. Luckily this is not a big deal for me to handle in our case. However, it could have been. This is like a "bootstrap" situation, but it's not normally how one would go and build some source code package on their system, and RPMs are all about reproducible source code builds. Again, to be totally fair, you wouldn't normally install your package into a BuildRoot prefixed "prefix" location either, but that seems easier to deal with than the location of libraries your package may depend on. And to go even further, as in the mpitests RPM build case, would one normally expect the RPM build result that is installed in a BuildRoot prefixed "prefix" and just left there to even work? I would say it is absolutely not safe to just assume that for any given RPM build. This all depends on the source code you are trying to build and what it does exactly. Any time you are using paths that don't reflect the final destination of whatever dependency, you have the potential to have to deal with extra work to fix the final result. In the usual SRPM building case, the packages that your package depends on would already be installed on the system in their final destination directory. I could even require these RPM packages as build requirements - something I am not doing in the spec file itself, yes? This would mean that I could take a few steps out of my SRPM spec file. From what I am reading here, this would be one reason to think of a chroo
Re: [openib-general] Open MPI rpmbuild fails in OFED-1.2
> Quoting Jeff Squyres <[EMAIL PROTECTED]>: > Subject: Re: Open MPI rpmbuild fails in OFED-1.2 > > On Feb 7, 2007, at 2:49 PM, Michael S. Tsirkin wrote: > > >> My $0.02: This is another in a growing list of issues reflecting the > >> whole "build everything in DESTDIR" is a problematic approach. > > > > I don't know much about RPM, and I am not exactly sure why are > > our source RPMs so complicated. > > It's a combination of two things: > > 1) similar to what you said below, we have lots of software packages > that are all dependent upon each other > --> this leads to a conglomeration of rpath's and shared library > dependencies that are incorrect > > 2) we're trying to *use* the software when it is installed in the > DESTDIR > --> this means that you have to put special-case in the software so > that they look for support files in both the DESTDIR *and* the final > installation directory How do you mean, use? Hmm. I guess my question is - this works fine when I run OFED's configure script, why is SRPM so much more difficult? -- MST ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] Open MPI rpmbuild fails in OFED-1.2
> Quoting Jeff Squyres <[EMAIL PROTECTED]>: > Subject: Re: Open MPI rpmbuild fails in OFED-1.2 > > My $0.02: This is another in a growing list of issues reflecting the > whole "build everything in DESTDIR" is a problematic approach. I don't know much about RPM, and I am not exactly sure why are our source RPMs so complicated. However, with the plan configure/make we are able to build all openfabrics components within build directory, without any chroot tricks. So let's not give up yet, IMO it is very nice to be able to build in standard environment, without being root. Note that what is biting us here is mostly the large number of modules: simple single-module packages don't have this problem - and this is really a design decision we took. -- MST ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] Open MPI rpmbuild fails in OFED-1.2
My $0.02: This is another in a growing list of issues reflecting the whole "build everything in DESTDIR" is a problematic approach. I have distinct %build and %install sections in the Open MPI specfile -- they're really intended for two different things. Specifically: I wouldn't call the SuSE %build behavior a bug -- it reflects how they want RPM designers to write RPMs. It appears that we're trying to circumvent their intended approach. Shouldn't that be a warning flag? :-) I've heard offhand comments that there were problems with trying to use chroot for building OFED. The two that I'm aware of are: 1. need to be root to make a chroot. My thought: who cares? 2. takes up lots of extra disk space. My thought: does it matter? Do we know of anyone who has small- disk servers who are building OFED? (and/or: can you hard-link files to make a chroot environment? I'm don't know) Are there other issues? More specifically, which is going to be simpler: a) fixing the growing list of problems with the DESTDIR approach or b) switching to a chroot environment? A simple search for "chroot" on freshmeat, for example, turns up a number of projects that can be used to help automate the creation of chroot environments. Again -- this is all my $0.02. Comments? On Feb 7, 2007, at 12:00 PM, Vladimir Sokolovsky wrote: > I propose to replace %build by %install. > Otherwise %build removes /var/tmp/OFED (on SuSE) which includes all > installed libraries. > > Regards, > Vladimir > > On Wed, 2007-02-07 at 11:52 -0500, Jeff Squyres wrote: >> The "%build" directive is not just a macro, it's also a section >> qualifier indicating the beginning of the build section. From >> >> http://fedora.redhat.com/docs/drafts/rpm-guide-en/ >> ch08s02.html#id2966770 >> >> "The build section starts with a %build statement." >> >> Is there something else that I should replace it with that will also >> start the build section? >> >> >> >> On Feb 7, 2007, at 11:42 AM, Vladimir Sokolovsky wrote: >> >>> Hi Jeff, >>> Please remove %build macro from the RPM spec file. >>> On SuSE distros it removes RPM_BUILD_ROOT. >>> >>> Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.23343 >>> + umask 022 >>> + cd /var/tmp/OFEDRPM/BUILD >>> + /bin/rm -rf /var/tmp/OFED >>> ++ dirname /var/tmp/OFED >>> + /bin/mkdir -p /var/tmp >>> + /bin/mkdir /var/tmp/OFED >>> + cd openmpi-1.2b4ofedr13470 >>> + fortify_source=1 >>> + test '' '!=' '' >>> ... >>> >>> -- >>> Vladimir Sokolovsky <[EMAIL PROTECTED]> >>> Mellanox Technologies Ltd. >> >> -- Jeff Squyres Server Virtualization Business Unit Cisco Systems ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] Open MPI rpmbuild fails in OFED-1.2
I propose to replace %build by %install. Otherwise %build removes /var/tmp/OFED (on SuSE) which includes all installed libraries. Regards, Vladimir On Wed, 2007-02-07 at 11:52 -0500, Jeff Squyres wrote: > The "%build" directive is not just a macro, it's also a section > qualifier indicating the beginning of the build section. From > > http://fedora.redhat.com/docs/drafts/rpm-guide-en/ch08s02.html#id2966770 > > "The build section starts with a %build statement." > > Is there something else that I should replace it with that will also > start the build section? > > > > On Feb 7, 2007, at 11:42 AM, Vladimir Sokolovsky wrote: > > > Hi Jeff, > > Please remove %build macro from the RPM spec file. > > On SuSE distros it removes RPM_BUILD_ROOT. > > > > Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.23343 > > + umask 022 > > + cd /var/tmp/OFEDRPM/BUILD > > + /bin/rm -rf /var/tmp/OFED > > ++ dirname /var/tmp/OFED > > + /bin/mkdir -p /var/tmp > > + /bin/mkdir /var/tmp/OFED > > + cd openmpi-1.2b4ofedr13470 > > + fortify_source=1 > > + test '' '!=' '' > > ... > > > > -- > > Vladimir Sokolovsky <[EMAIL PROTECTED]> > > Mellanox Technologies Ltd. > > ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] Open MPI rpmbuild fails in OFED-1.2
The "%build" directive is not just a macro, it's also a section qualifier indicating the beginning of the build section. From http://fedora.redhat.com/docs/drafts/rpm-guide-en/ch08s02.html#id2966770 "The build section starts with a %build statement." Is there something else that I should replace it with that will also start the build section? On Feb 7, 2007, at 11:42 AM, Vladimir Sokolovsky wrote: > Hi Jeff, > Please remove %build macro from the RPM spec file. > On SuSE distros it removes RPM_BUILD_ROOT. > > Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.23343 > + umask 022 > + cd /var/tmp/OFEDRPM/BUILD > + /bin/rm -rf /var/tmp/OFED > ++ dirname /var/tmp/OFED > + /bin/mkdir -p /var/tmp > + /bin/mkdir /var/tmp/OFED > + cd openmpi-1.2b4ofedr13470 > + fortify_source=1 > + test '' '!=' '' > ... > > -- > Vladimir Sokolovsky <[EMAIL PROTECTED]> > Mellanox Technologies Ltd. -- Jeff Squyres Server Virtualization Business Unit Cisco Systems ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] Open MPI rpmbuild fails in OFED-1.2
Hi Jeff, Please remove %build macro from the RPM spec file. On SuSE distros it removes RPM_BUILD_ROOT. Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.23343 + umask 022 + cd /var/tmp/OFEDRPM/BUILD + /bin/rm -rf /var/tmp/OFED ++ dirname /var/tmp/OFED + /bin/mkdir -p /var/tmp + /bin/mkdir /var/tmp/OFED + cd openmpi-1.2b4ofedr13470 + fortify_source=1 + test '' '!=' '' ... -- Vladimir Sokolovsky <[EMAIL PROTECTED]> Mellanox Technologies Ltd. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
