gjs @1.80.1: Undefined symbols for architecture x86_64: "std::__1::__libcpp_verbose_abort(char const*, ...)"

[christophecvr (christophecvr)]

The port gnome/gjs does not build an macbookpro macos 10.13.6 (high sierra) max on hardware. In works to update totem a port libhandy needs to be build and depends on the port gnome/gjs. This port fails to build. The real reason I could trace. It is a problem with libJPEG,libTIFF,libPng,libGIF i check done by macos which should not be done. To trace the problem I tried a direct build without using port using debug does not work as it always crashes the pc with any port. So I fetched the version of gjs wich the port is using 1.80.1 and the build with:

meson setup ./build --prefix=/opt/local -Dprofiler=disabled -Dskip_dbus_tests=true -Dskip_gtk_tests=true -Dbsymbolic_functions=false
cd build
ninja install

I have a more detailed error

dyld: Symbol not found: __cg_jpeg_resync_to_restart
  Referenced from: /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO
  Expected in: /opt/local/lib/libJPEG.dylib
 in /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO

Is there not a way to avoid that not needed check of JPEG done by ImageIO. This gjs is supposed to use the gnu jpeg versions out of /opt/local/lib . This checks needs the libJPEG.dylib build by mac wich is outdated. Yes work arounds can be made by deleting the link /opt/local/lib/libjpeg.dylib and replacing by a link to

/System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libJPEG.dylib

Repeat this for libPng libGIF libTIFF but then there will come other problems later on. The macos libJPEG is outdated and normally not needed at all for this gjs.

Included main log of port build gjs. log from build without the use of port.

[christophecvr (christophecvr)]

main log of port build port gnome/gjs

[christophecvr (christophecvr)]

Log of build gjs version without port. There we have the trace what is failing. That check is causing the x86_64 missing lib error.

[kencu (Ken)]

This is an issue that comes up in MacPorts every once in a while.

See this list, for example, where it has happened before:

​https://trac.macports.org/search?changeset=on&milestone=on&portsummarysearch=on&ticket=on&wiki=on&q=%2FSystem%2FLibrary%2FFrameworks%2FImageIO.framework%2FVersions%2FA%2FImageIO&page=1&noquickjump=1

essentially, the dyld library loader finds the newer libjpeg.dylib installed by MacPorts instead of the older libjpeg.dylib that ImageIO was originally built against.

The fix is always to find out why the library loader is being forced to look in /opt/local/lib when loading the libraries the system ImageIO is linked against. There is always some reason -- errant @rpath settings, DYLD_LIBRARY_PATH being set, something along those lines usually.

In this particular case, it might be -Wl,-rpath,/opt/local/lib that is forcing the dyld loader to look first in that location, and messing up the finding of the proper library. If that turns out to be the case, what to do about it is another question.

Some package mangers sequester all the headers and libraries away in subfolders to prevent this issue. It makes builds harder for everything else, though.

[christophecvr (christophecvr)]

Wath to do about is indeed the question I have . Yes like said the only solution I could think now is to remove the links libjpeg.dylib and libpng and libtiff and libgif . Replace with a link to the macos library's into /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources map. But the gjs needs actually the links to libjpeg gnu versions. The path here is actually right and must be /opt/local/lib . It is the fact that /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO check is for this build not needed at all and the function __cg_jpeg_resync_to_restart is also not needed at all. For the rest I tried so what playing around with DYLD_PATH ... but nothing works.

[kencu (Ken)]

can you show us what ImageIO is linked against?

Something like this should do it:

 % otool -L /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO

[christophecvr (christophecvr)]

I tried

% otool -L /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO

But answer is

-bash: fg: %: no such job

as test I did the work around by linking to macos libs from dir /opt/local/lib (I well saved first the original links so i can restore the defaults one) But the I just go further up to msg now from out libcups. Which I solved by building libcups from mac opensource but then with /opt/local/lib as path to link libs to I installed all in /opt/local and adapated the config.h off build to use /Library/Launchagents /Library/LaunchDeamons instead of /System/Library.. then it uses libcups which does not bug on -iconv during build. But again new issues arise now

