Can you try and go ahead and build one with clang right out of the svn? The appropriate order from my experience, starting from a clean machine with only gcc (experimented on a VM running vanilla Ubuntu 13.04):
LLVM+clang, use C++98 libc++rt, CC=clang, CXX=clang++ libc++, CC=clang, CXX=clang++, LDFLAGS+=-lc++rt LLVM+clang+lldb, CC=clang, CXX=clang++, CXXFLAGS+="-std=c++11 -stdlib=libc++", LDFLAGS+="-stdlib=libc++ -lc++rt" libobjc2, CC=clang, CXX=clang++, CXXFLAGS+="-std=c++11 -stdlib=libc++", LDFLAGS+="-stdlib=libc++ -lc++rt" libdispatch, CC=clang, CXX=clang++, CXXFLAGS+="-std=c++11 -stdlib=libc++", LDFLAGS+="-stdlib=libc++ -lc++rt -lobjc" libobjc2, CC=clang, CXX=clang++, CXXFLAGS+="-std=c++11 -stdlib=libc++", LDFLAGS+="-stdlib=libc++ -lc++rt -ldispatch" This will bootstrap LLVM/clang properly with lldb support (the debugger, requires C++11 to build), with libraries: * libc++rt LLVM C++ ABI library, * libc++ LLVM C++ standard library (linked against libc++rt explicitly, fixing the clang bug of not linking against the appropriate C++ ABI library), * libobjc2 GNUstep Objective-C runtime library, doubling as the sole Blocks runtime library and linked against libdispatch. (Since I already have libobjc2 and pretty much there is no non-Objective-C code uses Blocks, I just used that to save the hassle) * libdispatch Grand Central Dispatch. And if you linker (and friends) supports LTO, you can build LLVM+clang+lldb (2nd pass), libc++, libobjc2 and libdispatch with optimizations full on (-O4 -flto, including LTO) and that will result in binaries running really fast. As a funny side note, the only time my libobjc2 test passed 100% is when I built it with optimizations full on. 在 2013-6-13，上午8:25，Frank Rehwinkel <[email protected]> 写道： > This thread is about the same problem with FreeBSD 9.1 back in March. > > http://lists.gnu.org/archive/html/gnustep-dev/2013-03/msg00127.html > > The solution seems to be to build libcxxrt. > > But how? When I try to follow this instruction > > I've put MK_LIBCPLUSPLUS = yes in /etc/make.conf now. > > and cd to /usr/src/lib/libcxxrt/ but then make fails with > > root@free91:/usr/src/lib/libcxxrt # make > "/usr/share/mk/bsd.own.mk", line 478: MK_LIBCPLUSPLUS can't be set by a user. > > So I just don't know how to get this library built. Not as simple as getting > a port compiled I guess. > > > > On Wed, Jun 12, 2013 at 7:07 PM, Frank Rehwinkel <[email protected]> > wrote: > libsupc++.a does have symbols in it. > nm -g reports no symbols on libsupc++.so.1. > > > On Wed, Jun 12, 2013 at 6:52 PM, Maxthon Chan <[email protected]> wrote: > Oh it just hit me - maybe you want libsupc++.a instead of .so, which (may) > ask for libc++ to build. > > I used to simply force linking libobjc2 against libc++ but that tend to make > app load a little slower and consume some more memory (and then defeat this > performance penalty by enforcing link-time optimization in Base and GUI). > > 在 2013-6-13，上午6:48，Frank Rehwinkel <[email protected]> 写道： > >> I've checked the libsupc++ libraries are the same on the host as in the >> jail. Same sizes, same symbolic links. >> >> >> On Wed, Jun 12, 2013 at 6:39 PM, David Chisnall <[email protected]> wrote: >> >> On 12 Jun 2013, at 23:35, Frank Rehwinkel <[email protected]> wrote: >> >> > -- Using /usr/lib/libsupc++.so as the C++ runtime library >> >> Hmm, this should work. The C++ runtime symbols are missing from this >> library? >> >> David >> >> -- Sent from my Apple II >> >> > > >
_______________________________________________ Gnustep-dev mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnustep-dev
