#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 Carsten 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)
Change History (9)
comment:1 Changed 11 years ago by ryandesign (Ryan Carsten Schmidt)
Cc: | ryandesign@… added |
---|---|
Keywords: | octave removed |
Owner: | changed from macports-tickets@… to michaelld@… |
Port: | octave-devel added |
comment:2 Changed 11 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 11 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 11 years ago by michaelld (Michael Dickens)
Resolution: | → fixed |
---|---|
Status: | new → closed |
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 11 years ago by ryandesign (Ryan Carsten Schmidt)
What is the change that requires GraphicsMagick to be rebuilt?
comment:6 Changed 11 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 11 years ago by ryandesign (Ryan Carsten 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 11 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.
Could you attach the full main.log file please? It does sound ImageMagick-related but the log might give us more details.