[MacPorts] #48012: nettle @2.7.1: error: no member named 'ptrdiff_t' in the global namespace

[MacPorts]

#48012: nettle @2.7.1: error: no member named 'ptrdiff_t' in the global namespace
--------------------------+--------------------------
  Reporter:  m74z00219@…  |      Owner:  ryandesign@…
      Type:  defect       |     Status:  closed
  Priority:  Normal       |  Milestone:
 Component:  ports        |    Version:  2.3.3
Resolution:  invalid      |   Keywords:
      Port:  nettle       |
--------------------------+--------------------------
Changes (by ryandesign@…):

 * status:  new => closed
 * resolution:   => invalid


Comment:

 Replying to [comment:5 m74z00219@…]:
 > So, in "/opt/local/lib/" I have the library that is old:
 > {{{
 > /opt/local/lib/libgmp.10.dylib
 > }}}
 >
 > But I also have another library, which I suppose is the correct one:
 > {{{
 > /opt/local/lib/libgmp.dylib
 > }}}

 Unless something else is wrong on your system, libgmp.dylib is a symlink
 to the current version of libgmp—which at this time is libgmp.10.dylib:

 {{{
 $ ls -l /opt/local/lib/libgmp.dylib
 lrwxr-xr-x  1 root  wheel  15 Oct  4  2014 /opt/local/lib/libgmp.dylib ->
 libgmp.10.dylib
 }}}

 Note that a library has two version numbers—a major version and a minor
 version. In the situation we've been talking about in this ticket, the
 major version hasn't changed—it was and still is 10. This is the number
 you see in the filename. What has changed is the minor version, which is
 encoded into the library and can be revealed by using the `otool -L`
 command. From my system:

 {{{
 $ otool -L /opt/local/lib/libgmp.dylib
 /opt/local/lib/libgmp.dylib:
         /opt/local/lib/libgmp.10.dylib (compatibility version 13.0.0,
 current version 13.0.0)
         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
 version 1213.0.0)
 }}}

 Here we see that my libgmp has major version 10, and minor version 13.0.0.
 On your system when you filed this ticket, you somehow had libgmp major
 version 10 but minor version 11.0.0.

 If a program is linked with one ''major'' version of a library (for
 example, a program is linked with libpng16.16.dylib) and then the library
 is upgraded to a new major version (for example, libpng16.17.dylib), the
 program will cease to function and needs to be rebuilt. MacPorts
 maintainers should know this, and should increase the revision of ports
 using the library to cause them to rebuilt. If maintainers forget this,
 the MacPorts rev-upgrade function detects it and tries to fix it by
 rebuilding affected ports against the new library.

 If a program is linked with one ''minor'' version of a library (for
 example, if nettle was linked with libgmp.10.dylib minor version 11.0.0),
 and then the library is upgraded to a new minor version but the same major
 version (for example, libgmp.10.dylib minor version 13.0.0), that's fine;
 the program continues to work. This is what normally happens when
 libraries are updated. However, if the program is built with a new version
 of the library (for example, nettle linked with libgmp.10.dylib minor
 version 13.0.0—this was the case on your system and was normal) and then
 the library changes to an earlier minor version (in your case,
 libgmp.10.dylib minor verison 11.0.0), the program will cease to function.
 This shouldn't happen in normal use. After you installed nettle, you or a
 non-MacPorts installer you ran did this by replacing the current gmp
 library with an older version. MacPorts isn't designed to anticipate that
 anyone would ever do this. rev-upgrade correctly detected that programs
 linked with gmp were broken, but what it tried to do as a result—rebuild
 programs linked with gmp—wasn't the correct solution. (The correct
 solution was to rebuild gmp, but it couldn't have known that.) The rebuild
 of nettle failed because the old version of gmp you shoehorned into the
 system isn't compatible with the version of nettle we have in MacPorts.

 > Before I ran "sudo port -n upgrade --force gmp" I noticed that
 libgmp.10.dylib had a modification date going back to 2012. The
 aforementioned command succeeded in forcing gmp to install and, you know
 what, I was subsequently able to successfully install nettle!

 The modification date of gmp's files should have been in 2014, because the
 last time the port's version or revision was increased was r125350 in
 September 2014.

 > When I next attempted to install gnutls, I got an unsurprising error:
 > {{{
 > Unable to execute port: can't set "depends_lib": invalid depspec:
 path:~/.git/nettle/nettle:nettle
 > }}}

 Unsurprising? The error is extremely surprising to me, since no port that
 we distribute has such a depspec. Where is this depspec being used? What
 you said next may be the answer:

 > So, I tried again with tracemode activated -- got the same error. Then I
 made sure to uninstall the git build and other extra-macports builds I
 attempted -- same darn error.

 What "git build", what "extra-macports builds" are we talking about here?
 This may be another contributor to the problems you're having, and is
 something you should have mentioned from the beginning.

 Are you using unofficial or self-modified portfiles that use different
 versions of the software, pulled from git repositories? When you manually
 edit "random" portfiles to be different versions of software, this may
 change library versions or cause other incompatibilities, and other ports
 using that library will then need to be rebuilt, or even themselves
 updated or patched to remain compatible. Dealing with this type of
 breakage is one of the things MacPorts maintainers will (ideally) take
 care of for you when they update ports. If you want to edit ports
 yourself, that's fine, but then you become responsible for dealing with
 these issues.

 > Finally, I surmised that there is some file floating around that points
 to git, most likely generated by a previous build. So, I updated Macports
 and then ran "sudo port upgrade outdated" and thankfully it finally let me
 install gnutls and everything else I had previously failed at installing.

 If you have a normal rsync-based ports tree, and you had local
 modifications to some ports, and then you ran "sudo port selfupdate" or
 "sudo port sync", that should have wiped our your modifications and
 returned you to the standard ports collection. Running "sudo port upgrade
 outdated" would then upgrade any outdated ports, and the rev-upgrade
 process that runs after any upgrades should have found any linkage
 problems and rebuilt any affected ports.

 However, if you have modified your sources.conf to list any additional
 ports trees, such as unofficial port trees made by others, or a directory
 containing your own ports, this could still cause similar problems. In
 this case, you should either remove the nonstandard ports trees from
 sources.conf, or else you must take responsibility for dealing with any
 issues that arise as a result of the user of the nonstandard ports tree,
 either by resolving the issues yourself or by working with whoever
 provided the nonstandard ports tree to you.

-- 
Ticket URL: <https://trac.macports.org/ticket/48012#comment:6>
MacPorts <https://www.macports.org/>
Ports system for OS X