OT: Problem building libc++

[woodb...@gmail.com]

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

[woodb...@gmail.com]

On Thursday, February 20, 2014 5:00:24 PM UTC-6, woodb...@gmail.com wrote:
>
> 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.

[woodb...@gmail.com]

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

[Scott Lurndal]

woodb...@gmail.com writes:
>
>I was following these instructions
>
>http://solarianprogrammer.com/2013/01/17/building-clang-libcpp-ubuntu-linux/

>http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CCYQFjAA&url=http%3A%2F%2Fwiki.osdev.org%2FLibsupcxx&ei=o2YHU72EO4ex2wX2koDAAQ&usg=AFQjCNF6KTOFeb5SBX6SBywdREYfhy63ng

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

scott

[woodb...@gmail.com]

On Friday, February 21, 2014 8:50:41 AM UTC-6, Scott Lurndal wrote:

> >http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CCYQFjAA&url=http%3A%2F%2Fwiki.osdev.org%2FLibsupcxx&ei=o2YHU72EO4ex2wX2koDAAQ&usg=AFQjCNF6KTOFeb5SBX6SBywdREYfhy63ng
>
> 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.

[woodb...@gmail.com]

On Saturday, February 22, 2014 2:01:50 PM UTC-6, woodb...@gmail.com wrote:

>
> 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

[Scott Lurndal]

woodb...@gmail.com writes:
>On Saturday, February 22, 2014 2:01:50 PM UTC-6, woodb...@gmail.com wrote:
>
>>
>> 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?

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).

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.

An example:

struct AHCIDevice {
struct IDEBus port; /* 0 1696 */

/* XXX last struct has 4 bytes of padding */

/* --- cacheline 26 boundary (1664 bytes) was 32 bytes ago --- */
uint32_t state; /* 1696 4 */
uint32_t finished; /* 1700 4 */
struct AHCIPortRegs reg; /* 1704 68 */

/* XXX 4 bytes hole, try to pack */

/* --- cacheline 27 boundary (1728 bytes) was 48 bytes ago --- */
uint64_t lst; /* 1776 8 */
uint64_t res_fis; /* 1784 8 */
/* --- cacheline 28 boundary (1792 bytes) --- */
int done_atapi_packet; /* 1792 4 */
int init_d2h_sent; /* 1796 4 */
class AHCICmdHdr * cur_cmd; /* 1800 8 */
struct AHCICmdHdr cur_cmd_buf; /* 1808 32 */

/* size: 1840, cachelines: 29, members: 10 */
/* sum members: 1836, holes: 1, sum holes: 4 */
/* paddings: 1, sum paddings: 4 */
/* last cacheline: 48 bytes */
};

[woodb...@gmail.com]

On Monday, February 24, 2014 9:19:02 AM UTC-6, Scott Lurndal wrote:

> woodb...@gmail.com writes:
>
> >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?

> 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

[Scott Lurndal]

woodb...@gmail.com writes:
>On Monday, February 24, 2014 9:19:02 AM UTC-6, Scott Lurndal wrote:
>> woodb...@gmail.com writes:
>>
>> >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?
>
>> 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.

Not really, I could care less about the size of a binary.

The layout of data in memory, however, is important in the types
of applications I write - where cache pressure is significant
and there are high levels of concurrency (dozens to hundreds of threads
on systems with 10s to 100's of cores).

>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.

Actually, that could be a really bad idea for multithreaded
applications if multiple threads need that same cache line.

You really want run-time profiling tool help for this problem
(e.g. oprofile/prof).

>
>
>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.

See, that's what I call obsessive :-)

Pick a compiler and stick with it.

[Öö Tiib]

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).

[woodb...@gmail.com]

On Wednesday, February 26, 2014 10:45:47 AM UTC, Öö Tiib wrote:
> On Tuesday, 25 February 2014 16:55:47 UTC+2, Scott Lurndal wrote:
> > woodb...@gmail.com writes:

>
> > >So it was easy to switch between the two. Now it's
> > >kind of troublesome.
>
> >
> > 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.
>

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