Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#61203 closed defect (wontfix)

gtk3 @3.24.23_0: Can't update because of broken llvm

Reported by: rubendibattista (Ruben Di Battista) Owned by:
Priority: Normal Milestone:
Component: ports Version:
Keywords: Cc: dbevans (David B. Evans), cooljeanius (Eric Gallager)
Port: gtk3

Description

It has been a bit since I did a selfupdate. But now I cannot build gtk3 because of broken llvm (that is not listed as dependency in the Portfile).

Attachments (1)

gtk3.log.gz (19.3 KB) - added by rubendibattista (Ruben Di Battista) 4 years ago.
build log

Download all attachments as: .zip

Change History (21)

Changed 4 years ago by rubendibattista (Ruben Di Battista)

Attachment: gtk3.log.gz added

build log

comment:1 Changed 4 years ago by kencu (Ken)

I saw something like this too, when I was updating one of my systems ... there is something to be tweaked in the way MacPorts' calculates the order of dependencies to be upgraded, you're right. I found it easy enough to fix -- just update llvm-8.0 (in your case) first, and then you should be good to go again.

:info:build libtool: link: /usr/bin/clang -arch x86_64 -o /opt/local/var/macports/build/_Users_rubendibattista_git_macports-ports_gnome_gtk3/gtk3/work/gtk+-3.24.23/gdk/tmp-introspectr_sd7yds/.libs/Gdk-3.0 -I/opt/local/include -DX_LOCALE -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk -pipe -Os -fstrict-aliasing -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk -arch x86_64 -Wall /opt/local/var/macports/build/_Users_rubendibattista_git_macports-ports_gnome_gtk3/gtk3/work/gtk+-3.24.23/gdk/tmp-introspectr_sd7yds/Gdk-3.0.o -Wl,-framework -Wl,CoreFoundation -Wl,-headerpad_max_install_names -Wl,-syslibroot -Wl,/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk -arch x86_64  -L. ./.libs/libgdk-3.dylib -L/opt/local/lib -lpangocairo-1.0 -lpango-1.0 -lgdk_pixbuf-2.0 -lcairo-gobject -lcairo -lepoxy -lfribidi -lm -lgio-2.0 -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lintl
:info:build dyld: Library not loaded: /opt/local/lib/libffi.6.dylib
:info:build   Referenced from: /opt/local/libexec/llvm-8.0/lib/libLLVM.dylib
:info:build   Reason: image not found
:info:build fatal error: otool: fatal error in /opt/local/bin/llvm-objdump-mp-8.0

so :

sudo port -v upgrade llvm-8.0

and when that is done, DON'T allow rev-upgrade to rebuild anything broken.

Then go ahead with

sudo port -v upgrade outdated
Last edited 4 years ago by kencu (Ken) (previous) (diff)

comment:2 Changed 4 years ago by rubendibattista (Ruben Di Battista)

Thanks @kencu. That's exactly what I did, but I think this is a bug nonetheless, Macports should build llvm before gtk3, shouldn't it?

comment:3 Changed 4 years ago by kencu (Ken)

Something needs to be tweaked, yes. You're on Catalina -- why is llvm-objdump-mp-8.0 being called, exactly, instead of your xcode one?

Is that coming from ld64? On your system, it should be installed with the +xcode variant...so not sure why it would be called.

comment:4 Changed 4 years ago by rubendibattista (Ruben Di Battista)

I have no idea. Dunno if related, but every now and then I get the warning about the Xcode versions not recognized by Macports and I need to reinstall the Command Line Tools. Could it be related?

ld64 @3_3+ld64_xcode (active)

is indeed installed with the ld64_xcode variant.

comment:5 Changed 4 years ago by kencu (Ken)

by any chance, could you have done this at some point: sudo port select llvm mp-llvm-8.0?

comment:6 Changed 4 years ago by rubendibattista (Ruben Di Battista)

$> sudo port select --list llvm
Available versions for llvm:
	mp-llvm-8.0
	mp-llvm-9.0
	none (active)

Not that I remember...

Last edited 4 years ago by ryandesign (Ryan Carsten Schmidt) (previous) (diff)

comment:7 Changed 4 years ago by kencu (Ken)

OK. I see this at one point in your log:

:info:configure checking for objdump... objdump

and then later, when libtool goes to use it, it is this:

:info:build fatal error: otool: fatal error in /opt/local/bin/llvm-objdump-mp-8.0

which it probably shouldn't be, but that is what brings in the error somehow...

gtk3 should not be listing a dep on llvm-8.0, that much is for sure... but what should be listing a dep for what is less clear to me...

comment:8 Changed 4 years ago by kencu (Ken)

I bet it is gir-scanner -- it does lots of funky business:

