Opened 4 years ago
Last modified 21 months ago
#61987 reopened defect
gobject-introspection @1.60.2_4 : g-ir-scanner producing executable with linking problems
Reported by: | serge-cohen (Serge Cohen) | Owned by: | mascguy (Christopher Nielsen) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.6.4 |
Keywords: | Cc: | michaelld (Michael Dickens), ctreleaven (Craig Treleaven), evanmiller (Evan Miller) | |
Port: | gobject-introspection |
Description
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
Change History (14)
comment:1 Changed 4 years ago by kencu (Ken)
comment:2 Changed 4 years ago by 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.
comment:3 follow-up: 7 Changed 4 years ago by 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.
comment:4 Changed 4 years ago by 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.
comment:5 Changed 4 years ago by 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 ...
comment:6 Changed 4 years ago by michaelld (Michael Dickens)
Cc: | michaelld added |
---|
comment:7 Changed 4 years ago by 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.
comment:8 Changed 4 years ago by jmroot (Joshua Root)
Port: | @1.60.2_4 removed |
---|
comment:9 Changed 4 years ago by 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.
comment:10 Changed 4 years ago by mf2k (Frank Schima)
Cc: | dbevans removed |
---|---|
Owner: | set to dbevans |
Status: | new → assigned |
comment:11 Changed 3 years ago by ctreleaven (Craig Treleaven)
Cc: | ctreleaven added |
---|
comment:12 Changed 3 years ago by mascguy (Christopher Nielsen)
Cc: | evanmiller added |
---|---|
Owner: | changed from dbevans to mascguy |
comment:13 Changed 3 years ago by mascguy (Christopher Nielsen)
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Let us know if this is still an issue, after updating to the latest version (1.70.0).
comment:14 Changed 21 months ago by ryandesign (Ryan Carsten Schmidt)
Resolution: | fixed |
---|---|
Status: | closed → reopened |
comment:ticket:65905:2 says it's still a problem.
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.
g-ir-scanner is a huge PITA for this reason, and we've been trying for months to get it right, without full success.