gobject-introspection @1.60.2_4 : g-ir-scanner producing executable with linking problems

[serge-cohen (Serge Cohen)]

I am currently working to compile a project using gobject introspection (ufo : ​https://github.com/ufo-kit/ufo-core.git).

This package uses gobject introspection for its python interface. In the build process g-ir-scanner is runned on the source to extract API information but fails with message :

[ 74%] Generating Ufo-1.0.gir
dyld: Symbol not found: _iconv
  Referenced from: /usr/lib/libarchive.2.dylib
  Expected in: /opt/local/lib/libiconv.2.dylib
 in /usr/lib/libarchive.2.dylib
Command '['/ActualUsers/serge/Projects-info/ufo-core/build-test/ufo/tmp-introspectlq7hfjl3/Ufo-1.0', '--introspect-dump=/ActualUsers/serge/Projects-info/ufo-core/build-test/ufo/tmp-introspectlq7hfjl3/functions.txt,/ActualUsers/serge/Projects-info/ufo-core/build-test/ufo/tmp-introspectlq7hfjl3/dump.xml']' died with <Signals.SIGABRT: 6>.
make[2]: *** [ufo/Ufo-1.0.gir] Error 1
make[1]: *** [ufo/CMakeFiles/gir.dir/all] Error 2
make: *** [all] Error 2

As I am not an expert in GIR, my understanding is likely (partly) wrong :

gi-r-scanner is producing an executable that is self-introspecting for generating the API file (in GIR format). But this executable is linked to the wrong version either of libarchive or libiconv. My guess is that both these should be taken from the MacPorts /opt/local/lib (rather than libarchive from the system and libiconv from MacPorts)

This is running MacOS 10.15.7 (Catalina) on a MBP 16p

[kencu (Ken)]

g-ir-scanner monkeys around with DYLD_LIBRARY_PATH and similar library linking guts, often with ill effects.

libiconv has been set up to flag these errors by having purposefully different symbols for system vs user installed versions of libiconv, so this library often shows the issue (as it is supposed to) but it is not the source of the problem.

In this case, /usr/lib/libarchive.2.dylib is thinking it is linked against /usr/lib/liconv.2.dylib, and so therefore uses the _iconv symbol, but it is being redirected to /opt/local/lib/libiconv.2.dylib that does not have that symbol.

% nm /usr/lib/libiconv.2.dylib | grep iconv
00000000000f2710 D __libiconv_version
0000000000002390 T _iconv
0000000000014170 s _iconv_2VersionNumber
0000000000014140 s _iconv_2VersionString
00000000000026ab T _iconv_canonicalize
00000000000023b2 T _iconv_close
0000000000001095 T _iconv_open
00000000000023bf T _iconvctl
00000000000024b4 T _iconvlist
0000000000013fac T _libiconv_set_relocation_prefix

% nm /opt/local/lib/libiconv.2.dylib | grep iconv
00000000000f60c0 D __libiconv_version
0000000000002ae9 T _iconv_canonicalize
0000000000002353 T _libiconv
0000000000002375 T _libiconv_close
0000000000001058 T _libiconv_open
0000000000002382 T _libiconv_open_into
0000000000015b87 t _libiconv_relocate
0000000000015c59 t _libiconv_relocate2
0000000000015ad1 T _libiconv_set_relocation_prefix
00000000000027f8 T _libiconvctl
00000000000028f0 T _libiconvlist

g-ir-scanner is a huge PITA for this reason, and we've been trying for months to get it right, without full success.

[serge-cohen (Serge Cohen)]

Thank you for such a rapid answer, and sorry to see that indeed the problem is much larger than the «small one» I have with this package.

I understand, that the cause of my problem is rather «in the upstream» because of the way g-ir-scanner is mangling the environment in which it executes its necessary processes.

Is there anything I can do here to help ? Do you feel it would help you in anyway if I'd filled a bug report to GIR ?

Also, I had much troubles to find documentation on the way g-ir-scanner is processing its input. Do you have any pointers ? Maybe understanding how to «capture» the generated executable (which is currently in a temporary directory that I never managed to catch before it is destructed) would help finding a way around…

Again, thanks for the help, and in general with the work done by MacPorts !

Serge.

[kencu (Ken)]

Well -- MacPorts has changed g-ir-scanner's code, so they won't be too happy about our bug report :>

Your best bet would probably be to dump as much info in this ticket as you can about how you're exactly trying to make this work, and see if we can get it working for you.

[michaelld (Michael Dickens)]

I'm in agreement with @kencu here: Please post whatever info you can and we'll see if we can get the g-ir-scanner working. It looks like you need to set a compile variable to get the correct iconv symbols ... thinking there's an input argument/variable to tell g-ir-scanner what you want it to do here, but I can't recall specifics off the top of my head.

[michaelld (Michael Dickens)]

Something that would be useful: actual commands you're using to download and build the project's code that uses GO-I / g-ir-scanner ...

[jmroot (Joshua Root)]

Replying to kencu:

Well -- MacPorts has changed g-ir-scanner's code, so they won't be too happy about our bug report :>

True, but the original issues that required us to change the code could be reported. Last I heard, the response was likely to be "We don't use macOS. Patches welcome," though.

[ryandesign (Ryan Carsten Schmidt)]

We did already report the problem upstream and they did not respond. Our main bug for the issue was #58574 and the upstream bug is ​https://gitlab.gnome.org/GNOME/gobject-introspection/-/issues/335.

g-ir-scanner must use DYLD_LIBRARY_PATH in order to find and use just-built libraries, but it erroneously adds system directories to that variable as well (anything the build used as -L flags) which is what causes the issue you experienced.

They "fixed" it by switching to using DYLD_FALLBACK_LIBRARY_PATH, but that is the wrong fix and must be reverted.

We have reverted that change in MacPorts and made additional changes that are supposed to ensure that system directories don't end up in DYLD_LIBRARY_PATH while local build directories do.

We have already had several cases where we thought we had it fixed and then a new situation was discovered that we hadn't considered. You may have found another such situation so we need more details about your build. Attach a build log if you can.

[mascguy (Christopher Nielsen)]

Let us know if this is still an issue, after updating to the latest version (1.70.0).

[ryandesign (Ryan Carsten Schmidt)]

comment:ticket:65905:2 says it's still a problem.