Bug 2003326

Summary: build failures in latest stable 1.44.2
Product: [Community] Virtualization Tools Reporter: Toolybird <toolybird>
Component: libguestfsAssignee: Richard W.M. Jones <rjones>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: lersek, mhicks, ptoscano
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-09-13 07:54:54 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
build fix none

Description Toolybird 2021-09-11 06:05:00 UTC 
Latest libguestfs stable release has at least 2 unrelated build problems. I'm building this in a clean chroot on current Arch Linux as per usual.

The first issue relates to pcre2:

make[3]: Entering directory '/build/libguestfs/src/libguestfs-1.44.2/daemon'
  CCLD     guestfsd
/usr/bin/ld: ../common/mlpcre/libmlpcre.a(libmlpcre_a-pcre-c.o): undefined reference to symbol 'pthread_key_delete@@GLIBC_2.2.5'
/usr/bin/ld: /usr/lib/libpthread.so.0: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile:2855: guestfsd] Error 1

It appears to be missing `-lpthread' on the link line. If I hack that into the Makefile then the build proceeds.

Note that Arch is still on glibc-2.33 and I believe glibc-2.34 introduced some changes in this area which may explain why you don't see the problem.


The next issue appears like so:

Making all in common/mlprogress
make[2]: Entering directory '/build/libguestfs/src/libguestfs-1.44.2/common/mlprogress'
  OCAMLCMI progress.cmi
ocamlfind: Package `guestfs' not found
make[2]: *** [Makefile:2358: progress.cmi] Error 2

This one is due to latest `libguestfs-common' being incompatible with 1.44. In 1.45 the tools were split out, but this hasn't yet happened on 1.44, hence the fail. Offending commit:

https://github.com/libguestfs/libguestfs-common/commit/c74f9cb112d22ad981891ba4932005625f320db2

Undoing that one lets the build get further but then more pcre2 failures occur due to more missing `-lpthread' on link lines...
Comment 1 Richard W.M. Jones 2021-09-11 06:14:25 UTC 
Right, glibc 2.34 no longer requires -lpthread so this
issue is only going to get worse over time (with everything).
I upgraded to glibc 2.34 everywhere now.

Are you building from the tarball or git?  If git, did you
"git submodule update"?
Comment 2 Toolybird 2021-09-11 07:35:32 UTC 
> Are you building from the tarball or git?

Tarball.

> I upgraded to glibc 2.34 everywhere now.

Are you able to spin up a container with glibc-2.33? I'm afraid my hacks won't cut the mustard.
Comment 3 Richard W.M. Jones 2021-09-11 08:47:48 UTC 
Please try these commits on top of 1.44.2:

https://github.com/libguestfs/libguestfs/commit/e26cfa445a1947503a03c55d8d65263530747062
https://github.com/libguestfs/libguestfs/commit/489b14b75e5f30010d8a8c8d3a10ecc52b629563
https://github.com/libguestfs/libguestfs/commit/68a02c2f6c7b4243ecb298c0d9539f0fc51a52ce
Comment 4 Toolybird 2021-09-11 22:06:22 UTC 
Created attachment 1822412 [details]
build fix
Comment 5 Toolybird 2021-09-11 22:06:59 UTC 
(sorry for the late response - in a different timezone)

> Please try these commits on top of 1.44.2:

Still not quite there yet..

The first and third patches definitely solve the "-pthread" issues. The second patch seems to be solving a problem I'm not seeing.

To make a successful build I had to apply the attached patch to the common submodule files.

Thanks for the quick response! Cheers.
Comment 6 Richard W.M. Jones 2021-09-13 07:54:54 UTC 
I guess it's to do with splitting out guestfs-tools from
libguestfs.  If I uninstall libguestfs then the build
failure is reproducible.  However we can't apply that patch
to the common module since it would break upstream builds,
so I suggest carrying that patch downstream.

As this is now fixed as far as possible, I'm closing the bug.