#45483 closed defect (fixed)
gcc49: bug in libstdc++ when using std::complex
Reported by: | vsoftco@… | Owned by: | larryv (Lawrence Velázquez) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.3.2 |
Keywords: | Cc: | mww@… | |
Port: | gcc49 |
Description
The following produces a segfault when compiling with g++4.9.1 using libstdc++ that comes with it.
#include <complex> #include <iostream> int main() { std::complex<double> a{1,0}; std::cout << a.imag() << std::endl; // works fine std::cout << a << std::endl; // segfault }
Probably there is something related to ostream operator<< overloading for std::complex, although I cannot say for sure. However, the bug is extremely important, as it makes the whole std::complex part of the library unusable.
Attachments (1)
Change History (12)
comment:1 follow-up: 3 Changed 10 years ago by ryandesign (Ryan Carsten Schmidt)
Keywords: | gcc libstdc++ removed |
---|---|
Owner: | changed from macports-tickets@… to mww@… |
Priority: | High → Normal |
Summary: | bug in libstdc++ when using std::complex → gcc49: bug in libstdc++ when using std::complex |
comment:2 Changed 10 years ago by larryv (Lawrence Velázquez)
Cc: | larryv@… added |
---|
I can reproduce the segfault.
comment:3 follow-up: 4 Changed 10 years ago by vsoftco@…
Replying to ryandesign@…:
You should probably test if the problem remains in gcc5, and also report the problem to the developers of gcc. All we do at MacPorts is package the software they provide.
I tested the code with gcc4.9.1 from Homebrew (and using its libstdc++), and there is no segfault. I have also filled a bug with gcc, however it seems extremely strange that one version of gcc4.9.1 works and another one not.
Changed 10 years ago by larryv (Lawrence Velázquez)
Attachment: | yosemite-symbol-lookup.patch added |
---|
comment:4 follow-up: 5 Changed 10 years ago by larryv (Lawrence Velázquez)
I know what’s going on. The crash log looks uncomfortably familiar…
Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: EXC_I386_GPFLT Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libdyld.dylib 0x00007fff82b01432 stack_not_16_byte_aligned_error + 0
…because this is my old friend, the Libtool MACOSX_DEPLOYMENT_TARGET bug.
I’ve attached a preliminary patch. Could you try it?
% sudo port uninstall libgcc gcc49 && sudo port clean libgcc gcc49 % sudo port patch libgcc % curl https://trac.macports.org/raw-attachment/ticket/45483/yosemite-symbol-lookup.patch | sudo patch -p1 -d $(port work libgcc)/gcc-4.9.1 % sudo port install libgcc % sudo port patch gcc49 % curl https://trac.macports.org/raw-attachment/ticket/45483/yosemite-symbol-lookup.patch | sudo patch -p1 -d $(port work libgcc)/gcc-4.9.1 % sudo port install gcc49
comment:6 Changed 10 years ago by larryv (Lawrence Velázquez)
Cc: | mww@… added; larryv@… removed |
---|---|
Owner: | changed from mww@… to larryv@… |
I’ve pushed the change in r127092. Can you run selfupdate and try the new version (4.9.1_1)?
comment:7 Changed 10 years ago by larryv (Lawrence Velázquez)
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:9 follow-up: 10 Changed 10 years ago by vsoftco@…
I have a question, is the bug related to libgcc or to macports? If it's related to macports, I'll remove the bug I filled for g++. Thanks again for the great work in fixing it!
comment:10 Changed 10 years ago by larryv (Lawrence Velázquez)
It’s an upstream bug. The configure scripts in the distribution are based on the current Libtool, which uses incorrect linker flags when MACOSX_DEPLOYMENT_TARGET is set to “10.10”. We set that environment variable in our builds; Homebrew does not, which is why you didn’t observe the bug there.
Could you provide a link to the bug report you filed?
comment:11 Changed 10 years ago by larryv (Lawrence Velázquez)
Upstream PR: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63610
You should probably test if the problem remains in gcc5, and also report the problem to the developers of gcc. All we do at MacPorts is package the software they provide.