search for: gittup

...bc52e.o] and unordered [`.eh_frame' in /usr/lib/gcc/x86_64-linux-gnu/5.4.1/../../../x86_64-linux-gnu/crt1.o] sections /usr/local/bin/ld: final link failed: Bad value Looks it's code explicitly restricts mixing sections with link order flag and without: https://github.com/gittup/binutils/blob/gittup/bfd/elflink.c#L9991 With GNU gold (GNU Binutils 2.29.51.20171006) 1.14 have an assert: ~/LLVM/Release/bin/clang++ test.cpp -ffunction-sections -o test.o /usr/local/bin/ld: internal error in layout_eh_frame_section, at .././../gold/object.cc:1309 It is that place: https://githu...

...gold (GNU Binutils 2.29.51.20171006) 1.14 have an assert: >> ~/LLVM/Release/bin/clang++ test.cpp -ffunction-sections -o test.o >> /usr/local/bin/ld: internal error in layout_eh_frame_section, at >> .././../gold/object.cc:1309 >> It is that place: >> https://github.com/gittup/binutils/blob/gittup/gold/object.cc#L1372 >> Did not investigate it, but it looks it is place >> (https://sourceware.org/ml/binutils/2009-06/msg00097.html) >> mentioned in comment for >> https://marc.info/?l=llvm-commits&m=144683596826489. > >I've committed a p...

>Thank you for taking a look. I think that the answer depends on how much slower GNU linkers are with separate .eh_frame sections. If it is not too slow, it may make >sense to generate split .eh_frame sections unconditionally. Otherwise, we might want to add a new option so that clang doesn't produce split .eh_frame sections by >default. I'll start investigating the

...2.29.51.20171006) 1.14 have an assert: >>> ~/LLVM/Release/bin/clang++ test.cpp -ffunction-sections -o test.o >>> /usr/local/bin/ld: internal error in layout_eh_frame_section, at >>> .././../gold/object.cc:1309 >>> It is that place: >>> https://github.com/gittup/binutils/blob/gittup/gold/object.cc#L1372 >>> Did not investigate it, but it looks it is place >>> (https://sourceware.org/ml/binutils/2009-06/msg00097.html) >>> mentioned in comment for >>> https://marc.info/?l=llvm-commits&m=144683596826489. >> >&g...