:info:build g-ir-scanner: link: /bin/sh ../libtool --mode=link --tag=CC /usr/bin/clang -arch x86_64 -o /opt/local/var/macports/build/_Users_rubendibattista_git_macports-ports_gnome_gtk3/gtk3/work/gtk+-3.24.23/gdk/tmp-introspectbhhu8fe9/Gdk-3.0 -export-dynamic -I/opt/local/include -DX_LOCALE -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk -pipe -Os -fstrict-aliasing -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk -arch x86_64 -Wall /opt/local/var/macports/build/_Users_rubendibattista_git_macports-ports_gnome_gtk3/gtk3/work/gtk+-3.24.23/gdk/tmp-introspectbhhu8fe9/Gdk-3.0.o -L. libgdk-3.la -L/opt/local/lib -lgio-2.0 -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lintl -Wl,-framework -Wl,CoreFoundation -L/opt/local/lib -Wl,-headerpad_max_install_names -Wl,-syslibroot,/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk -arch x86_64

comment:9 Changed 4 years ago by kencu (Ken)

it is gir-scanner, as the tail of your log shows.

Do you have your cctools installed with +xcode variant as well?

If your cctools is installed with llvm80 variant, at least we have a clue there.

comment:10 Changed 4 years ago by kencu (Ken)

I think it must be cctools. We install it with an llvmXY variant, and it gets used (opportunistically I think) by gir-scanner, but it is broken in those rare situations where we do something like upgrading libffi, which breaks all the llvms.

nothing in gtk3 declares a dep on cctools, so then nothing declares a dep on llvmXY, so therefore the build breaks.

comment:11 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)

Keywords: gtk3 llvm build removed
Resolution: wontfix
Status: newclosed

Such problems exist from time to time, but I can't suggest a good way that we could prevent it.

We offer newer versions of Apple's toolchain in the cctools port. If you have it installed, many ports will opportunistically use the programs it provides. If they're broken in some way, for example because one of their dependencies like libffi was updated and you haven't updated cctools yet, then that will cause those many other ports to fail to build. We do not want to "fix" it by adding a cctools dependency to those many ports, because that would normally be unnecessary; those ports would build fine with Xcode's copy of those tools.

So when you encounter these kinds of problems you have to do a little investigation and fix it yourself. For example, when you see:

dyld: Library not loaded: /opt/local/lib/libffi.6.dylib
  Referenced from: /opt/local/libexec/llvm-8.0/lib/libLLVM.dylib
  Reason: image not found

use port provides /opt/local/libexec/llvm-8.0/lib/libLLVM.dylib to figure out what port provides it, check if it's outdated, and if so, upgrade it. Then try again.

comment:12 Changed 4 years ago by rubendibattista (Ruben Di Battista)

Can't the dependency be conditionally imposed on those ports being already installed?

comment:13 Changed 4 years ago by kencu (Ken)

So to do that, any port that uses gobject-introspection would need to see if cctools is installed, and if it is installed, add a dependency on it. That will not be a very popular thing to do, as it makes the dependency chain random. Technically, though, that's trivially easy to do.

But if that was accepted, if I understand how that works, that would force cctools (and it's dependency on some LLVM version) to update itself before the port using gir-scanner.

I think pretty much all these ports are using the gobject-introspection portgroup, so the place to put the code is already there.

comment:14 Changed 4 years ago by rubendibattista (Ruben Di Battista)

Why do you say "random dependency chain"? Wouldn't it be double branched, but still deterministic?

comment:15 Changed 4 years ago by kencu (Ken)

That's the argument that will come up.

On any given system, there will, or won't, be a dep added on cctools that is non-deterministic from the point of view of the Portfile.

comment:16 Changed 4 years ago by kencu (Ken)

that would force cctools (and it's dependency on some LLVM version) to update itself

well -- actually -- would it?

Even if you added a dep on cctools to the port using gir-scanner, the test would show that cctools is installed and up-to-date.

Would that somehow trigger to the port dep mechanism that the llvm cctools is using needs to have it's upgrade done first? Maybe it would. I'm not 100% sure.

Last edited 4 years ago by kencu (Ken) (previous) (diff)

comment:17 in reply to:  13 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)

Replying to kencu:

I think pretty much all these ports are using the gobject-introspection portgroup, so the place to put the code is already there.

Dave has been undoing this lately because #60644 has not been implemented, so it will be some work to re-do this to all the ports where it has been undone.

comment:18 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)

The challenge of ports opportunistically using components from cctools is not limited to those that use gobject-introspection, and for that matter also includes ports that opportunistically use gawk, gsed, grep, and gmake.

comment:19 Changed 4 years ago by rubendibattista (Ruben Di Battista)

Ryan, what should be done to account for this in the most complete way then? At least with your vision? Such that I could try to do it...

comment:20 Changed 4 years ago by cooljeanius (Eric Gallager)

Cc: cooljeanius added
Note: See TracTickets for help on using tickets.