poppler fails build

[tjahns (Thomas)]

When building an updated poppler that fails with a failure to link libgio. See attached log for details.

From what I could find about this error message, it appears there's some -Wl,-rpath argument missing.

$ sudo port upgrade outdated
--->  Computing dependencies for poppler
--->  Fetching archive for poppler
--->  Attempting to fetch poppler-23.02.0_0+boost.darwin_18.x86_64.tbz2 from http://packages.macports.org/poppler
--->  Attempting to fetch poppler-23.02.0_0+boost.darwin_18.x86_64.tbz2 from http://fra.de.packages.macports.org/poppler
--->  Attempting to fetch poppler-23.02.0_0+boost.darwin_18.x86_64.tbz2 from http://nue.de.packages.macports.org/poppler
--->  Fetching distfiles for poppler
--->  Verifying checksums for poppler
--->  Extracting poppler
--->  Applying patches to poppler
--->  Configuring poppler
--->  Building poppler                                   
Error: Failed to build poppler: command execution failed 
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_graphics_poppler/poppler/main.log for details.
Error: Follow https://guide.macports.org/#project.tickets if you believe there is a bug.

[tjahns (Thomas)]

Copy of detailed log file

[ryandesign (Ryan Carsten Schmidt)]

Log says:

g-ir-scanner: link: /usr/bin/clang -o /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_graphics_poppler/poppler/work/build/glib/tmp-introspect0h9jzeji/Poppler-0.18 -Os -pipe -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk -arch x86_64 /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_graphics_poppler/poppler/work/build/glib/tmp-introspect0h9jzeji/Poppler-0.18.o -L. -Wl,-rpath,. -L/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_graphics_poppler/poppler/work/build -Wl,-rpath,/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_graphics_poppler/poppler/work/build -L/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_graphics_poppler/poppler/work/build/glib -Wl,-rpath,/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_graphics_poppler/poppler/work/build/glib -lpoppler-glib -lpoppler -lgio-2.0 -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lintl -L/opt/local/libexec/boost/1.76/lib -Wl,-headerpad_max_install_names -liconv -Wl,-syslibroot,/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk -arch x86_64
dyld: Library not loaded: @rpath/libgio-2.0.0.dylib
  Referenced from: /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_graphics_poppler/poppler/work/build/glib/tmp-introspect0h9jzeji/Poppler-0.18
  Reason: image not found

This looks like #63592 again. Can you please show the output of:

port -v installed name:^glib2

and:

otool -L /opt/local/lib/libgio-2.0.0.dylib

[tjahns (Thomas)]

Thank you for looking into this. I can, here's the output:

$ port -v installed name:^glib2
The following ports are currently installed:
  glib2 @2.70.5_0+quartz (active) requested_variants='+quartz' platform='darwin 18' archs='x86_64' date='2022-11-17T20:41:36+0100'
$ otool -L /opt/local/lib/libgio-2.0.0.dylib
/opt/local/lib/libgio-2.0.0.dylib:
	@rpath/libgio-2.0.0.dylib (compatibility version 7001.0.0, current version 7001.5.0)
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1575.17.0)
	/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1575.17.0)
	/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 1671.60.107)
	/usr/lib/libresolv.9.dylib (compatibility version 1.0.0, current version 1.0.0)
	@rpath/libglib-2.0.0.dylib (compatibility version 7001.0.0, current version 7001.5.0)
	@rpath/libgobject-2.0.0.dylib (compatibility version 7001.0.0, current version 7001.5.0)
	@rpath/libgmodule-2.0.0.dylib (compatibility version 7001.0.0, current version 7001.5.0)
	/opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.13)
	/opt/local/lib/libintl.8.dylib (compatibility version 11.0.0, current version 11.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.250.1)
	/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 946.0.0)
	/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)

[tjahns (Thomas)]

I did the following, and now the output no longer has @rpath entries:

$  sudo port install glib2
Password:
--->  Computing dependencies for glib2
--->  Fetching archive for glib2
--->  Attempting to fetch glib2-2.70.5_0+x11.darwin_18.x86_64.tbz2 from http://packages.macports.org/glib2
--->  Attempting to fetch glib2-2.70.5_0+x11.darwin_18.x86_64.tbz2.rmd160 from http://packages.macports.org/glib2
--->  Installing glib2 @2.70.5_0+x11
--->  Deactivating glib2 @2.70.5_0+quartz
--->  Cleaning glib2
--->  Activating glib2 @2.70.5_0+x11
--->  Cleaning glib2
--->  Scanning binaries for linking errors
--->  No broken files found.
--->  No broken ports found.

[tjahns (Thomas)]

And now the following seems to produce the desired install:

$ sudo port install texlive-bin
--->  Computing dependencies for texlive-bin
The following dependencies will be installed:  poppler
Continue? [Y/n]: y
--->  Fetching archive for poppler
--->  Attempting to fetch poppler-23.02.0_0+boost.darwin_18.x86_64.tbz2 from http://packages.macports.org/poppler
--->  Attempting to fetch poppler-23.02.0_0+boost.darwin_18.x86_64.tbz2.rmd160 from http://packages.macports.org/poppler
--->  Installing poppler @23.02.0_0+boost
--->  Activating poppler @23.02.0_0+boost
--->  Cleaning poppler
--->  Cleaning texlive-bin
--->  Scanning binaries for linking errors
--->  No broken files found.
--->  No broken ports found.

Thank you for giving me the right directions, Ryan.

[ryandesign (Ryan Carsten Schmidt)]

Ok, but now you've replaced your +quartz glib2 with +x11 which may not be what you want. All* installed ports that have +x11 and +quartz variants must use the same one. Do you use +x11 or +quartz with your other ports? Take a look at the output of:

port -v installed | grep -E '\+(quartz|x11)'