dyld: Symbol not found: _gll_noop
  Referenced from: /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL
  Expected in: /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL
 in /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL

Looks that there is something very wrong with introspect and so.

[ryandesign (Ryan Carsten Schmidt)]

Ken intends % to represent the shell prompt; don't type it.

[ryandesign (Ryan Carsten Schmidt)]

Replying to christophecvr:

To trace the problem I tried a direct build without using port […]

meson setup ./build --prefix=/opt/local -Dprofiler=disabled -Dskip_dbus_tests=true -Dskip_gtk_tests=true -Dbsymbolic_functions=false
cd build
ninja install

I have a more detailed error

dyld: Symbol not found: __cg_jpeg_resync_to_restart
  Referenced from: /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO
  Expected in: /opt/local/lib/libJPEG.dylib
 in /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO

This must be happening because you set the DYLD_LIBRARY_PATH environment variable in your shell to include the value /opt/local/lib. Don't do that.

We're not here to debug problems that occur when you build software outside of MacPorts; we're here to debug problems building ports with MacPorts. And the reason why the port failed to build, per the log you attached, is:

:info:build Undefined symbols for architecture x86_64:
:info:build   "std::__1::__libcpp_verbose_abort(char const*, ...)", referenced from:
:info:build       std::__1::__hash_table<_GIArgument*, std::__1::hash<_GIArgument*>, std::__1::equal_to<_GIArgument*>, std::__1::allocator<_GIArgument*> >::erase(std::__1::__hash_const_iterator<std::__1::__hash_node<_GIArgument*, void*>*>) in libgjs-internal.a(gi_arg-cache.cpp.o)
:info:build       __ZNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEEC2B7v160006IDnEEPKc in libgjs-internal.a(gi_boxed.cpp.o)
:info:build       __ZNKSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEE16__get_short_sizeB7v160006Ev in libgjs-internal.a(gi_boxed.cpp.o)
:info:build       __ZNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEEC2B7v160006IDnEEPKc in libgjs-internal.a(gi_foreign.cpp.o)
:info:build       __ZNKSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEE16__get_short_sizeB7v160006Ev in libgjs-internal.a(gi_foreign.cpp.o)
:info:build       __ZNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEEC2B7v160006IDnEEPKc in libgjs-internal.a(gi_fundamental.cpp.o)
:info:build       __ZNKSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEE16__get_short_sizeB7v160006Ev in libgjs-internal.a(gi_fundamental.cpp.o)
:info:build       ...
:info:build ld: symbol(s) not found for architecture x86_64

Let's focus on that problem. We see the same problem on the buildbot on High Sierra.

[kencu (Ken)]

We've seen the verbose_abort problem many times... it happens because the compiler (clang-16 here it appears) is too new for the libc++.dylib being linked against.

Solution to that is to use an older compiler or a newer libc++.dylib.

If Ryan is correct and you have had DYLD_LIBRARY_PATH set as he mentioned in your shell -- well that is certainly your problem with that libjpeg.dylib issue, as I mentioned above.

[ryandesign (Ryan Carsten Schmidt)]

Replying to kencu:

We've seen the verbose_abort problem many times... it happens because the compiler (clang-16 here it appears) is too new for the libc++.dylib being linked against.

Then maybe MacPorts shouldn't pick such a new compiler on such old versions of macOS?

[Dave-Allured (Dave Allured)]

This port gjs was building correctly on 10.12 and 10.13 about 9 months ago, and on the previous supported gjs version 1.76.2. As the person who pushed the 1.80.1 update, I do not know what would have changed to cause this new error on 10.12 and 10.13. It is the same verbose_abort error on both builders, same as this ticket. This is offered as supplemental info, no reply needed.

@christophecvr, if you might be interested in downgrading to this previous version that was building correctly, I could show you how to do that. There is no guarantee that that version will now build in context of all the other Macports updates.

[kencu (Ken)]

