libcxx install location?

After failing to use libstdc++:
  http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-February/013216.html
I tried to understand how to use libc++:
  http://libcxx.llvm.org/
Although that libcxx page mentions:
  clang++ -stdlib=libc++ test.cpp
there's no mention of this opton here:
  http://clang.llvm.org/docs/UsersManual.html#commandline
Also, that libcxx page makes no mention of:
  http://llvm.org/svn/llvm-project/cfe/trunk/runtime/libcxx/Makefile
However, seeing:
  LIBCXX_SRC_ROOT := $(LLVM_SRC_ROOT)/projects/libcxx
  CPP.Flags := -nostdinc++ -I$(LIBCXX_SRC_ROOT)/include
in that Makefile, suggests that maybe one option is to install libcxx
below my svn working directory:
  ~/download/llvm/svn/llvm/tools/clang/runtime
with something like:
  svn co http://llvm.org/svn/llvm-project/libcxx/trunk libcxx
from within that svn working directory. In that case, would there be
any need for the -stdlib=libc++ option to clang++? But then what
arguments should I pass ~/download/llvm/svn/llvm/configure to cause
the libcxx library to be built? Grepping that configure for libcxx
showed nothing.

TIA for any help.

-regards,
Larry

Did you had a look at this thread:

http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-January/013017.html

-- Jean-Daniel

[snip]

Also, that libcxx page makes no mention of:
http://llvm.org/svn/llvm-project/cfe/trunk/runtime/libcxx/Makefile
However, seeing:
LIBCXX_SRC_ROOT := $(LLVM_SRC_ROOT)/projects/libcxx
CPP.Flags := -nostdinc++ -I$(LIBCXX_SRC_ROOT)/include

[snip]

Did you had a look at this thread:

http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-January/013017.html

Yes, but I'd rather not mess with /usr/lib or /usr/include if it
can be avoided, and the mentioned trunk/runtime/libcxx/Makefile
suggested maybe there's another way which avoids messing with /usr.

-Larry

I went ahead and did as:

  http://libcxx.llvm.org/http://libcxx.llvm.org/http://libcxx.llvm.org/

and added symlinks from /usr/lib and /usr/include/c++. It compiled OK;
however, the link failed with:

make compile
ls -ld /usr/lib/libc++*
lrwxrwxrwx 1 root root 69 Feb 5 07:09 /usr/lib/libc++.so ->
/home/evansl/download/llvm/svn/llvm/projects/libcxx/lib/libc++.so.1.0
ls -ld /usr/include/c++/v1
lrwxrwxrwx 1 root root 59 Feb 5 07:14 /usr/include/c++/v1 ->
/home/evansl/download/llvm/svn/llvm/projects/libcxx/include
/home/evansl/download/llvm/svn/build/Debug+Asserts/bin/clang++
-stdlib=libc++ move.cpp -o move.exe
/usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib64/libc++.so:
undefined reference to `__cxa_free_exception'
/usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib64/libc++.so:
undefined reference to `__cxa_begin_catch'
/usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib64/libc++.so:
undefined reference to `__cxa_guard_release'
...

I didn't link to path-to-libcxx/lib/libc++.1.dylib
because there was no such file. Instead, I figured
that was a MacOS convention for shared libs; so,
I substituted the only likely file in the target
directory:

  libc++.so.1.0

Now I did *not* do the download and install of:

  http://home.roadrunner.com/~hinnant/libcppabi.zip

because the webpage:

  http://libcxx.llvm.org/

said:

  To build on Mac OS X 10.6, you need a helper library and header found
  here. cp cxxabi.h to /usr/include, and cp libc++abi.dylib to
  /usr/lib.

and I'm on ubuntu, not Mac OS X.

Am I missing something?

TIA.

-Larry

I don't have access to my linux machine right now, so I cannot test, but I think you can link on libstdc++ to get the missing symbols (just adding -lstdc++ to the linker flags should be enough).

It should not conflict with libc++ symbols as libc++ uses inline namespace, and so mangle the standard symbols differently than the libstdc++.

This is what we use to do on OS X before we got a separate libc++abi library.

-- Jean-Daniel

[snip]

Am I missing something?

I don't have access to my linux machine right now, so I cannot test, but I think you can link on libstdc++ to get the missing symbols (just adding -lstdc++ to the linker flags should be enough).

It should not conflict with libc++ symbols as libc++ uses inline namespace, and so mangle the standard symbols differently than the libstdc++.

This is what we use to do on OS X before we got a separate libc++abi library.

-- Jean-Daniel

Thanks Jean; however, I'm getting the same error:

make compile
/home/evansl/download/llvm/svn/build/Debug+Asserts/bin/clang++ -c
-stdlib=libc++ move.cpp -o move.o
/home/evansl/download/llvm/svn/build/Debug+Asserts/bin/clang++
-stdlib=libc++ -lstdc++ move.o -o move.exe
/usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib64/libc++.so:
undefined reference to `__cxa_free_exception'
/usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib64/libc++.so:
undefined reference to `__cxa_begin_catch'
/usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib64/libc++.so:
undefined reference to `__cxa_guard_release'
...

-Larry

-lstdc++ must be after move.o

OK. In fact, you have to add this flag to the libc++ LDFLAGS (in buildit script).
Make sure to also add -std=c++0x to the cflags to enable latest clang enhancements.

EXTRA_FLAGS="-std=c++0x"
LDSHARED_FLAGS="-o libc++.so.1.0
-shared -nodefaultlibs -Wl,-soname,libc++.so.1
-lpthread -lrt -lc -lstdc++"

