Am 18.11.2013 23:30, schrieb Dimitry Andric: > On 18 Nov 2013, at 23:25, Matthias Andree <mand...@freebsd.org> wrote: >> Am 18.11.2013 23:04, schrieb Dimitry Andric: >> >>> I will have a look at the port meanwhile, I hope it does not pull in too >>> many dependencies? >> >> Thanks for the prompt response. Trying top-of-clang-tree will take me a >> few days until I get around to it (is clang-devel good enough for a >> first attempt?) > > Can you please run the ipsharpen.cc compilation command with -save-temps > added on your system, and then upload the resulting .ii file somewhere? > > That would save me the trouble of building most of GNOME, which it seems > to pull in... :)
Uploaded. http://people.freebsd.org/~mandree/ has: <http://people.freebsd.org/~mandree/ipsharpen.ii.xz>: the xzipped .ii file (unpacked: 6.5 MB) <http://people.freebsd.org/~mandree/ipsharpen-compile%2bwarnings.txt>: compiler command line (make VERBOSE=1 MAKE_JOBS_UNSAFE=yes) and early warnings. It is still compiling, and these are the files in the working dir. work/rawtherapee-4.0.11/rtengine/ipsharpen.cc work/.build/rtengine/ipsharpen.ii work/.build/rtengine/ipsharpen.s-40cd6fd9 -O1, -Oz complete in c. 5 seconds, -Os require 5.6 s on my processor. -O2 has now spent more than 510 s I haven't dared -O3. I got: $ size work/.build/rtengine/CMakeFiles/rtengine.d text data bss dec hex filename 414247 16 168 414431 652df work/.build/rtengine/CMakeFiles/rtengine.dir/ipsharpen.cc.o and the .s file has also been xziped and uploaded to the URL above. (unpacked 3.5 MB). >> (Oh, and I wish we had more prominent error messages telling about an >> ABI mismatch between libc++ and libstdc++ than just the innocuous >> undefined references about - roughly - >> Glib::ustring::ustring(std::basic_string<> const &) - I needed to nm -sC >> the glibmm-2.0.so to figure out it provided the std::_1:: namespace >> stuff for c++ and finally figure out the libraries were alright but they >> were using the libc++ ABI rather than GCC's libstdc++.) > > Most of the time, you will only find out at link time if you have mixed > libstdc++ and libc++ STL containers... I'm not sure if there is a nicer > way to bring bad news. :-) Glib shares the fate, because it defers to std:: containers where possible. A nice way would require additional work and get the linkers to complain that symbols resolve with a different, incompatible ABI. That would, however, require second-guessing other ABIs and namespaces, and would hardly be portable -- or add ABI versions into the object files and .a and .so libraries, unless we already have ABI tags somewhere down deep in the ELF stuff. I never checked.
signature.asc
Description: OpenPGP digital signature
