Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#61086 closed defect (invalid)

graphviz@2.40.1_3+pangocairo+x11: /usr/lib//libiconv.la: No such file

Reported by: JDLH (Jim DeLaHunt) Owned by: ryandesign (Ryan Carsten Schmidt)
Priority: Normal Milestone:
Component: ports Version: 2.6.3
Keywords: Cc:
Port: graphviz

Description

Updating graphviz @2.40.1_3+pangocairo+x11 from graphviz @2.40.1_2+pangocairo+x11, or installing it as graphviz @2.40.1_3+pangocairo+x11, fails with error message

:info:build ggrep: /usr/lib//libiconv.la: No such file or directory

Attaching the main.log file in two versions:

  • graphviz_ld-bug_main_2020-08-29a.log from port update graphviz
  • graphviz_ld-bug_main_2020-08-29b.log from port install graphviz +pangocairo+x11

Attachments (2)

graphviz_ld-bug_main_2020-08-29a.log (1.8 MB) - added by JDLH (Jim DeLaHunt) 4 years ago.
graphviz_ld-bug_main_2020-08-29a.log from port update graphviz
graphviz_ld-bug_main_2020-08-29b.log (1.9 MB) - added by JDLH (Jim DeLaHunt) 4 years ago.
graphviz_ld-bug_main_2020-08-29b.log from port install graphviz +pangocairo+x11

Change History (10)

Changed 4 years ago by JDLH (Jim DeLaHunt)

graphviz_ld-bug_main_2020-08-29a.log from port update graphviz

Changed 4 years ago by JDLH (Jim DeLaHunt)

graphviz_ld-bug_main_2020-08-29b.log from port install graphviz +pangocairo+x11

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

That's a new one for me.

