Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#41361 closed defect (fixed)

octave-devel failed to compile on 10.9

Reported by: azurvii@… Owned by: michaelld (Michael Dickens)
Priority: Normal Milestone:
Component: ports Version: 2.2.1
Keywords: Cc: ryandesign (Ryan Schmidt)
Port: octave-devel

Description

the blocking error shown in /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_octave-devel/octave-devel/main.log was:

:info:build   "Magick::CoderInfo::CoderInfo(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&)", referenced from:
:info:build       F__magick_format_list__(octave_value_list const&, int) in DLD_FUNCTIONS___magick_read___la-__magick_read__.o
:info:build ld: symbol(s) not found for architecture x86_64

Not really sure, but could it be related to ImageMagick? I was doing "sudo port install octave-devel +docs".

Attachments (1)

main.log (2.6 MB) - added by azurvii@… 7 years ago.
octave compiling log

Change History (9)

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

Cc: ryandesign@… added
Keywords: octave removed
Owner: changed from macports-tickets@… to michaelld@…
Port: octave-devel added

Could you attach the full main.log file please? It does sound ImageMagick-related but the log might give us more details.

Changed 7 years ago by azurvii@…

Attachment: main.log added

octave compiling log

comment:2 Changed 7 years ago by michaelld (Michael Dickens)

This is a duplicate of #40806, which was fixed to work with Clang and/or GCC. Please do the following:

sudo port -f uninstall GraphicsMagick
sudo port clean octave-devel
sudo port selfupdate
sudo port install octave-devel

and then hopefully all will be well.

comment:3 Changed 7 years ago by azurvii@…

It worked! Thank you Mike! So this is about GraphicsMagick instead.. This led me to another thinking -- it seems

sudo port seflupdate

does not identify GraphicsMagick as an outdated. Does it imply a bug in "port selfupdate"?

comment:4 Changed 7 years ago by michaelld (Michael Dickens)

Resolution: fixed
Status: newclosed

Great; you're welcome! There's no bug in "port selfupdate", though I'm tempted to rev-bump GraphicsMagick to force it to be rebuilt.

comment:5 Changed 7 years ago by ryandesign (Ryan Schmidt)

What is the change that requires GraphicsMagick to be rebuilt?

comment:6 Changed 7 years ago by michaelld (Michael Dickens)

The error when linking a library in octave is:

:info:build Undefined symbols for architecture x86_64:
:info:build   "Magick::CoderInfo::CoderInfo(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&)", referenced from:
:info:build       F__magick_format_list__(octave_value_list const&, int) in DLD_FUNCTIONS___magick_read___la-__magick_read__.o
:info:build ld: symbol(s) not found for architecture x86_64

I've no idea why, but for some reason rebuilding GraphicsMagick fixes the issue. We've tried just cleaning octave-devel, and a few other less-obvious things, but none work. What has worked reliably is rebuilding GraphicsMagick. As I said, I've no idea why.

comment:7 Changed 7 years ago by ryandesign (Ryan Schmidt)

Are you sure this isn't just because GraphicsMagick was built with clang, and therefore libc++ on Mavericks, whereas octave-devel defaults to using gcc48, and therefore libstdc++, and you cannot mix C++ runtimes within a single program? In #40806, of which this ticket was marked a duplicate, someone suggested reinstalling GraphicsMagick with gcc48, which would of course "fix" this problem for octave-devel while breaking every other program that wants to use GraphicsMagick, so that's not a viable solution. The only viable solutions I know of are 1) make octave-devel compile using clang or 2) make octave-devel no longer use GraphicsMagick.

comment:8 Changed 7 years ago by michaelld (Michael Dickens)

octave-devel builds all C/C++ code using the configure.compiler setting (for a few months now, I think); all fortran code is build using the selected variant's compiler. So, at least for -building- octave-devel and GraphicsMagick, it seems like so long as the same configure.compiler is selected then all should be well (and, it does seem to be the case). That said, at least on 10.8 I do find that libGraphicsMagick++.dylib links with Apple's libstdc++ while the octave-compiled __magick_read__.oct links with MacPorts' libstdc++, which should result in an error during runtime. Interestingly, I can do the following (in 10.8; with "foo.jpg" in the octave search path):

% octave
> foo = imread("foo.jpg");
> imshow(foo)

and it works. So .... not sure what's going on there since I would expect the runtime error. I think that this issue is complicated; maybe some of these people were the ones who rebuilt GraphicsMagick using configure.compiler=macports-gcc-4.X and thus just needed to re-rebuild? The bottom line for me is that rebuilding GraphicsMagick works, and at the end of the day all seems well between octave-devel and GraphicsMagick.

Note: See TracTickets for help on using tickets.