Replying to ryandesign:

Then maybe MacPorts shouldn't pick such a new compiler on such old versions of macOS?

The compiler choice was rolled back for this exact reason here, but to prevent clang-17:

[b0d1ec350c471dd0e55cbd41cda16c20c1552cd0/macports-ports]

see: #68640

and there are details on llvm commits, etc, here:

​https://github.com/macports/macports-ports/pull/21051

according to what I saw months ago, clang-16 was OK with this issue. Perhaps something is different, or perhaps there are subtleties to consider (or perhaps I was incorrect, and clang-16 has always had this issue too, although that would be a bit odd that I thought it was OK back then).

[christophecvr (christophecvr)]

Replying to ryandesign: .

Yes the bug is filed for macports . Building outside macports was only a try to see if I could have more info to trace the problem. But now I did not set a DYLD_LIBRARY_PATH in bash.profile. and not use export DYLD_LIBRARY_PATH=... . The used lib paths are normally set via the autotools and or build tools such as macports self,or configure or meson or cmake or ... But quit possible that meson does set sometimes the wrong lib at wrong time. As info my bash.profile has only one export and that is :

export MANPATH="/opt/local/share/man:$MANPATH"

The paths are set in /private/etc/paths file . So the paths are by my then always (as user or sudo or sudo -i) the same. these are

/opt/local/bin:/opt/local/sbin:/usr/local/bin:/usr/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin

For the rest I kept all macos defaults sudo login bash is /bin/sh user login bash is /bin/bash. Just one little change in /private/etc/sudoers I added

Defaults	always_set_home

then excecuting a command with sudo like for example gedit will use /var/root as home dir for the caches and settings and so not make those settings unchangable in users home dir.

But I just had plenty of info further here to investigate and try to find real cause and solution. It maybe a upgrade somewhere wich is the cause. Even meson has had a upgrade not so long ago perhaps this may also trigger some wrongly set libs due to deprecated or not used parameters who does not fail the configure phase.

[christophecvr (christophecvr)]

extra log by a run with -v -d from fresh try building gjs. I self find nothing more which could be wrong but maybe somone else could.

[christophecvr (christophecvr)]

terminal out from run with -v -d . not much more then log self, but I could have missed something.

[christophecvr (christophecvr)]

Replying to Dave-Allured:

@christophecvr, if you might be interested in downgrading to this previous version that was building correctly, I could show you how to do that. There is no guarantee that that version will now build in context of all the other Macports updates.

Hallo, I just tried the previous version version 1.76.2 of 9 months ago (just used the port file on that date and the patchfiles). It first installed depends mozjs102 and then oeps downloaded a already build version. That installed fine. So I removed it again. Then rebuild gjs with -s option. It then also downloaded python 3.11 and build that python fully pfff installed it . But unfortunately the build of gjs failed with exact the same error. Looks to be something wrong with introspection. it does not seams to be gjs self. I will add the main log output here. Then can be seen it is almost same.

[christophecvr (christophecvr)]

old vesrion 1-76-2 off gjs also does not build anymore on macos 10.13.6 . Seems not to be the package self that has a fault.

[christophecvr (christophecvr)]

Replying to kencu:

can you show us what ImageIO is linked against?

Something like this should do it:

 % otool -L /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO

Sorry I forgot to give this answer. But this issue only happen when building with meson outside macports. So its just that I will need to do some changes if I wan't to build without the use of mac ports as test. Perhaps extra flag c and cxx and cpp flags to add and so what I always do when using configure and make but how to do with messon I need to find out.

The linking of /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO is :

