Re: getting architecture/os info when building an rpm

[Jeff Johnson <jbj JBJ ORG>]

On Tue, Jan 08, 2002 at 12:22:47PM -0500, rpjday wrote:
> On Tue, 8 Jan 2002, Jeff Johnson wrote:
> 
> > RPM_{ARCH,OS} are set by the %___build_pre macro that is expanded at
> > the beginning of a scriptlet (to make it a script):
> > 
> > %___build_pre   \
> >   RPM_SOURCE_DIR=\"%{u2p:%{_sourcedir}}\"\
> >   RPM_BUILD_DIR=\"%{u2p:%{_builddir}}\"\
> >   RPM_OPT_FLAGS=\"%{optflags}\"\
> >   RPM_ARCH=\"%{_arch}\"\
> >   RPM_OS=\"%{_os}\"\
> 
> so, just to make sure i have an answer to my previous question,
> these variables and respective macros are based on the host that
> the build is being done on, right?  and not subject to selection
> by the user.

The %__build_pre macro encapsulates the mapping from macro values to
shell variables in the scriptlet.

The %_target_foo variables are set initially from uname(2), changed
if --target is given on the command line.

%_arch -- the "canonical rpm architecture" i.e. "i386" on i686 --
is the oddball, and acquires it's value when rpm is built.

Ditto %_os, but hardly anyone uses that, as most rpm users and packages
are linux.

>  
> > >   %_target		sparc-sunos
> > >   %_target_arch		%_target_arch (clearly no such macro)
> > 
> > The macro you want is %{_target_cpu}, same name as what autoconf uses.
> 
> which implies that the rpmbuild man page needs fixing.
> 
> > %ifarch uses the expansion of %_target_cpu, %ifos uses %_target_os.
> > 
> > >From build/parseSpec.c:247
> 
> oh, right -- read the *source* to get the answer.  :-)

That's what I do for a living, read the source code to rpm-list users :-)

> 
> > Yup. Isn't legacy wonderful :-(
> 
> this is a rhetorical question, i assume.  thanks for the info.

The question of arch/os in rpm is very, very painful for me, all that's
*really* needed is a set of regex's applied to a string to figger
whether a package is "compatible". Meanwhile, there's beaucoup pokery
jiggery to, say, determine that a kernel that identifies itself as "i686"
is running on a cpu that does not include an (optional) CMOV instruction,
and so should -- really -- be identified as a "i586". Got that :-)

And to add insult to injury, there's hardly anything that I can change
wrto rpm package builds these days. Oh well ...

73 de Jeff

-- 
Jeff Johnson	ARS N3NPQ
jbj@jbj.org	(jbj@redhat.com)
Chapel Hill, NC