Building a Fedora package
Steven Pritchard
pugs off and on for the last couple of weeks. I have something that
works fine on i386, but on x86_64 there are two issues.
First, there is a hardcoded "lib" somewhere that I can't seem to find.
On x86_64, libraries should get dropped in /usr/lib64, but "make
install" never creates /usr/lib64/parrot. Pointers on how to override
that would be greatly appreciated.
I have a lot of cruft in the current version of the spec from where I
was trying to fix that problem. I'm sure most of it is bogus, so try
to ignore it if you look at this... :-)
http://ftp.kspei.com/pub/steve/rpms/parrot/parrot.spec
Second, ICU detection fails. (I haven't had time to look into this
yet.)
Thanks in advance for any help...
Steve
--
Steven Pritchard - K&S Pritchard Enterprises, Inc.
Email: st...@kspei.com http://www.kspei.com/
Phone: (618)398-3000 Mobile: (618)567-7320
Joshua Hoblitt
> First, there is a hardcoded "lib" somewhere that I can't seem to find.
> On x86_64, libraries should get dropped in /usr/lib64, but "make
> install" never creates /usr/lib64/parrot. Pointers on how to override
> that would be greatly appreciated.
When you say, "On x86_64" I think what your really mean is a "x86_64
system with multilib support". You are correct that the current build
system does not support multilib builds or installs (or at least it
didn't the last time I looked at it several months ago).
While I don't have a recent Fedora build to look at I'd bet that
/usr/lib64 on your system is actually a link to /usr/lib while
/usr/lib32 is a separate directory. So there shouldn't be any issue
with installing under /usr/lib. Is this the case?
Cheers,
-J
--
Steven Pritchard
> When you say, "On x86_64" I think what your really mean is a "x86_64
> system with multilib support".
Right.
> You are correct that the current build system does not support
> multilib builds or installs (or at least it didn't the last time I
> looked at it several months ago).
Which is fine, if I could just override "lib". It sort of works
now... The libraries get installed in /usr/lib64, but /usr/lib/parrot
is also created, which wouldn't be a big deal if it was
arch-independent stuff (although then technically it should be
/usr/share/parrot), but /usr/lib/parrot/dynext has arch-dependent
files...
> While I don't have a recent Fedora build to look at I'd bet that
> /usr/lib64 on your system is actually a link to /usr/lib while
> /usr/lib32 is a separate directory. So there shouldn't be any issue
> with installing under /usr/lib. Is this the case?
No. i386 packages have exclusive use of lib. All x86_64 packages
install in lib64.
In an ideal world, the layout that would be best for a multilib Linux
system would probably be something like this:
/usr/lib64/libparrot.*
/usr/lib64/pkgconfig/
/usr/lib64/parrot/dynext/
/usr/share/parrot/include/
/usr/share/parrot/library/
/usr/include/parrot/
/usr/bin/*
What I have now is this:
/usr/lib64/libparrot.*
/usr/lib64/pkgconfig/
/usr/lib/parrot/dynext/
/usr/lib/parrot/include/
/usr/lib/parrot/library/
/usr/include/parrot/
/usr/bin/*
That's after overriding lib_dir...
Steven Pritchard
OK, I finally found the (last, I hope) problem. In
tools/dev/install_files.pl, there is this line:
$dest =~ s/^runtime/lib/;
I may have gone overboard a bit, but here's what I ended up doing:
%{__perl} -pi -e 's,"/lib","/%{_lib}", if (/^\s*lib_dir\s*=>/)' \
config/init/defaults.pm
%{__perl} -pi -e 's,"lib/,"%{_lib}/, if %(/CONST_STRING\(interpreter,/)' \
src/library.c
%{__perl} -pi -e "s,'/usr/lib','%{_libdir}',;s,runtime/lib/,runtime/%{_lib}/," \
tools/dev/install_files.pl \
tools/dev/mk_manifests.pl
In the spec file, %{_lib} will expand to "lib64" on x86_64, otherwise
it's just "lib". (In other words, this is all wasted effort on i386.)
It seems to me that having "lib" hard-coded in src/library.c and
tools/dev/install_files.pl at the very least would be a bug. Should I
put a ticket in RT for this?
> Second, ICU detection fails. (I haven't had time to look into this
> yet.)
I still haven't looked at this... Note that this is only on x86_64.
On i386, it works fine.
Oh, the one other issue I had worth mentioning was that the readline
test in Configure.pl failed unless I specified --libs=-lcurses. I'm
not who is to blame for that though... (This was on i386 and
presumably on x86_64 as well.)
Joshua Hoblitt
# Please include the string: [perl #39860]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=39860 >
LIB_DIR gets setup as part of the configure process which is then passed
to the install script as --libdir=$(LIB_DIR). The solution is to make
Configure.pl more autotools like in that it can accept --libdir,
--datadir, etc.
-J
--
Joshua Hoblitt
> # New Ticket Created by Joshua Hoblitt
> # Please include the string: [perl #39860]
> # in the subject line of all future correspondence about this issue.
> # <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=39860 >
>
>
> LIB_DIR gets setup as part of the configure process which is then passed
> to the install script as --libdir=$(LIB_DIR). The solution is to make
> Configure.pl more autotools like in that it can accept --libdir,
> --datadir, etc.
>
> -J
>
> --
Attached is a patch to implement autoconf compatible installation path
options. Keep in mind that this more or less just implements the
options. While all option values are stored in Parrot::Config only a
few of the values are currently used in the build process (prefix,
libdir, etc.). I'd like to get back several reports that this patch
works OK for people and actually resolves their installation issues
before applying it (please, nobody get trigger happy). I suspect
changes to root.in and the install script will be necessary to make
everyone happy. The new options will also need to be documented in
Configure.pl
Cheers,
-J
--
James Keenan via RT
r14047 | jhoblitt | 2006-08-12 15:36:03 -0400 (Sat, 12 Aug 2006) | 2 lines
bug #39860 - autoconf compatible install options
Resolving ticket.