It's normal that /usr/lib/libiconv.la does not exist. It's also normal on OS X 10.9 and later (and I see you're on 10.13) that /opt/local/lib/libiconv.la does not exist, and indeed that most .la files do not exist; MacPorts deliberately deletes them because their presence causes certain problems.

So the question is why your build is trying to find /usr/lib/libiconv.la, or indeed any part of libiconv, since as far as I know libiconv is not a direct dependency of graphviz.

Do you by chance have anything installed in /usr/local or /sw?

Do you have any .la files in /opt/local/lib? (ls -l /opt/local/lib/*.la) A couple ports do override the MacPorts default and keep them around, which is fine, but let's make sure there aren't any there that shouldn't be there.

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

comment:2 Changed 4 years ago by JDLH (Jim DeLaHunt)

Thank you for your attention, Ryan.

Do you by chance have anything installed in /usr/local or /sw?

g% ls -lF /usr/local                                                     
total 0
drwxr-xr-x@ 100 root  wheel  3200 13 Aug 11:10 bin/
drwxr-xr-x@   4 root  wheel   128  2 Sep  2019 etc/
drwxr-xr-x@  21 root  wheel   672  2 Sep  2019 include/
drwxr-xr-x@  63 root  wheel  2016  2 Sep  2019 lib/
drwxr-xr-x@   3 root  wheel    96  2 Sep  2019 man/
drwxr-xr-x@   5 root  wheel   160  2 Sep  2019 mysql/
drwxr-xr-x@   9 root  wheel   288  2 Sep  2019 pgsql/
drwxr-xr-x    3 root  wheel    96  2 Sep  2019 remotedesktop/
drwxr-xr-x@   4 root  wheel   128  2 Sep  2019 share/
drwxr-xr-x@  15 jdlh  staff   480  2 Sep  2019 soylatte16-i386/
drwxrwxr-x    3 root  wheel    96  2 Sep  2019 src/
% ls -lF /sw                                                            
ls: /sw: No such file or directory

In /usr/local/*, mysql contains symlinks for bin/, include/, and lib/. pgsql contains an instance of postgresql, probably 8.3.1, files dating from 2008. soylatte16-i386 is an instance of Java JDK 6 dated 2008.

There are plenty of files in /usr/local/lib/*, all dated 2017 or earlier.

% ls -lF /usr/local/lib/*.la           
-rwxr-xr-x@ 1 root  wheel   973  8 Mar  2014 /usr/local/lib/libcdio++.la*
-rwxr-xr-x@ 1 root  wheel   938  8 Mar  2014 /usr/local/lib/libcdio.la*
-rwxr-xr-x@ 1 root  wheel   795 19 Dec  2008 /usr/local/lib/libfuse.la*
-rwxr-xr-x@ 1 root  wheel   831 19 Dec  2008 /usr/local/lib/libfuse_ino64.la*
-rwxr-xr-x@ 1 root  wheel  1028 11 Jul  2008 /usr/local/lib/libgd.la*
-rwxr-xr-x@ 1 root  wheel  1020  8 Mar  2014 /usr/local/lib/libiso9660++.la*
-rwxr-xr-x@ 1 root  wheel   979  8 Mar  2014 /usr/local/lib/libiso9660.la*
-rwxr-xr-x@ 1 root  wheel   955  8 Mar  2014 /usr/local/lib/libudf.la*

Do you have any .la files in /opt/local/lib?

Not many:

% ls -lF /opt/local/lib/*.la
-rwxr-xr-x  1 root  wheel   978 21 Aug 17:00 /opt/local/lib/libMagick++-6.Q16.la*
-rwxr-xr-x  1 root  wheel   990 21 Aug 17:00 /opt/local/lib/libMagickCore-6.Q16.la*
-rwxr-xr-x  1 root  wheel   990 21 Aug 17:00 /opt/local/lib/libMagickWand-6.Q16.la*
-rw-r--r--  1 root  wheel  1028 11 Jul  2008 /opt/local/lib/libgd.la

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

ImageMagick is one of the ports that intentionally keeps its .la files. gd2 is not. Verify with port provides /opt/local/lib/libgd.la that it was not provided by a MacPorts port, then try deleting /opt/local/lib/libgd.la.

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

It is curious that libgd.la in both /opt/local/lib and /usr/local/lib have the same date.

comment:5 Changed 4 years ago by JDLH (Jim DeLaHunt)

There is a libgd.lai in the mix also. I am not familiar with the .lai extension. The dates aren't exactly the same, but two of the files are identical. They are all very old.

% ls -lT /opt/local/lib/libgd.la* /usr/local/lib/libgd.la*
-rw-r--r--  1 root  wheel  1028 11 Jul 12:03:54 2008 /opt/local/lib/libgd.la
-rw-r--r--  1 root  wheel  1028 11 Jul 12:02:35 2008 /opt/local/lib/libgd.lai
-rwxr-xr-x@ 1 root  wheel  1028 11 Jul 12:11:04 2008 /usr/local/lib/libgd.la
% openssl dgst -md5  /opt/local/lib/libgd.la* /usr/local/lib/libgd.la*
MD5(/opt/local/lib/libgd.la )= 970e85327a186aab6251114b8fd90e3c
MD5(/opt/local/lib/libgd.lai)= 78e72d984c947b56158535c18f6677ea
MD5(/usr/local/lib/libgd.la )= 78e72d984c947b56158535c18f6677ea

(I tweaked the spacing to make the digests line up, for easier comparison.)

None of these libraries is claimed by a port.

% port provides /opt/local/lib/libgd.la* /usr/local/lib/libgd.la*
/opt/local/lib/libgd.la is not provided by a MacPorts port.
/opt/local/lib/libgd.lai is not provided by a MacPorts port.
/usr/local/lib/libgd.la is not provided by a MacPorts port.

I renamed the /opt/local/lib/libgd.la* files to hide them from MacPorts.

% cd /opt/local/lib
% foreach f (libgd.la*) do ; sudo mv $f ${f}.DISABLED_2020-08-30 ; done
Password:
Nothung% ls -lT libgd.la*
-rw-r--r--  1 root  wheel    1028 11 Jul 12:03:54 2008 libgd.la.DISABLED_2020-08-30
-rw-r--r--  1 root  wheel    1028 11 Jul 12:02:35 2008 libgd.lai.DISABLED_2020-08-30

With that, sudo port install graphviz run successfully. The workaround seems effective!

Thank you!

comment:6 Changed 4 years ago by JDLH (Jim DeLaHunt)

Why are these very old, and unclaimed, libraries in /opt/local/lib? I have upgraded macOS at least three times since 2008, and moved hardware at least twice. I followed the instructions for migrating MacPorts to the new OS. That includes listing the ports, uninstalling all of the ports, and reinstalling. However, it does not include deleting all of /opt/local/*. When migrating hardware, I use the Apple Migration Assistant, which probably copies all of /opt/local/* to the new machine. Maybe I should delete the whole directory next time I migrate to a new macOS version.

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

Resolution: invalid
Status: assignedclosed

Replying to JDLH:

There is a libgd.lai in the mix also. I am not familiar with the .lai extension.

I wasn't either. As far as I can tell in brief research, the .lai file would be created in the build directory, and then it would be copied to an .la file in the installation directory. In other words, an .lai file should never have been installed.

With that, sudo port install graphviz run successfully. The workaround seems effective!

Glad it worked!

Replying to JDLH:

Why are these very old, and unclaimed, libraries in /opt/local/lib?

Only you can know that. :) One situation that we encounter from time to time is users who run third-party software installers that were themselves built using MacPorts set to its default prefix. Using such an installer would write files to the MacPorts prefix, overwriting files you might already have installed there using MacPorts and of course not informing MacPorts that this has happened. We advise people not to distribute installers that do this, but it happens. If you ran such an installer in 2008 (or perhaps just an installer that was made in 2008) and gd2 was one of the things it installed, that could account for the presence of those files. And of course once they're there they're not going to be deleted unless you delete them; MacPorts isn't going to remove them for you since it didn't put them there and doesn't know they exist.

I'm not sure why any .la file of any era would have referred to /usr/lib/libiconv.la on macOS since as far as I know macOS never shipped with any .la files in /usr/lib. So it's a bit of a mystery how you got that file.

I have upgraded macOS at least three times since 2008, and moved hardware at least twice. I followed the instructions for migrating MacPorts to the new OS. That includes listing the ports, uninstalling all of the ports, and reinstalling. However, it does not include deleting all of /opt/local/*.

Right, deleting all of /opt/local is pretty disruptive, since you likely have files in there that you want to keep, such as configuration files, maybe databases, etc.

When migrating hardware, I use the Apple Migration Assistant, which probably copies all of /opt/local/* to the new machine.

It does, if you ask it to. (I think you get the opportunity to say what information you want to transfer, right?)

Maybe I should delete the whole directory next time I migrate to a new macOS version.

It might be a good idea. Whatever action put the gd2 .la file there could have installed other files as well that could cause problems in the future. But before you remove all of /opt/local, remember to save any config files or other files you modified and want to keep.

comment:8 Changed 4 years ago by JDLH (Jim DeLaHunt)

I appreciate your help. Thank you!

And I'm glad this ticket now has a lot of search terms to potentially help someone in the future.

Note: See TracTickets for help on using tickets.