[haikuports] Re: HaikuPorts build failure when on ramdisk?
- From: Adrien Destugues <pulkomandy@xxxxxxxxx>
- To: haikuports@xxxxxxxxxxxxx
- Date: Fri, 16 Jun 2017 13:36:40 +0200
2017-06-16 13:26 GMT+02:00 waddlesplash <waddlesplash@xxxxxxxxx>:
On Fri, Jun 16, 2017 at 1:20 AM, Adrien Destugues <pulkomandy@xxxxxxxxx>
wrote:
Sounds like the usual mess with libtool files:
- One devel packages comes with a .la file that references libiconv.la
(with absolute path)
- This devel package is used as a dependency for something else, but
the gettext package is not a dependency there or is a different
version
- As a result, the depended-on .la file is not found
Except this exact recipe builds just fine on my development VM, with
identical versions of all system packages, including gettext, which is
why I suspect it of being a problem caused by the ramdisk and
arfonzo's VM's slow disk access. (As further confirmation, kallisti5's
Mac Mini built glib2 just fine -- it doesn't use a ramdisk.)
It is not just system packages. If the packages built by the slave are left
in the "packages" directory, they can be used by haikuporter to build other
packages. The buildmaster is careful in checking this, it moves all the
packages to a package-cache folder, compute the dependencies on the master
(so system packages from the running slave are not used), and moves exactly
the required set of packages into the packages dir of the slave to run
haikuporter using these.
This ensures the builds are reasonably reproductible accross different
build slaves.
Is the kitchen doing something similar, or could it be that the build on
arfonzo machines picked some previously built packages as dependencies,
while tests on other machines didn't?
This is also part of the reason I ended up creating a release branch at
haikuports, to have a fixed set of packages to work against. Otherwise, you
always get changes and updates that break something, and never reach a
stable state. It seems Korli independently reached the same conclusion and
created his own branches, with a different policy of what to merge in.
This is why we have been reworking packages to delete the .la files
everywhere. On Haiku they are not needed (they are meant to work
around linker and runtime loader differences accross systems, but our
default behavior is the "makes sense" one so there's nothing special
to do). Just fix the recipes to remove the .la files. I think we could
even make that a policy warning in haikuporter.
It looks like glib2 is explicitly looking for the .la file though. I
wonder if we could change that? Or if this is just a symptom of a
larger problem that isn't going to go away if we fix it.
Use haikuporter -E on the machine that fails to get into the chroot. Grep
/system/lib and /system/develop/lib for references to that .la file. Check
that the .la actually exists in the chroot. Then we can investigate why it
is different on other machines.
--
Adrien Destugues / PulkoMandy
http://pulkomandy.tk
Other related posts:
