Opened 9 years ago

Closed 9 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)

main.log (121.1 KB) - added by watsodw 9 years ago.

Download all attachments as: .zip

Change History (13)

Changed 9 years ago by watsodw

Attachment: main.log added

comment:1 Changed 9 years ago by 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?

Last edited 9 years ago by john@… (previous) (diff)

comment:2 in reply to:  1 Changed 9 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 Changed 9 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 in reply to:  3 ; Changed 9 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 in reply to:  4 Changed 9 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 Changed 9 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!

Last edited 9 years ago by john@… (previous) (diff)

comment:7 in reply to:  6 Changed 9 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_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!

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 Changed 9 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 in reply to:  8 Changed 9 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 (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.

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. :(

Version 0, edited 9 years ago by watsodw (next)

comment:10 Changed 9 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 in reply to:  10 Changed 9 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 9 years ago by larryv (Lawrence Velázquez)

Resolution: invalid
Status: newclosed

Whew.

Note: See TracTickets for help on using tickets.