As the library soname is libc++.so.1, you have to create a /usr/lib/libc++.so.1 symlink that point to the library. Else you will get a “library not found” runtime error.

After theses changes, I was able to compile a simple hello world program.

--------- hello.cpp

#include

int main (int argc, char * const argv[]) {
// insert code here…
std::cout << “Hello, World!\n”;
return 0;
}

OK, but it must be something else, because:

/home/evansl/download/llvm/svn/build/Debug+Asserts/bin/clang++ -c
-stdlib=libc++ move.cpp -o move.o
/home/evansl/download/llvm/svn/build/Debug+Asserts/bin/clang++ move.o
-stdlib=libc++ -lstdc++ -o move.exe
/usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib64/libc++.so:
undefined reference to `__cxa_free_exception'
/usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib64/libc++.so:
undefined reference to `__cxa_begin_catch'
...

I really appreciate the help Jean-Daniel!

I did make the changes you suggested to the buildit, then
invoked buildit, then added the symlink; however, now
the compiler can't find the just created libc++ :frowning:

/usr/lib $ sudo ln -sf
/home/evansl/download/llvm/svn/llvm/projects/libcxx/lib/libc++.so.1.0
libc++.so.1.0
/usr/lib $ ls -ld libc++*
lrwxrwxrwx 1 0 0 69 Feb 5 09:50
libc++.so.1.0 ->
/home/evansl/download/llvm/svn/llvm/projects/libcxx/lib/libc++.so.1.0
/usr/lib $ pushd
~/prog_dev/clang $ make compile
/home/evansl/download/llvm/svn/build/Debug+Asserts/bin/clang++ -c
-stdlib=libc++ move.cpp -o move.o
/home/evansl/download/llvm/svn/build/Debug+Asserts/bin/clang++ move.o
-stdlib=libc++ -lstdc++ -o move.exe
/usr/bin/ld: cannot find -lc++
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
make: *** [compile] Error 1
~/prog_dev/clang $ pushd
/usr/lib $ pushd /home/evansl/download/llvm/svn/llvm/projects/libcxx/lib
~/download/llvm/svn/llvm/projects/libcxx/lib $ rcsdiff buildit

should be

cd /usr/lib
sudo ln -sf /home/evansl/download/llvm/svn/llvm/projects/libcxx/lib/libc++.so.1.0 libc++.so
sudo ln -sf /home/evansl/download/llvm/svn/llvm/projects/libcxx/lib/libc++.so.1.0 libc++.so.1

You need a libc++.so symlink to compile (that what the static linker expects), and a libc++.so.1 (no .0 here) symlink to run your program (that what the dynamic linker is looking for).

-- Jean-Daniel

Thank you!

/usr/lib $ sudo ln -sf
/home/evansl/download/llvm/svn/llvm/projects/libcxx/lib/libc++.so.1.0
libc++.so

/usr/lib $ sudo ln -sf
/home/evansl/download/llvm/svn/llvm/projects/libcxx/lib/libc++.so.1.0
libc++.so.1

/usr/lib $ pushd
~/prog_dev/clang $ make compile
/home/evansl/download/llvm/svn/build/Debug+Asserts/bin/clang++ -c
-stdlib=libc++ move.cpp -o move.o
/home/evansl/download/llvm/svn/build/Debug+Asserts/bin/clang++ move.o
-stdlib=libc++ -lstdc++ -o move.exe
./move.exe
~/prog_dev/clang $

[snip]

After theses changes, I was able to compile a simple hello world program.

--------- hello.cpp
#include <iostream>

int main (int argc, char * const argv) {
    // insert code here...
    std::cout << "Hello, World!\n";
    return 0;
}
------------------------

Unfortunalty, this simple code does not run properly. It prints "Hello
World", and then a lot of garbage (and sometimes segfault too).

But this may be a good base to start hacking on libc++.

The attached code, with:

  #define EMTPY_STDOUT_STR

runs OK; however, with:

  //#define EMTPY_STDOUT_STR

it prints the "?" followed by a bunch of garbage just like you
describe.

I did try gdb and after a *lot* of stepping through many statement,
finished with:

(gdb) s
std::__1::__stdoutbuf<char>::sync (this=<value optimized out>) at
../include/__std_stream:202
(gdb) s
(gdb) s
Line number 287 out of range; ../src/iostream.cpp has 53 lines.
(gdb) s
std::__1::codecvt<char, char, __mbstate_t>::unshift (this=<value
optimized out>) at ../include/__locale:745
(gdb) s
Die: DW_TAG_restrict_type (abbrev 191, offset 0xf53ba)
  parent at offset: 0x79b11
  has children: FALSE
  attributes:
    DW_AT_type (DW_FORM_ref4) constant ref: 0x94ec8 (adjusted)
Die: DW_TAG_restrict_type (abbrev 191, offset 0xf53ba)
  parent at offset: 0x79b11
  has children: FALSE
  attributes:
    DW_AT_type (DW_FORM_ref4) constant ref: 0x94ec8 (adjusted)
Dwarf Error: Cannot find type of die [in module /usr/lib/libc++.so.1]
(gdb)

After that, tried further stepping; however, nothing changed so I
finally had to kill it.

I don't know what to conclude from that, but maybe others can
glean some useful information and hopefully provide some
suggestions about how to find the problem.

-Larry

cout.cpp (168 Bytes)

[snip]
This problem had already been reported as a bug here:

http://llvm.org/bugs/show_bug.cgi?id=8992