#48012 closed defect (invalid)
nettle @2.7.1: error: no member named 'ptrdiff_t' in the global namespace
Reported by: | m74z00219@… | Owned by: | ryandesign (Ryan Carsten Schmidt) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.3.3 |
Keywords: | Cc: | ||
Port: | nettle |
Description (last modified by ryandesign (Ryan Carsten Schmidt))
While it seems that Nettle has been abandoned, it seems that I need it. Unfortunately, I can't for the life of me get it to build.
After running this
sudo port -t install nettle
Macports reports that there are a number of broken links and that there are two broken ports. Seems that the broken ports are nettle itself and gnutls (which depends on nettle).
Once "Configuring Nettle" begins, Macports delivers a warning:
The following file inside the MacPorts prefix not installed by a port was accessed: /opt/local/bin/gcc
It also gives warnings about files being hidden from install, but I guess that's the point of tracemode.
Then, finally, the error itself:
Error: org.macports.build for port nettle returned: command execution failed
I tried combing through the error log, but, to be honest, it doesn't make much sense to me.
I would appreciate any assistance.
Attachments (3)
Change History (10)
Changed 9 years ago by m74z00219@…
Attachment: | errorlog.txt added |
---|
comment:1 Changed 9 years ago by ryandesign (Ryan Carsten Schmidt)
Description: | modified (diff) |
---|---|
Owner: | changed from macports-tickets@… to ryandesign@… |
Port: | 2.7.1 removed |
Summary: | Nettle 2.7.1 build failure → nettle @2.7.1: error: no member named 'ptrdiff_t' in the global namespace |
comment:2 Changed 9 years ago by ryandesign (Ryan Carsten Schmidt)
Thanks for the report.
Ports should not have been broken... what does it say about why the ports are broken? You can get that information by running "sudo port -v rev-upgrade
".
What versions of Xcode and clang do you have? You can find out by running "xcodebuild -version
" and "clang -v
".
comment:3 follow-up: 4 Changed 9 years ago by m74z00219@…
Hi and you're most welcome.
To give a little more context, I had been attempting to install the port youtube-dl, which depends on ffmpeg, which depends on gnutls, which depends on nettle. While I'm not exactly sure of what constitutes a "broken" port (perhaps being interrupted during build?), I believe that list must have comprised the aforementioned ports. Unfortunately, I've already uninstalled youtube-dl and its dependencies. However, I did just just attempt to install nettle again (new log attached).
My Xcode version is 6.3.2 (build 6D2105). My clang, which I actually upgraded today in hopes that it would help with nettle, is version 3.7.0 (trunk 239386); Target: x86_64-apple-darwin14.4.0; Thread model: posix.
Since I uninstalled youtube-dl and it's dependencies -- save nettle -- I'm not sure if ""sudo port -v rev-upgrade"" will yield much. My eyes don't see anything meaningful, so I attached it to this ticket.
Changed 9 years ago by m74z00219@…
Changed 9 years ago by m74z00219@…
comment:4 Changed 9 years ago by ryandesign (Ryan Carsten Schmidt)
Replying to m74z00219@…:
To give a little more context, I had been attempting to install the port youtube-dl, which depends on ffmpeg, which depends on gnutls, which depends on nettle. While I'm not exactly sure of what constitutes a "broken" port (perhaps being interrupted during build?), I believe that list must have comprised the aforementioned ports. Unfortunately, I've already uninstalled youtube-dl and its dependencies. However, I did just just attempt to install nettle again (new log attached).
My Xcode version is 6.3.2 (build 6D2105). My clang, which I actually upgraded today in hopes that it would help with nettle, is version 3.7.0 (trunk 239386); Target: x86_64-apple-darwin14.4.0; Thread model: posix.
Since I uninstalled youtube-dl and it's dependencies -- save nettle -- I'm not sure if ""sudo port -v rev-upgrade"" will yield much. My eyes don't see anything meaningful, so I attached it to this ticket.
Thanks, that helps.
A "broken" port is one linked with libraries that don't exist or that are the wrong version.
From your log:
Incompatible library version: /opt/local/bin/nettle-hash requires version 13.0.0 or later, but /opt/local/lib/libgmp.10.dylib provides version 11.0.0 Incompatible library version: /opt/local/bin/nettle-lfib-stream requires version 13.0.0 or later, but /opt/local/lib/libgmp.10.dylib provides version 11.0.0 Incompatible library version: /opt/local/bin/pkcs1-conv requires version 13.0.0 or later, but /opt/local/lib/libgmp.10.dylib provides version 11.0.0 Incompatible library version: /opt/local/bin/sexp-conv requires version 13.0.0 or later, but /opt/local/lib/libgmp.10.dylib provides version 11.0.0 Incompatible library version: /opt/local/lib/libhogweed.2.5.dylib requires version 13.0.0 or later, but /opt/local/lib/libgmp.10.dylib provides version 11.0.0
So the files installed by nettle are linked with gmp libraries version 13, which is how it should be: that's the version of the gmp libraries on my system. But for some reason you have gmp libraries version 11 on your system.
You have somehow replaced your gmp libraries with older versions, without MacPorts knowing about this. Perhaps you ran a third-party installer that overwrote these files?
You need to get gmp libraries version 13 back onto your system. One way to do that is to force gmp to rebuild:
sudo port -n upgrade --force gmp
Then nettle will no longer be considered broken.
However, if gmp files were overwritten on your system, who knows how many other files from other ports were also overwritten... The safest thing to do would be to uninstall all ports, and MacPorts itself, including deleting /opt/local entirely, after having saved any important data or configuration file therein, then reinstalling MacPorts and the ports you want. That way you can be sure only files in the MacPorts prefix are the ones MacPorts put there.
comment:5 follow-ups: 6 7 Changed 9 years ago by m74z00219@…
A most disturbing proposition. I will investigate your findings before taking "drastic" measures and report back with my findings.
Thanks!
EDIT:
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
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!
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
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.
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.
So, things work now, though I can't say I fully understand how this problem began. While that old gmp library had a modification date from 2012, that doesn't necessarily mean it was added to the directory back then. Even so, I'm confused as to why nettle couldn't differentiate between the newer gmp library, which, according to my own analysis, was in the same directory.
*shrugs*
Thank you for your valuable advice, ryandesign.
comment:6 Changed 9 years ago by ryandesign (Ryan Carsten Schmidt)
Resolution: | → invalid |
---|---|
Status: | new → closed |
Replying to m74z00219@…:
So, in "/opt/local/lib/" I have the library that is old:
/opt/local/lib/libgmp.10.dylibBut 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.
comment:7 Changed 9 years ago by ryandesign (Ryan Carsten Schmidt)
Replying to m74z00219@…:
A most disturbing proposition. I will investigate your findings before taking "drastic" measures and report back with my findings.
Thanks!
EDIT:
Note that I did not see your edit until I happened to check the ticket just now. Trac sends email notifications when comments are added, but not when they're edited, so if you have further information to add to a ticket, always add a new comment, don't edit an old comment. Only use the edit feature for minor unimportant edits, such as to fix typos or formatting mistakes.
Says errorlog.txt, but I guess this is really an installation log.