[pacman-dev] [PATCH] Introduce destarch keyword into makepkg
thomas at archlinux.org
Wed Jul 2 12:20:32 EDT 2008
Allan McRae schrieb:
> Just getting an indication of how common this is. The multilib stuff in
> [community] all takes the i686 package as the source and just moves the
> files to the new locations. Is there some reason that you cannot use
> that approach. Wouldn't all packages you are wanting to make a multilib
> package for have an i686 package floating about. Also, with that
> approach you can actually make the package on the target architecture.
The approach taken in community doesn't work very well, as putting a
library package into a different path poses problems. Just one example:
glibc has the path /usr/lib/gconv hardcoded, now we load the 32 bit
glibc on a 64 bit system and it tries to load the modules from
/usr/lib/gconv, all of which are 64 bit binaries, thus incompatible.
Similar problems exist for alsa-lib, pango, gtk and maybe others. In the
community/AUR packages, these are worked around by environment variables
where possible, but in most cases they are just being ignored.
Thus I started to look into rebuilding all packages required on a 32 bit
system, adjusting the paths correctly and stripping all unnecessary
files. This is supposed to be a _clean_ and slim 32 bit runtime without
a build environment. Right now I got enough libraries to make
nspluginwrapper (built from source!) and flashplugin work.
My goal for now is to get nspluginwrapper+flash and wine to work on a 64
bit archlinux system. Maybe later I want to add all libraries necessary
to install and run Google Earth.
This task motivated the destarch=, STRIP_DIRS and rundepends suggestions
I posted: In my PKGBUILDs, I would then use
to "cross-compile" the packages on my full arch32 system. I hope this
clarifies my wishes.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 260 bytes
Desc: OpenPGP digital signature
More information about the pacman-dev