OT: Problem building libc++

[woodbrian77]

I was following these instructions

http://solarianprogrammer.com/2013/01/17/building-clang-libcpp-ubuntu-linux/

but have a problem when I get to building libc++.

Linking CXX shared library libc++.so
/usr/bin/ld: cannot find -lsupc++


I tried:

find / -type f -name "*supc++*" -print

but it didn't find any files that matched that.

I searched on https://duckduckgo.com and bing for
some ideas, but haven't found the answer.

What do you suggest? Thanks in advance.

Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net

 

[woodbrian77]

I tried:

find / -type f -name "*supc++*" -print

Just tried that without the + signs

find / -type f -name "*supc*" -print

and it still doesn't find anything.

 

[woodbrian77]

This thread looks helpful;

http://www.code-aster.org/forum2/viewtopic.php?id=16173

I'm not at work now so haven't tried it

 

[woodbrian77]

http://webcache.googleusercontent.com/search?q=cache:4D214uOlD3QJ:wiki.osdev.org/Libsupcxx+

$ locate libsup
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/libsupc++.a

OK, thanks. I looked at that and wasn't making much
progress with it so I decided to install Arch linux.
That was a little bit of a pain, but I got it and
it has clang 3.4 as it's default version.

 

[woodbrian77]

OK, thanks. I looked at that and wasn't making much
progress with it so I decided to install Arch linux.
That was a little bit of a pain, but I got it and
it has clang 3.4 as it's default version.

This tripped me up so am adding a note about it here.

It wasn't enough to do

pacman -S clang

.. I also had to do

pacman -S libc++

and link with libc++abi (-lc++abi)
..

Tomorrow I may try installing gcc 4.9. Previously
when installing a gcc snapshot, I'd install gmp,
mpfr and mpc. Now it looks like there's another
library called "elf" that needs to be installed?


Brian
Ebenezer Enterprises - Remembering the Alamo.
http://webEbenezer.net

 

[woodbrian77]

gcc and binutils should go together, generally.

I believe most of the ELF stuff (Extensible Linking Format)
is part of elfutils package(s). You also might find the dwarves
package useful (pahole, in particular, as you seem to be
obsessive about the size of your binary).

I'm not the only one who cares about these things.

pahole will display the layout in memory of a class, showing holes
caused by alignment. It may lead you to group all your 'bool'
variables together (uint64_t, bool, uint64_t, bool, uint64_t) will
waste 14 bytes in every object containing those 5 fields, for example,
while (uint64_t, uint64_t, uint64_t, bool, bool) won't.

You're preaching to the choir on that. Birds of a
feather flock together. I know also that Andrei A.
talks about putting "hot" members (members that are
used a lot) close to each other so they will fit in
a few cachelines. That seems like something to
consider also.


I downloaded the gcc 4.9 snapshot and built and
installed it on the same machine I have clang 3.4 on.
Gcc seems to be working fine, but I can only get
clang to work when I specify -stdlib=libc++ and
-lc++abi.

Previously all I had to do to switch from gcc to
clang was uncomment this line:

#CXX=clang++

So it was easy to switch between the two. Now it's
kind of troublesome.


Brian
Ebenezer Enterprises
http:/webEbenezer.net

 

[Öö Tiib]

See, that's what I call obsessive

Pick a compiler and stick with it.

There are different problem domains. For some software it is
fine advice I guess. For what Brian does it it feels not that good
advice. Reason is that one of Brian's key requirements is
portability.

I have used different compilers (up to 3) as tools of additional
automatic diagnosing even where portability is not required. It
is cheap to set up compiling and running the unit-tests
automatically on several compilers in continuous integration
(if there already are named things anyway).

The differences tend to come up from dim regions of C++
language as rule. Such code (that fails or runs depending on
compiler) can be correct for language lawyer; still it is always
better idea to rewrite it. C++ compilers feel to be among
smartest tools in human disposal and if some of those do not
parse a piece of code then very high chances are that next
human engineer who reads it is stuck with it as well (and that
is expensive).

 

[woodbrian77]

There are different problem domains. For some software it is
fine advice I guess. For what Brian does it it feels not that good
advice. Reason is that one of Brian's key requirements is
portability.

Portability is important for C++ and C. It's
important for me also. There's development and
testing. I've tended to think I could use gcc
or clang freely in either context. It may be
that I'll have to pick one of those compilers
for development and tell users to also use that
compiler when building the parts that run on
their systems. But for testing there's more
latitude and the use of multiple compilers
seems like a good thing. The outermost part of
my software is the code that's generated by the
back tier. The second most outermost would be
my library. Those are the pieces that most need
to be portable. After that the front tier and
after that the middle tier. I think it's the
back tier and middle tier, in particular, that
may need to be built by the same, not necessarily
the exact same version, compiler. I don't know:
it still seems odd to think that way because
there's a TCP connection between those two tiers.
How could it matter what compiler is used?

I also think open code generation is important --

http://www.sciencenet.se/converis/publicweb/contract/16447

I have used different compilers (up to 3) as tools of additional
automatic diagnosing even where portability is not required. It
is cheap to set up compiling and running the unit-tests
automatically on several compilers in continuous integration
(if there already are named things anyway).

I use GCC, Clang and Visual Studio. Each of them has
been helpful in pointing things out that I was missing.

The differences tend to come up from dim regions of C++
language as rule. Such code (that fails or runs depending on
compiler) can be correct for language lawyer; still it is always
better idea to rewrite it. C++ compilers feel to be among
smartest tools in human disposal and if some of those do not
parse a piece of code then very high chances are that next
human engineer who reads it is stuck with it as well (and that
is expensive).

Brian
Ebenezer Enterprises
http://webEbenezer.net