Re: src.rpm for x86_64

[Carl Nygard <cjnygard fast net>]

And now I'm really confused.  my /usr/lib/rpm/macros defines _lib="lib",
but running the rpmbuild process with a simple 'echo lib=%{_lib}' shows
lib64 as the result.

So somewhere _lib is getting redefined, and I can't see where.  Not
anywhere (that I know) in /usr/lib/rpm or in /etc/rpm.

Now I'm clueless, the only solution I can see is either:

sudo ln -s /usr/lib/rpm /usr/lib64/rpm
or hardcode the path to brp-compress in the %install portion of the spec
file.

ln -s will work for me temporarily


Just figure out, there's architecture-specific subdir with it's own
macro redefinitions.  Mystery solved, but still no good solution.

On Wed, 2004-10-20 at 14:45, Ross McFarland wrote:
> Carl Nygard said:
> > Processing files: perl-ExtUtils-Depends-0.204-1
> > error: File not found:
> > /var/tmp/perl-ExtUtils-Depends-0.204-1-root/usr/share/man/man3/ExtUtils::Depends.3pm
> >
> > Finally found the docs where the macros are defined (that was way too
> > hard).
> >
> > The only thing I can come up with is to do this:
> >
> > -[ -x %{_libdir}/rpm/brp-compress ] && %{_libdir}/rpm/brp-compress
> > +[ -x %{_prefix}/%{_lib}/rpm/brp-compress ] &&
> > %{_prefix}/%{_lib}/rpm/brp-compress
>
> i suspect this is just preventing brp-compress from running. -x ... will
> likely fail b/c i don't think brp-compress will be in _prefix..., the location
> into which the rpm is building.
>
> i'm not 100% that line should be in there, at least i don't know off hand what
> it does. it was probably in the examples i based our spec files off of so i
> left it alone. what happens if you totally remove it?
>
> > I think there's something wrong with using brp-compress behind your back
> > when it changes filenames on you.  That's either a bug or my complete
> > ignorance.
>
> the next two lines are building up the filelist on the fly using the find
> command:
>
> find $RPM_BUILD_ROOT%{_prefix} -type f -print | \
>       sed "s ^$RPM_BUILD_ROOT@@g" > %{name}-%{version}-%{release}-filelist
>
> that should have the correct extensions reguardless of what then ended up
> being. (changed or not) it builds the list after brp-compress has been run.
> i'm not sure how that could end up with invalid file names. i think something
> bigger is going on here.
>
> -rm
> _______________________________________________
> gtk-perl-list mailing list
> gtk-perl-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-perl-list