(*There are some exceptions. cairo, cairomm, pango, and pangomm can use both +quartz and +x11 at the same time, and which variant you select for the tk port, if you have it installed, needn't match the others.)

[tjahns (Thomas)]

Good point, I have no idea why glib2 was installed in a quartz version, I think it's only for something from texlive, so probably I got asked once upon a time which version to choose and quartz seemed more sensible? Anyhow that's the current status, looks consistent to me:

 port -v installed | grep -E '\+(quartz|x11)'
  cairo @1.17.4_0+quartz+x11 requested_variants='+quartz+x11' platform='darwin 18' archs='x86_64' date='2022-11-17T20:44:15+0100'
  cairo @1.17.6_0+quartz+x11 (active) requested_variants='+quartz+x11' platform='darwin 18' archs='x86_64' date='2023-02-18T01:06:16+0100'
  gd2 @2.3.3_2+x11 (active) requested_variants='+x11' platform='darwin 18' archs='x86_64' date='2023-02-01T09:20:25+0100'
  ghostscript @9.56.1_1+x11 (active) requested_variants='+x11' platform='darwin 18' archs='x86_64' date='2023-02-01T09:25:52+0100'
  giflib @4.2.3_0+x11 (active) requested_variants='+x11' platform='darwin 18' archs='x86_64' date='2018-11-07T23:05:44+0100'
  glib2 @2.70.5_0+quartz requested_variants='+quartz' platform='darwin 18' archs='x86_64' date='2022-11-17T20:41:36+0100'
  glib2 @2.70.5_0+x11 (active) requested_variants='' platform='darwin 18' archs='x86_64' date='2023-03-01T22:40:05+0100'
  graphviz @7.1.0_0+pangocairo+x11 (active) requested_variants='+pangocairo+x11' platform='darwin 18' archs='x86_64' date='2023-02-01T09:23:22+0100'
  ImageMagick @6.9.11-60_5+x11 (active) requested_variants='' platform='darwin 18' archs='x86_64' date='2023-02-01T09:29:57+0100'
  pango @1.50.7_0+quartz+x11 (active) requested_variants='+quartz+x11' platform='darwin 18' archs='x86_64' date='2022-11-17T20:56:15+0100'
  texlive-bin @2022.62882_2+x11 (active) requested_variants='+x11' platform='darwin 18' archs='x86_64' date='2022-11-17T20:52:15+0100'

[tjahns (Thomas)]

If removing glib2 again and reinstalling in a form that preserves detailed logs is something useful to you, I'd be happy to help.

[ryandesign (Ryan Carsten Schmidt)]

MacPorts uses +x11 by default (as you saw when you reinstalled glib2 just now) and doesn't prompt you whether you would like +quartz instead; it something you would have had to request explicitly.

But it looks like you don't have any other active ports with just +quartz so having reinstalled glib2 +x11 your ports should now be in a consistent state.

I just tried building glib2 +quartz on my Monterey Mac and did not end up with any @rpath install names, so I think there is something else that we have yet to discover that is causing @rpath install names when you build the port. (When you reinstalled glib2 just now, you didn't build it; you received a binary that we built on our server.)

I would be very interested to see whether rebuilding glib2 +x11 on your system results in @rpath install names again. To do that you could run:

sudo port -nsk upgrade --force glib2 build.jobs=1

--force means rebuild even though the port is not outdated; -n means only rebuild this port, not its dependencies; -s means build from source, don't try to download a binary; -k means keep the log and work directory after a successful build; build.jobs=1 means don't build in parallel, which will make the build take a long time but will make it easier to compare your log with other logs.

If you see @rpath install names for glib2 libraries with otool -L after that, please attach the main.log file (whose location is printed by the command port logfile glib2). Then you can delete the log and work directory with sudo port clean glib2.

If you got @rpath install names, you can get back to non-@rpath install names by getting our binary again, with sudo port -nb upgrade --force glib2. (-b means get a binary, don't build from source.)

[tjahns (Thomas)]

Okay, happening right now, but because of build deps, it might take a while (and also the updated meson perhaps means the results won't be the same?):

 sudo port -nsk upgrade --force glib2 build.jobs=1
Password:
--->  Computing dependencies for glib2
The following dependencies will be installed: 
 bison
 bison-runtime
 meson
 ninja
 py-bootstrap-modules
 py311-build
 py311-installer
 py311-packaging
 py311-pep517
 py311-setuptools
 py311-wheel
 python311
 re2c
Continue? [Y/n]: 
--->  Fetching distfiles for python311
--->  Attempting to fetch Python-3.11.2.tar.xz from https://www.python.org/ftp/python/3.11.2/
--->  Verifying checksums for python311
--->  Extracting python311
--->  Applying patches to python311
--->  Configuring python311
Warning: Configuration logfiles contain indications of -Wimplicit-function-declaration; check that features were not accidentally disabled:
  dbm_open: found in Python-3.11.2/config.log
--->  Building python311
      [  •   •   •   •   •   •   •   •   •   •   •   • ]

[ryandesign (Ryan Carsten Schmidt)]

Oh. Building all those deps from source will take extra time. It's fine to let it run, or you could interrupt the build, clean whichever port was building when you interrupted it, then install those deps manually first, letting MacPorts get binaries for them:

sudo port install --unrequested bison bison-runtime meson ninja py-bootstrap-modules py311-build py311-installer py311-packaging py311-pep517 py311-setuptools py311-wheel python311 re2c

The -k flag would also apply to those deps so you'll want to remove their logs and work directories later with:

sudo port clean bison bison-runtime meson ninja py-bootstrap-modules py311-build py311-installer py311-packaging py311-pep517 py311-setuptools py311-wheel python311 re2c

[tjahns (Thomas)]

Yep, this worked out: no @rpath to be seen in otool output. I guess things will remain a little mysterious for a while.

[ryandesign (Ryan Carsten Schmidt)]

Thanks for testing. If anyone ever figures out why meson apparently sometimes installs libraries with @rpath in the install_name, please comment here.