libidn fails to build

[metbic]

Hello all. Greetings!

Tried to upgrade the all-popular inkscape.

Went alright until hit the snag with libidn.

Error message states:

--->  Building libidn
Error: Failed to build libidn: command execution failed  
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_mail_libidn/libidn/main.log for details.
Error: Follow https://guide.macports.org/#project.tickets if you believe there is a bug.

I cannot uninstall and re-install because I fear it will destroy ghostscript.

Note: It is not recommended to uninstall/deactivate a port that has dependents as it breaks the dependents.
The following ports will break:
 p5.26-net-libidn @0.120.0_5
 p5.28-net-libidn @0.120.0_5
 ghostscript @9.53.3_1

There is no maintainer.

Does it have to do with the thread about libidn2? #63309

Thank you and forgive me if I forgot to report something.

best regards
metbic

[metbic]

main.log

[evanmiller (Evan Miller)]

This issue looks similar: ​https://legacy.imagemagick.org/discourse-server/viewtopic.php?t=28136

Apparently there is supposed to be a global_symbol_pipe variable that is defined during configure, but that's not happening for some reason. This is a good explanation, though it lacks a solution:

​https://lists.gnu.org/archive/html/bug-libtool/2015-07/msg00000.html

[metbic]

Related? But I could install and use both gimp and inkscape very well with macports, for quite some years, on this machine, and that must've included several versions of imagemagick, didn't it? Never had encountered that problem, and its report is from 2015.

[evanmiller (Evan Miller)]

Hi, the issue is deeper than ImageMagick and has to do with a program called libtool that is used during the build process for both ImageMagick and libidn.

[metbic]

Alright, I will try to upgrade libtool and report back.

[metbic]

Impossible, can't upgrade it since "port upgrade outdated" stops because of libidn.

[metbic]

This is a mess. Sorry for that.

[evanmiller (Evan Miller)]

You can try port -n upgrade inkscape. That will try to install inkscape without upgrading the dependencies (may or may not work...)

[metbic]

... I have quite a bunch of broken ports now that ask me for a rebuild, not sure what is best now ...

[metbic]

inkscape is dead now - how can I go back to the previous version of libidn ?

[ryandesign (Ryan Carsten Schmidt)]

Replying to evanmiller:

You can try port -n upgrade inkscape. That will try to install inkscape without upgrading the dependencies (may or may not work...)

You should not do that.

how can I go back to the previous version of libidn ?

wiki:howto/InstallingOlderPort

[metbic]

it's already too late ... the older version is no longer there

port installed libidn

The following ports are currently installed:
  libidn @1.36_0+universal (active)

[metbic]

What a poor decision from me in the first place. This is an older machine, but it had all the tools I need. Don't know what got into me even trying to upgrade anything.

[ryandesign (Ryan Carsten Schmidt)]

Replying to metbic:

Does it have to do with the thread about libidn2? #63309

Nothing whatsoever.

Replying to evanmiller:

This issue looks similar: ​https://legacy.imagemagick.org/discourse-server/viewtopic.php?t=28136

Apparently there is supposed to be a global_symbol_pipe variable that is defined during configure, but that's not happening for some reason. This is a good explanation, though it lacks a solution:

​https://lists.gnu.org/archive/html/bug-libtool/2015-07/msg00000.html

That bug-libtool post says "it only occurs due to outside influences". If that's so, maybe building with trace mode would hide those outside influences from the build.

sudo port clean libidn
sudo port -t upgrade libidn

Replying to metbic:

it's already too late ... the older version is no longer there

port installed libidn
The following ports are currently installed:
  libidn @1.36_0+universal (active)

If the older version is no longer installed then indeed you cannot follow the steps in the first section of that wiki page, "Reactivating an older version that's still installed", but you can follow the steps in the subsequent section, "(Re)installing an older version that's no longer installed". However, reinstalling older versions of ports is not the intended solution for issues; we should try to figure out what is wrong and fix it with the current versions.

However, you've shown above that you have libidn 1.36 installed, which is not the current version; the current version is 1.38. The updates to 1.37 and then 1.38 were made in 2021.

[ryandesign (Ryan Carsten Schmidt)]

