[ewg] RFC: OFED-1.3-20070823-1130 - first build

Doug Ledford dledford at redhat.com
Mon Aug 27 13:10:49 PDT 2007


On Mon, 2007-08-27 at 11:32 +0300, Vladimir Sokolovsky wrote:
> Doug Ledford wrote:
> > On Fri, 2007-08-24 at 13:47 +0200, Stefan Roscher wrote:
> >> Hi Vladimir,
> >>
> >> I tested the new build environment with some different configurations. From my
> >> point of view it is a good solution. Very easy to use and to understand.
> >>
> >> During the tests I found 2 little issues.
> >>
> >> The first one hits the libibverbs. On ppc64 I built OFED-1.2 with following
> >> command:
> >> 	./install.pl --basic
> >>
> >> Now the libibverbs is installed in /usr/lib64, but it is a 32bit libary:
> >>
> >> 	systemx  # file /usr/lib64/libibverbs.so.1.0.0 
> >> 	/usr/lib64/libibverbs.so.1.0.0: ELF 32-bit MSB shared object, 
> >> 	PowerPC or cisco 4500, version 1 (SYSV), not stripped
> > 
> > I would guess this is because you are trying to set the libdir and
> > compile mode flags yourselves?  The rpmbuild environment has the ability
> > to set these things for you.  For example, if you build using this
> > command on a ppc64 machine:
> > 
> > rpmbuild --ba --target=ppc libibverbs.spec
> > 
> > and inside the libibverbs.spec file simply use %{_libdir} and CFLAGS=
> > $RPM_OPT_FLAGS, then you get the right result.
> > 
> > Likewise, rpmbuild --ba --target=ppc64 libibverbs.spec *also* does the
> > right thing if you use %{_libdir} during configure and in %files and
> > also set CFLAGS=$RPM_OPT_FLAGS.
> > 
> > The only requirement for this to work is that you need to have installed
> > rpm-devel.ppc and rpm-devel.ppc64 (you get the correct macros from those
> > different packages).
> > 
> > At least this is how it works under RHEL.  I would hope that SuSE is
> > sane in this regard too.
> > 
> > Trying to outsmart rpm instead of working with rpm on stuff like this is
> > a big part of why I want tarballs, not a distribution.  It breaks in all
> > sorts of subtle ways.
> > 
> >> So the following libaries like libmthca and libehca can not configure because
> >> the libibverbs check fails. After I exported LDFLAGS and CFLAGS explicit with
> >> -m64 option it was working fine.
> > 
> > The ppc64 RPM_OPT_FLAGS include -m64 because we know that -m32 is the
> > default setting in the compiler and you need it to force 64bit apps.
> > 
> 
> 
> Hi Doug,
> I tried what you said:
> 
> rpmbuild --ba --target=ppc  --define "CFLAGS \$RPM_OPT_FLAGS" libibverbs.spec

You shouldn't need to define CFLAGS like this, the build usually picks
it up automatically.  IIRC, the start of the build script automatically
sets the CFLAGS environment variable to $RPM_OPT_FLAGS.  However, if I'm
wrong on that, then the correct way to set it is something like:

%build
%configure CFLAGS="$RPM_OPT_FLAGS"
make %{?_smp_mflags}

> But still got '--libdir=/usr/lib64' in the options to the configure during rpmbuild.
> 
> In the libibverbs.spec:
> %build
> %configure
> make %{?_smp_mflags}
> 
> Both rpm-devel.ppc and rpm-devel.ppc64 are installed.
> What is wrong?

OK, it's a bug in the rpm packaging.  In particular, /var/lib/rpm/macros
has the base settings for rpm when building.  Then, for arch specific
settings, there is /var/lib/rpm/linux-%{arch}/macros.  RPM *should* also
have a /var/lib/rpm/linux-%{secondary_arch}/macros file to override the
settings that the default arch uses.  I don't see this internally since
we build on the arch we are building for, but it exists none the less.
I'll file a bug against our rpm package about this.  Were you trying
this on RHEL4 or RHEL5 or something else?


-- 
Doug Ledford <dledford at redhat.com>
              GPG KeyID: CFBFF194
              http://people.redhat.com/dledford

Infiniband specific RPMs available at
              http://people.redhat.com/dledford/Infiniband
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.openfabrics.org/pipermail/ewg/attachments/20070827/8b8c9edd/attachment.sig>


More information about the ewg mailing list