Open Amavect opened 3 years ago
Same on Arch when building from the cctools-git AUR package. I had to edit the PKGBUILD and add CFLAGS='-U_GLIBCXX_ASSERTIONS'
and CXXFLAGS='-U_GLIBCXX_ASSERTIONS'
to the configure line to get it to work properly (it would probably work without the CFLAGS change, leaving only CXXFLAGS modified).
Same on Arch when building from the cctools-git AUR package. I had to edit the PKGBUILD and add
CFLAGS='-U_GLIBCXX_ASSERTIONS'
andCXXFLAGS='-U_GLIBCXX_ASSERTIONS'
to the configure line to get it to work properly (it would probably work without the CFLAGS change, leaving only CXXFLAGS modified).
Confirmed. With these envvars in place I managed to build osxcross
on Arch. Thanks a lot!
I'm trying to build osxcross for Artix Linux. The build worked, but when it got to testing the compilers, it failed:
Not a very helpful error message. Something to do with std::vector.
Here's the output with -v to see invocation.
The issue lies in the linker, ld64. It compiles, but calls an assert when running.
Compiling with debug symbols and running GDB to get a stack trace:
And finally we can see the issue.
The following code in
mach_o::relocatable::Atom<x86_64>::fixupsEnd at macho_relocatable_file.cpp:763
has the issue:Because C++ is annoying, this is not an array access. It calls the following in
std::allocator<ld::Fixup> >::operator[] at stl_vector.h:1045
__glibcxx_requires_subscript
is obviously a macro, indebug/assersions.h
Which is the end of the problem.
So, what's going on is that my system defines _GLIBCXX_ASSERTIONS by default. This issues a bounds check when
fixupsEnd()
calls the[]
operator. That obviously fails because_fixupsStartIndex+_fixupsCount
is one-off the last valid index.Of course, we're taking the & of it, so it's never been a problem. However, the documentation says that
out_of_range lookups are not defined
. A quick search gives this mailing-list discussion: https://www.mail-archive.com/gcc-bugs@gcc.gnu.org/msg619891.htmlI've found a workaround, namely replacing each
&vec[n]
with(vec.begin()+n).base()
so it no longer asserts. It feels very kludgy, though. Also, this is especially a problem because the&vec[n]
idiom is used everywhere in ld64's code. And who knows when it's actually a pointer that just needsptr+n
.file -type f | xargs grep '\&.*\[' | wc
gets at least 1500 lines.I'm not much of a C++ programmer, so before I try to manually replace each instance, what are your thoughts? I would prefer to keep _GLIBCXX_ASSERTIONS enabled, since that is "correct". Is there a better way than replacing with begin() and base()? I'm willing to dig through and change everything.