The main.log does show this error, indicative of the libtool problem being discussed:

:info:configure checking command to parse /opt/local/bin/nm output from /usr/bin/clang object... failed

To discover why this failed, we could look in the config.log file; you could attach it.

[evanmiller (Evan Miller)]

@metbic It looks like port -n upgrade was bad advice. I am sorry about that.

@ryandesign The easiest path might be to unhook ghostscript from libidn (i.e. configure --without-libidn, maybe re-enable with a variant?). Then libidn will not be in the inkscape upgrade path.

[metbic]

/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_mail_libidn/libidn/work/libidn\-1.38/config.log

[ryandesign (Ryan Carsten Schmidt)]

The config.log shows that the reason is:

dyld: Library not loaded: /opt/local/lib/libffi.7.dylib
  Referenced from: /opt/local/libexec/llvm-7.0/lib/libLLVM.dylib
  Reason: no suitable image found.  Did find:
        /usr/local/lib/libffi.7.dylib: stat() failed with errno=13

So the problem is that libffi was updated to a new version that provides libffi.8.dylib (not libffi.7.dylib like it used to), and your llvm-7.0 port hasn't been updated yet. Update it first.

sudo port upgrade llvm-7.0

If you do have /usr/local/lib/libffi.7.dylib as the error message says, that is not recommended; see wiki:FAQ#usrlocal.

[metbic]

However, you've shown above that you have libidn 1.36 installed, which is not the current version; the current version is 1.38. The updates to 1.37 and then 1.38 were made in 2021.

Spring 2021 was indeed the last time I did a full port upgrade outdated.

[metbic]

--->  Activating llvm-7.0 @7.1.0_2
--->  Cleaning llvm-7.0
--->  Scanning binaries for linking errors
--->  Found 255 broken files, matching files to ports    
Warning: No port p5.26-net-ssleay found in the index; can't rebuild
--->  Found 37 broken ports, determining rebuild order
You can always run 'port rev-upgrade' again to fix errors.
The following ports will be rebuilt:
 python27 @2.7.18+universal
 python36 @3.6.13+universal
 python37 @3.7.9+universal
 python38 @3.8.7+universal
 python39 @3.9.4+universal
 net-snmp @5.9+ssl
 botan @2.10.0
 glib2 @2.58.3+universal+x11
 gobject-introspection @1.60.2+universal
 py27-gobject @2.28.7+x11
 py27-gobject3 @3.36.1
 py36-gobject3 @3.38.0
 py37-gobject3 @3.38.0
 py38-gobject3 @3.38.0
 py39-gobject3 @3.38.0
 kerberos5 @1.19.1
 p11-kit @0.23.22+universal
 openssh @8.4p1+kerberos5+xauth
 libevent @2.1.12+universal
 links @2.21+universal
 libfetch @9.0.0-RELEASE
 gdl3 @3.40.0
 neon @0.31.2
 opusfile @0.11
 libshout2 @2.4.4
 libssh2 @1.9.0
 gstreamer1-gst-plugins-bad @1.16.2+x11
 p5.28-net-ssleay @1.900.0
 ruby25 @2.5.8
 sane-backends @1.0.31+avahi
 cyrus-sasl2 @2.1.27+kerberos
 openldap @2.4.56
 llvm-5.0 @5.0.2
 llvm-8.0 @8.0.1
 llvm-9.0 @9.0.1+universal
 qt4-mac @4.8.7
 kdelibs4 @4.14.3
Continue? [Y/n]: 

Should I Yes or should I No ? ... I hit yes, of course ... wish me luck ...

[ryandesign (Ryan Carsten Schmidt)]

Either way. If you answer yes, those ports will be rebuilt or upgraded now. If you answer no, they will remain broken, but are presumably broken only because they link with old versions of libraries, which is why their revision or version was subsequently increased, so they should already be included in the set of outdated ports, and running sudo port upgrade outdated should upgrade them.

[metbic]

Alright, after another port clean all, finally port upgrade libidn worked well. To make sure it worked, I did port upgrade libidn again, but this stopped without noteworthy results because of python39 not being able to build #64708.

But, I guess this ticket could be closed.