Opened 10 years ago
Closed 10 years ago
#46911 closed defect (invalid)
wcslib install fails
Reported by: | watsodw | Owned by: | macports-tickets@… |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.3.3 |
Keywords: | Cc: | john@… | |
Port: | wcslib |
Description
with 'undefined symbols for x86_64'. See log.
Attachments (1)
Change History (13)
Changed 10 years ago by watsodw
comment:1 follow-up: 2 Changed 10 years ago by john@…
comment:2 Changed 10 years ago by watsodw
Replying to john@…:
I'm unable to replicate the problem here. I'd expect the missing symbols to be defined in
/opt/local/lib/gcc48/gcc/x86_64-apple-darwin13/4.8.4/../../../libgfortran.dylib
on your system -- can you check to make sure they're there? Something like$ nm opt/local/lib/gcc48/gcc/x86_64-apple-darwin13/4.8.4/../../../libgfortran.dylib | grep gfortran_transfer_character_write 0000000000081e7c T __gfortran_transfer_character_write(and similarly for
integer_write
) is what you're looking for.I see from your log that you're using a version of cfitsio compiled with an older version (4.6) of gcc. Might be worth making sure everything is built with the same compiler (although I tried mixing and matching here, and couldn't reproduce the issue).
I searched the web to see if anybody had run into similar problems before, and found this issue from a couple of years ago, which sounds very similar... as does the name of the reporter. Did that get resolved? Could it be relevant?
nm /opt/local/lib/libgcc/libgfortran.3.dylib | grep gfortran_transfer_character_write 0000000000081e7c T gfortran_transfer_character_write returns: grep: 0000000000081e7c: No such file or directory grep: T: No such file or directory grep: gfortran_transfer_character_write: No such file or directory
I don't have this problem using gcc48 with anything else.
comment:3 follow-up: 4 Changed 10 years ago by john@…
I'm having trouble parsing what you typed and what was returned in the above -- I think you grepped for the string "0000000000081e7c", which is not correct, but I'm not sure. Can you try reformatting according to the guidelines in WikiFormatting, please?
comment:4 follow-up: 5 Changed 10 years ago by watsodw
Replying to john@…:
I'm having trouble parsing what you typed and what was returned in the above -- I think you grepped for the string "0000000000081e7c", which is not correct, but I'm not sure. Can you try reformatting according to the guidelines in WikiFormatting, please?
I tried entering the command you suggested. The return was:
grep: 0000000000081e7c: No such file or directory grep: T: No such file or directory grep: gfortran_transfer_character_write: No such file or directory
I hope this reply is readable.
comment:5 Changed 10 years ago by watsodw
Replying to david.w.watson@…:
Replying to john@…:
I'm having trouble parsing what you typed and what was returned in the above -- I think you grepped for the string "0000000000081e7c", which is not correct, but I'm not sure. Can you try reformatting according to the guidelines in WikiFormatting, please?
I tried entering the command you suggested. The return was:
grep: 0000000000081e7c: No such file or directory grep: T: No such file or directory grep: gfortran_transfer_character_write: No such file or directory
I hope this reply is readable.
Lets try this again:
grep: 0000000000081e7c: No such file or directory grep: T: No such file or directory grep: __gfortran_transfer_character_write: No such file or directory
comment:6 follow-up: 7 Changed 10 years ago by john@…
Thanks! That's clear. It looks like I wasn't, though. My intention is that you should run the command:
nm /opt/local/lib/gcc48/gcc/x86_64-apple-darwin13/4.8.4/../../../libgfortran.dylib | grep gfortran_transfer_character_write
The $
in my original text indicates your shell prompt -- the intention is "you type things here". The next line is the response that you should get back (ie, in this case nm
has found the symbol you were looking for, and prints some information about it. If the symbol isn't found, you'll get no output). Grepping for "0000000000081e7c" is not telling us anything informative.
Sorry for being unclear!
comment:7 Changed 10 years ago by watsodw
Replying to john@…:
Thanks! That's clear. It looks like I wasn't, though. My intention is that you should run the command:
nm /opt/local/lib/gcc48/gcc/x86_64-apple-darwin13/4.8.4/../../../libgfortran.dylib | grep gfortran_transfer_character_writeThe
$
in my original text indicates your shell prompt -- the intention is "you type things here". The next line is the response that you should get back (ie, in this casenm
has found the symbol you were looking for, and prints some information about it. If the symbol isn't found, you'll get no output). Grepping for "0000000000081e7c" is not telling us anything informative.Sorry for being unclear!
Tried again, I'm told:
error: nm: can't open file: opt/local/lib/gcc48/gcc/x86_64-apple-darwin13/4.8.4/../../../libgfortran.dylib (No such file or directory)
Turns out that there's a symbolic link /opt/local/lib/gcc48/libgfortran.dylib to /opt/local/lib/gcc/libgfortran3.dylib. wcslib is looking for a libgfortran.dylib that does'nt exist.
comment:8 follow-up: 9 Changed 10 years ago by john@…
Are you missing the initial slash on the path you're giving to the nm
command?
I'd expect following symlinks to ultimately get you to something like /opt/local/lib/libgcc/libgfortran.3.dylib
; the precise path doesn't matter, so long as it's ultimately reachable from whatever wcslib is using.
The path that wcslib is using looks plausible to me -- if following symlinks from there doesn't get you to a libgfortran
, then it probably means your gcc installation is broken. If it does, then check if the library provides the missing symbols (using nm
, as above). If it doesn't, then, again, it looks like your gcc installation is broken. If the library both exists and contains the missing symbols, there may be a problem with the wcslib build.
comment:9 Changed 10 years ago by watsodw
Replying to john@…:
Are you missing the initial slash on the path you're giving to the
nm
command?I'd expect following symlinks to ultimately get you to something like
/opt/local/lib/libgcc/libgfortran.3.dylib
; the precise path doesn't matter, so long as it's ultimately reachable from whatever wcslib is using.The path that wcslib is using looks plausible to me -- if following symlinks from there doesn't get you to a
libgfortran
, then it probably means your gcc installation is broken. If it does, then check if the library provides the missing symbols (usingnm
, as above). If it doesn't, then, again, it looks like your gcc installation is broken. If the library both exists and contains the missing symbols, there may be a problem with the wcslib build.
Evidently I didn't run the nm command correctly. Did it again, correctly, and got:
0000000000081e7c T gfortran_transfer_character_write
I have no idea what this means. :(
Also, ran "nm /opt/local/lib/gcc48/gcc/x86_64-apple-darwin13/4.8.4/../../../libgfortran.dylib | grep integer_write" and got:
0000000000081de0 T gfortran_transfer_integer_write
comment:10 follow-up: 11 Changed 10 years ago by john@…
I have no idea what this means. :(
Well, what it means is that you do have a copy of libgfortran on your system which provides the symbols which are supposedly missing: the problem is not that your gfortran installation is messed up, or, at least, not messed up in any particularly obvious way.
Unfortunately, that doesn't help us get to the bottom of the issue. I'm clutching at straws here, but I'm wondering if you have another, broken, libgfortran somewhere else on your system (/usr/local/lib, maybe) which is getting used in preference to that provided by Macports and hence causing things to break.
Other than that, I can't reproduce this problem, and, since you've seen similar problems before with other (unrelated, non-Macports) software, I'm afraid it rather looks like there's an issue with the way you've set your system up which is probably out of scope for something we can handle in a wcslib bug report. Sorry!
comment:11 Changed 10 years ago by watsodw
Replying to john@…:
I have no idea what this means. :(
Well, what it means is that you do have a copy of libgfortran on your system which provides the symbols which are supposedly missing: the problem is not that your gfortran installation is messed up, or, at least, not messed up in any particularly obvious way.
Unfortunately, that doesn't help us get to the bottom of the issue. I'm clutching at straws here, but I'm wondering if you have another, broken, libgfortran somewhere else on your system (/usr/local/lib, maybe) which is getting used in preference to that provided by Macports and hence causing things to break.
Other than that, I can't reproduce this problem, and, since you've seen similar problems before with other (unrelated, non-Macports) software, I'm afraid it rather looks like there's an issue with the way you've set your system up which is probably out of scope for something we can handle in a wcslib bug report. Sorry!
That's exactly what happened. I have a copy in /usr/local/lib that got installed with NIST Dataplot. I moved it out of the way and the install worked. Thanks!
comment:12 Changed 10 years ago by larryv (Lawrence Velázquez)
Resolution: | → invalid |
---|---|
Status: | new → closed |
Whew.
I'm unable to replicate the problem here. I'd expect the missing symbols to be defined in
/opt/local/lib/gcc48/gcc/x86_64-apple-darwin13/4.8.4/../../../libgfortran.dylib
on your system -- can you check to make sure they're there? Something like(and similarly for
integer_write
) is what you're looking for.I see from your log that you're using a version of cfitsio compiled with an older version (4.6) of gcc. Might be worth making sure everything is built with the same compiler (although I tried mixing and matching here, and couldn't reproduce the issue).
I searched the web to see if anybody had run into similar problems before, and found this issue from a couple of years ago, which sounds very similar... as does the name of the reporter. Did that get resolved? Could it be relevant?