macbookprocvr-2:~ christophe$ otool -L /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO
/System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO:
	/System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate (compatibility version 1.0.0, current version 4.0.0, weak)
	/System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics (compatibility version 64.0.0, current version 1161.21.5)
	/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 50.0.0, upward)
	/System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libJPEG.dylib (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libTIFF.dylib (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libPng.dylib (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libGIF.dylib (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libJP2.dylib (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libRadiance.dylib (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/libcompression.dylib (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
	/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
	/System/Library/PrivateFrameworks/AppleJPEG.framework/Versions/A/AppleJPEG (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1455.255.0)
	/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 822.37.0)
	/System/Library/Frameworks/IOSurface.framework/Versions/A/IOSurface (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1455.255.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.50.4)
	/System/Library/Frameworks/ColorSync.framework/Versions/A/ColorSync (compatibility version 1.0.0, current version 4.7.0)
macbookprocvr-2:~ christophe$

[christophecvr (christophecvr)]

Well as test I downgraded to CLANG 12 with llvm-11 and llvm-12 (they compilers were lucky avbl on uk build of macports). It does build. Just for test I temporary fouled the file /opt/mports/macports-ports/_resources/port1.0/compilers/clang_compilers.tcl

Modified lines 29,30 and 31 to :

    lappend compilers macports-clang-12 \
                      macports-clang-11 \
                      macports-clang-10

and it builds fine. I did it so since on 10.13.6 the macos xcode compiler is clang-10.

I will add the terminal output of build with -v log file is gone cause build and install succeeded. It used the clang-12 to build.

[christophecvr (christophecvr)]

gjs build on macos 10.13.6 with clang-12 build install ok

[kencu (Ken)]

OK, so looks like we can close this ticket.

Your libjpeg link error has nothing to do with macports after all.

The issues with verbose_abort are being tracked elsewhere. #68640

Good progress.

[christophecvr (christophecvr)]

Well the problem found. Yes it is just that macos 10.13.6 does not work ok with clang 16 . But it still needs to be solved in macport self. By adding a patch. Guess it will be to downgrade the compiler on macos 10.12.. and 10.13... only. But still do not know which is the highest possible version. And way to do. So I think the ticket should remained open till that is done.

[kencu (Ken)]

no need … the verbose_abort issue has nothing to do with gjs, we’ve known about it for 6 months, and is being tracked elsewhere. I will add a reference to your ticket there, though.

[christophecvr (christophecvr)]

Ok the gjs builds ok up to :

Project name: gjs
Project version: 1.80.1
C compiler for the host machine: /opt/local/bin/clang-mp-14 (clang 14.0.6 "clang version 14.0.6")
C linker for the host machine: /opt/local/bin/clang-mp-14 ld64 450.3
C++ compiler for the host machine: /opt/local/bin/clang++-mp-14 (clang 14.0.6 "clang version 14.0.6")
C++ linker for the host machine: /opt/local/bin/clang++-mp-14 ld64 450.3

But I gues now that I found my major problem why trying to upgrade some gnome packages beyond the versions used in macports is found. If I limited Clang to version 14 on my hardware wich is limited to max Macos 10.13.6 till the conflict clang versus C++ is found.

As from Clang 15 some build are failing.

[Dave-Allured (Dave Allured)]

has duplicate #69603

Ken, okay. I do not see how this helps the next guy to find out why gjs fails on their 10.13 system. I think either add gjs to #68640, or else leave this ticket open. Otherwise there is no ticket seen for 10.13 on the gjs port status page, which is where the casual users go to find out. Search trac history is too much for casual users. Do you have a better idea?

[christophecvr (christophecvr)]

Replying to Dave-Allured:

has duplicate #69603

Ken, okay. I do not see how this helps the next guy to find out why gjs fails on their 10.13 system. I think either add gjs to #68640, or else leave this ticket open. Otherwise there is no ticket seen for 10.13 on the gjs port status page, which is where the casual users go to find out. Search trac history is too much for casual users. Do you have a better idea?

I do agree with this comment. Since if other persons are building some ports on macos -10.12 or 13 and gjs is a depend will end up opening a ticket . I would leave it open so long a final solution has not been found with clang 15 and higher and c++ object linking on this os versions. As a temporary solution using clang14 or lower is ok.

[christophecvr (christophecvr)]

Replying to kencu:

no need … the verbose_abort issue has nothing to do with gjs, we’ve known about it for 6 months, and is being tracked elsewhere. I will add a reference to your ticket there, though.

I well need to say that in you're ticket #68640 They do speak about that problem comming from clang 17 and another port (package) . What we have here is the same error yes but it well is there as from clang 15 . This means that it might be something else . On top the ticket is 5 months old and still not solved. Perhaps it is better to set for Macos versions 10.13.6 and below in master develop mac ports a max clang version of 14 till the ticket You mentioned is solved. Perhaps then higher versions of clang than 14 will be also ok for this port gjs and ... Closing this ticket is a bit premature at this time and due to the different versions of clang as from when it starts it even could be something else.

[christophecvr (christophecvr)]

I now pushed the solution for this bug to my fork of macports-ports. Changed file is :

/opt/mports/macports-ports/_resources/port1.0/compilers/clang_compilers.tcl

This is the only way until maybe they find another fix to let run clang higher then 15 on macos 10.13.6 in ticket #68640

The changes can be find on my github : ​​https://github.com/christophecvr/macports-ports/commit/310a49be0f3d93a5f6919bcf78778fed95210f53

[christophecvr (christophecvr)]

This ticket was closed premature.The error maybe the same as on another ticket,but on macos 10.13.6 that other ticket is even not valid since the poppler package does build with clang 16 17 and ... So this ticket is for package gjs and others. There the temporary soluition is to limit clang to 14 why I don't .it just so.

[kencu (Ken)]

Replying to Dave-Allured:

has duplicate #69603

Ken, okay. I do not see how this helps the next guy to find out why gjs fails on their 10.13 system. I think either add gjs to #68640, or else leave this ticket open. Otherwise there is no ticket seen for 10.13 on the gjs port status page, which is where the casual users go to find out. Search trac history is too much for casual users. Do you have a better idea?

sure, add gjs to the other ticket.

there will be many more build failures, as this issue relates to how the compiler is interacting with the system libc++.dylib on various systems, and possibly other issues like the c++ standard being used, whether exceptions are in use, etc.

IMO this should all be tracked in 1 ticket, but hey, if you want 1,000 tickets about this issue be my guest.

[christophecvr (christophecvr)]

Replying to kencu:

Replying to Dave-Allured:

has duplicate #69603

Ken, okay. I do not see how this helps the next guy to find out why gjs fails on their 10.13 system. I think either add gjs to #68640, or else leave this ticket open. Otherwise there is no ticket seen for 10.13 on the gjs port status page, which is where the casual users go to find out. Search trac history is too much for casual users. Do you have a better idea?

sure, add gjs to the other ticket.

there will be many more build failures, as this issue relates to how the compiler is interacting with the system libc++.dylib on various systems, and possibly other issues like the c++ standard being used, whether exceptions are in use, etc.

IMO this should all be tracked in 1 ticket, but hey, if you want 1,000 tickets about this issue be my guest.

Yes but this ticket apart of the error is really different. It might be the same source at the end. But in practice : first the other ticket is not valid on macos-10.13.6 but looks the be a macos 10.12 issue. It was also with clang 17. This problem here occurs with clang 16 and also clang 15 . Is not there with clang 14. So leave it open then normally there will be no new ticket for this issue. Persons can see what to do to solve the problem temporarily until definitive fix have been found. But I'm afk that the real cause is really the fact that apple does not take care anymore of older os the 14+ in clang development and therefore is the use of higher clang versions very hazardous(unstable) on not supported os versions. A solution can be in the macports is making more use of gnu compiler C and g++ if needed for some features in gnu software packages.

[kencu (Ken)]

No, we certainly won't be using gcc for more builds.

For all these problems (with all the different builds that have shown it in #68640 so far, and all the ones to come), the solution is to always use an older clang compiler.

There is nothing special about gjs.

[kencu (Ken)]

So let's close this ticket again, and track this where it belongs, in #68640.

And might as well add any (and all) future similar failures with verbose_abort() there too.

[Dave-Allured (Dave Allured)]

Agreed, close this ticket, now that gjs is added to #68640.