Re: __gnu_cxx error in OpenSolaris

Re: __gnu_cxx error in OpenSolaris

[Dennis Clarke]

>
>>I have had good results for both Sparc and i386/AMD64 with or without
> gas
>>( GNU as ) however you must always use Sun provided LD=/usr/ccs/bin/ld
> if
>>you want things to work.
>
> Yes but I have forgot to say that I have tried with the Solaris ld and
> the result
> was in essence the same. Also,
>
> $ elfdump -s /usr/lib/libstdc++.so.6.0.14|grep gnu_cxx
>
> shows that the sumbols are included in the library!
>
> BTW, have you compiled the latest Qt with gcc? You know solaris
> studio is not an option as most useful programs do not compile
> with it.

Yeah I have hit that issue myself over and over to a point where I gave up
on Sun Studio. Such is life.

As for QT , well I have not tried in a while.

Stick with GCC and you will be happy.

-- 
Dennis Clarke
dclarke@opensolaris.ca  <- Email related to the open source Solaris
dclarke@blastwave.org   <- Email related to open source for Solaris

Re: __gnu_cxx error in OpenSolaris

[Dr. David Kirkby]

On 05/18/11 10:09 PM, Dennis Clarke wrote:
>
>>
>>> I have had good results for both Sparc and i386/AMD64 with or without
>> gas
>>> ( GNU as ) however you must always use Sun provided LD=/usr/ccs/bin/ld
>> if
>>> you want things to work.
>>
>> Yes but I have forgot to say that I have tried with the Solaris ld and
>> the result
>> was in essence the same. Also,
>>
>> $ elfdump -s /usr/lib/libstdc++.so.6.0.14|grep gnu_cxx
>>
>> shows that the sumbols are included in the library!
>>
>> BTW, have you compiled the latest Qt with gcc? You know solaris
>> studio is not an option as most useful programs do not compile
>> with it.
>
> Yeah I have hit that issue myself over and over to a point where I gave up
> on Sun Studio. Such is life.
>
> As for QT , well I have not tried in a while.
>
> Stick with GCC and you will be happy.

That's if you want to write in GNU C++ and don't care about writing standard C++ 
code.

GCC is useful, but it is the cause of a lot of badly written code.

-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Re: __gnu_cxx error in OpenSolaris

[Jonathan Wakely]

On 19/05/2011, Dr. David Kirkby wrote:
> On 05/18/11 10:09 PM, Dennis Clarke wrote:
>> Stick with GCC and you will be happy.
>
> That's if you want to write in GNU C++ and don't care about writing standard
> C++
> code.

(While we're making gross generalisations...) Every compiler with a
significant user base creates ghettos of non-portable code.

I'm curious what you consider to be "GNU C++" because there are fewer
and fewer non-standard constructs accepted, and the trend is generally
to remove support for them not encourage them.

> GCC is useful, but it is the cause of a lot of badly written code.

That can be said about nearly any compiler that's used to write a lot
of code, and I'm sure you know what they say about bad workmen and
their tools.

Re: __gnu_cxx error in OpenSolaris

[asyropoulos]

>It's not impossible at all, clang, gcc and icc use a common C++ ABI
>and should be link-compatible

Well my experience says that this does not work with gcc and solstudio.

>You've picked the wrong person to complain about C++ too so let's

No I don't complain to you but I complained through your message :-)

>ignore that ... you didn't say whether you looked at the libstdc++.so
>libs in /opt/gcc-4.6.0 and whether any of them use ELF symbol
>versioning, which might make them incompatible.

I have compiled Qt with gcc 4.5.3 and 4.6.0 and now I am trying again
with 4.6.0 that has been configured to use GNU ld and GNU as. As about
the versioning thing I am not sure what you mean, bur I hope the 
following help:

$ elfdump -v /usr/lib/libstdc++.so.6.0.14

Version Needed Section:  .SUNW_version
     index  file                        version
       [2]  libm.so.2                   SUNW_1.2
       [3]  libgcc_s.so.1               GCC_3.0              [ INFO ]
       [4]                              GCC_3.3              [ INFO ]
       [5]                              GCC_4.2.0

$ elfdump -v /opt/gcc-4.6.0/lib/libstdc++.so.6.0.15

Version Definition Section:  .SUNW_version
     index  version                     dependency
       [1]  libstdc++.so.6                                   [ BASE ]
       [2]  GLIBCXX_3.4
       [3]  GLIBCXX_3.4.1               GLIBCXX_3.4
       [4]  GLIBCXX_3.4.2               GLIBCXX_3.4.1
       [5]  GLIBCXX_3.4.3               GLIBCXX_3.4.2
       [6]  GLIBCXX_3.4.4               GLIBCXX_3.4.3
       [7]  GLIBCXX_3.4.5               GLIBCXX_3.4.4
       [8]  GLIBCXX_3.4.6               GLIBCXX_3.4.5
       [9]  GLIBCXX_3.4.7               GLIBCXX_3.4.6
      [10]  GLIBCXX_3.4.8               GLIBCXX_3.4.7
      [11]  GLIBCXX_3.4.9               GLIBCXX_3.4.8
      [12]  GLIBCXX_3.4.10              GLIBCXX_3.4.9
      [13]  GLIBCXX_3.4.11              GLIBCXX_3.4.10
      [14]  GLIBCXX_3.4.12              GLIBCXX_3.4.11
      [15]  GLIBCXX_3.4.13              GLIBCXX_3.4.12
      [16]  GLIBCXX_3.4.14              GLIBCXX_3.4.13
      [17]  GLIBCXX_3.4.15              GLIBCXX_3.4.14
      [18]  CXXABI_1.3
      [19]  CXXABI_1.3.1                CXXABI_1.3
      [20]  CXXABI_1.3.2                CXXABI_1.3.1
      [21]  CXXABI_1.3.3                CXXABI_1.3.2
      [22]  CXXABI_1.3.4                CXXABI_1.3.3
      [23]  CXXABI_1.3.5                CXXABI_1.3.4

Version Needed Section:  .SUNW_version
     index  file                        version
      [24]  libm.so.2                   SUNW_1.2
      [25]  libc.so.1                   SUNW_1.22
      [26]                              SUNW_1.18            [ INFO ]
      [27]                              SUNW_1.1             [ INFO ]
      [28]                              SUNW_0.9             [ INFO ]
      [29]                              SUNW_0.7             [ INFO ]
      [30]                              SUNWprivate_1.1
      [31]                              SYSVABI_1.3          [ INFO ]
      [32]  libgcc_s.so.1               GCC_3.0              [ INFO ]
      [33]                              GCC_3.3              [ INFO ]
      [34]                              GCC_4.2.0

Regards,

Apostolos

Re: __gnu_cxx error in OpenSolaris

[Jonathan Wakely]

On 19 May 2011 15:03,  <asyropoulos@aol.com> wrote:
>
>> ignore that ... you didn't say whether you looked at the libstdc++.so
>> libs in /opt/gcc-4.6.0 and whether any of them use ELF symbol
>> versioning, which might make them incompatible.
>
> I have compiled Qt with gcc 4.5.3 and 4.6.0 and now I am trying again
> with 4.6.0 that has been configured to use GNU ld and GNU as. As about
> the versioning thing I am not sure what you mean, bur I hope the following
> help:
>
> $ elfdump -v /usr/lib/libstdc++.so.6.0.14
>
> Version Needed Section:  .SUNW_version
>    index  file                        version
>      [2]  libm.so.2                   SUNW_1.2
>      [3]  libgcc_s.so.1               GCC_3.0              [ INFO ]
>      [4]                              GCC_3.3              [ INFO ]
>      [5]                              GCC_4.2.0

This shows that /usr/lib/libstdc++.so doesn't use symvers.

> $ elfdump -v /opt/gcc-4.6.0/lib/libstdc++.so.6.0.15
>
> Version Definition Section:  .SUNW_version
>    index  version                     dependency
>      [1]  libstdc++.so.6                                   [ BASE ]
>      [2]  GLIBCXX_3.4
>      [3]  GLIBCXX_3.4.1               GLIBCXX_3.4
>      [4]  GLIBCXX_3.4.2               GLIBCXX_3.4.1
> ...

This shows that /opt/gcc-4.6.0/lib/libstdc++.so does use symvers.

Therefore they are not compatible.

If you compile with gcc 4.6 you must ensure the library in /opt is
found.  I suspect the wrong libstdc++.so is being found at link time.

Another alternative would be to rebuild gcc 4.6 without symbol
versioning enabled so that you get compatibility with the lib from gcc
4.5

Re: __gnu_cxx error in OpenSolaris

[Jonathan Wakely]

On 19 May 2011 15:47, Jonathan Wakely wrote:
> On 19 May 2011 15:03,  <asyropoulos@aol.com> wrote:
>>
>>> ignore that ... you didn't say whether you looked at the libstdc++.so
>>> libs in /opt/gcc-4.6.0 and whether any of them use ELF symbol
>>> versioning, which might make them incompatible.
>>
>> I have compiled Qt with gcc 4.5.3 and 4.6.0 and now I am trying again
>> with 4.6.0 that has been configured to use GNU ld and GNU as. As about
>> the versioning thing I am not sure what you mean, bur I hope the following
>> help:
>>
>> $ elfdump -v /usr/lib/libstdc++.so.6.0.14
>>
>> Version Needed Section:  .SUNW_version
>>    index  file                        version
>>      [2]  libm.so.2                   SUNW_1.2
>>      [3]  libgcc_s.so.1               GCC_3.0              [ INFO ]
>>      [4]                              GCC_3.3              [ INFO ]
>>      [5]                              GCC_4.2.0
>
> This shows that /usr/lib/libstdc++.so doesn't use symvers.
>
>> $ elfdump -v /opt/gcc-4.6.0/lib/libstdc++.so.6.0.15
>>
>> Version Definition Section:  .SUNW_version
>>    index  version                     dependency
>>      [1]  libstdc++.so.6                                   [ BASE ]
>>      [2]  GLIBCXX_3.4
>>      [3]  GLIBCXX_3.4.1               GLIBCXX_3.4
>>      [4]  GLIBCXX_3.4.2               GLIBCXX_3.4.1
>> ...
>
> This shows that /opt/gcc-4.6.0/lib/libstdc++.so does use symvers.
>
> Therefore they are not compatible.
>
> If you compile with gcc 4.6 you must ensure the library in /opt is
> found.  I suspect the wrong libstdc++.so is being found at link time.
>
> Another alternative would be to rebuild gcc 4.6 without symbol
> versioning enabled so that you get compatibility with the lib from gcc
> 4.5

See the docs for --enable-symvers at
http://gcc.gnu.org/onlinedocs/libstdc++/manual/configure.html

If that isn't given explicitly then it will be guessed by configure.
The guess will depend on whether the linker supports symvers or not so
depends on what linker gcc is configured to use. Also support for
--enable-symvers=sun was added in gcc 4.6, so maybe that is being used
by your 4.6 build.

Re: __gnu_cxx error in OpenSolaris

[asyropoulos]

>See the docs for --enable-symvers at
>http://gcc.gnu.org/onlinedocs/libstdc++/manual/configure.html
>
>If that isn't given explicitly then it will be guessed by configure.
>The guess will depend on whether the linker supports symvers or not so
>depends on what linker gcc is configured to use. Also support for
>--enable-symvers=sun was added in gcc 4.6, so maybe that is being used
>by your 4.6 build.


Thank you for the info. I have tried to compiled Qt with gcc

$  gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/opt/gnu/gcc-4.6.0/libexec/gcc/i386-pc-solaris2.11/4.
6.0/lto-wrapper
Target: i386-pc-solaris2.11
Configured with: ../gcc-4.6.0/configure --prefix=/opt/gnu/gcc-4.6.0 
--enable-shared --disable-libtool-lock
--target= --enable-objc-gc --disable-libada --enable-libssp 
--enable-languages=c,c++
--enable-threads=posix --enable-tls=yes --with-system-zlib 
--with-gnu-ld --with-ld=/usr/gnu/bin/ld
--with-gnu-as --with-as=/usr/sfw/bin/gas --with-gmp-lib=/usr/lib 
--with-mpfr-lib=/usr/lib
--enable-c99 --enable-nls --enable-wchar_t 
--enable-libstdcxx-allocator=mt --with-pic --enable-multilib
Thread model: posix
gcc version 4.6.0 (GCC)


and this time compilation completed with no problems. So it seems that 
GNU ld does something
magical...

Regards,

Apostolos

Re: __gnu_cxx error in OpenSolaris

[David Kirkby]

On 19 May 2011 09:43, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> On 19/05/2011, Dr. David Kirkby wrote:
>> On 05/18/11 10:09 PM, Dennis Clarke wrote:
>>> Stick with GCC and you will be happy.
>>
>> That's if you want to write in GNU C++ and don't care about writing standard
>> C++
>> code.
>
> (While we're making gross generalisations...) Every compiler with a
> significant user base creates ghettos of non-portable code.


But the default behavior of GCC is to permit loads of GNU extensions.
Therefor lots of people who write code are writing in some variant of
the C language - usually without realising it.

I've spent a lot of time working on the Sage maths project, which
contains over 90 bits of open-source software. I've noticed that those
bits of code which will not compile with the Sun compiler tend to
present more problems when built with gcc than code that will compile
cleanly with the Sun compiler.

There's one bit of code in particular

http://boxen.math.washington.edu/home/kirkby/bad-code/sympow-1.018.1.p7/src/

~(do a wget -r if you want it)

which is of appalling quality, yet gcc will compile it. When I tried
finding a problem in that code, it was difficult as the code was not
valid C, so I had no idea what the author actually intended.

12 years after the C99 standard was introduced gcc still does not
fully support it. But numerous extensions have been developed in that
time.

> I'm curious what you consider to be "GNU C++" because there are fewer
> and fewer non-standard constructs accepted, and the trend is generally
> to remove support for them not encourage them.

I can't see how you can say that. See:

http://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html#C-Dialect-Options
-sts=`gnu89'
    GNU dialect of ISO C90 (including some C99 features). This is the
default for C code.

It's bad this is the default, but when (IF?) C99 ever gets fully
supported we find the default will again be to permit GNU extensions.

gnu9x'
    GNU dialect of ISO C99. When ISO C99 is fully implemented in GCC,
this will become the default. The name `gnu9x' is deprecated.

>> GCC is useful, but it is the cause of a lot of badly written code.
>
> That can be said about nearly any compiler that's used to write a lot
> of code, and I'm sure you know what they say about bad workmen and
> their tools.


True, but the tools could be a bit more protective. If you are a pilot
and you want to crash a plane you can do. But the computer systems
will protect against stalls and other avoidable conditions.

There's no such warnings when you do non-standard things with gcc.
Sure there are obscure options which aim to accept only standard
conforming C, but I argue these should not be options but be defaults.

Dave

Re: __gnu_cxx error in OpenSolaris

[Jonathan Wakely]

On 19 May 2011 20:03, David Kirkby <david.kirkby@onetel.net> wrote:
> On 19 May 2011 09:43, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>> On 19/05/2011, Dr. David Kirkby wrote:
>>> On 05/18/11 10:09 PM, Dennis Clarke wrote:
>>>> Stick with GCC and you will be happy.
>>>
>>> That's if you want to write in GNU C++ and don't care about writing standard
>>> C++
>>> code.
>>
>> (While we're making gross generalisations...) Every compiler with a
>> significant user base creates ghettos of non-portable code.
>
>
> But the default behavior of GCC is to permit loads of GNU extensions.
> Therefor lots of people who write code are writing in some variant of
> the C language - usually without realising it.

I thought we were talking about C++ (my first clue was the subject of
the thread and your mention of "GNU C++")

Throughout your reply you only refer to C, which I'm not qualified or
interested enough to comment on.

I'm very interested in making G++ conform to the C++ standard as well
as possible and only objected to the assertion that G++ users don't
care about writing standard C++.

Re: __gnu_cxx error in OpenSolaris

[Ian Lance Taylor]

Jonathan Wakely <jwakely.gcc@gmail.com> writes:

> I thought we were talking about C++ (my first clue was the subject of
> the thread and your mention of "GNU C++")
>
> Throughout your reply you only refer to C, which I'm not qualified or
> interested enough to comment on.
>
> I'm very interested in making G++ conform to the C++ standard as well
> as possible and only objected to the assertion that G++ users don't
> care about writing standard C++.

I concur with Jonathan's implication that gcc is far more standard
conforming for C++ than it is for C.  The gcc maintainers have shifted
their general attitude about language extensions over time, but it's
hard to remove the existing C extensions as they are widely used.  There
were never very many C++ extensions, and I believe the ones which remain
are useful and are clearly demarked by double underscores.

Ian

Re: __gnu_cxx error in OpenSolaris

[Miles Bader]

"Dr. David Kirkby" <david.kirkby@onetel.net> writes:
>> Stick with GCC and you will be happy.
>
> That's if you want to write in GNU C++ and don't care about writing
> standard C++ code.

... or are capable of adding a "-std=..." option.  Even if there were no
GNU extensions at all, one would usually need to think about this, as
the differences between various standard dialects are significant.

[Even by default, though, g++ is of vastly _vastly_ more
standards-conforming than, e.g., Microsoft's C++ compiler...]

-Miles

-- 
"Whatever you do will be insignificant, but it is very important that
 you do it."  Mahatma Gandhi

Re: __gnu_cxx error in OpenSolaris

[Dr. David Kirkby]

On 05/19/11 09:09 PM, Jonathan Wakely wrote:
> On 19 May 2011 20:03, David Kirkby<david.kirkby@onetel.net>  wrote:

> I thought we were talking about C++ (my first clue was the subject of
> the thread and your mention of "GNU C++")

> Throughout your reply you only refer to C, which I'm not qualified or
> interested enough to comment on.

But for many practical purposes C++ is a superset of C, so g++ inherits the same 
GNUims as gcc.

For example:

#include <iostream>
using namespace std;

int main() {
    int a=0b1111111;
    cout << a;
}

compiles with g++, but is not valid C++.

There's not even a warning if -Wall is used

drkirkby@hawk:~$ g++ -Wall test.cc
drkirkby@hawk:~$

The Sun compiler quickly identifies this as invalid C++ code.

drkirkby@hawk:~$ CC test.cc
"test.cc", line 5: Error: 0b is not a valid constant.
"test.cc", line 5: Error: Badly formed expression.
2 Error(s) detected.

> I'm very interested in making G++ conform to the C++ standard as well
> as possible and only objected to the assertion that G++ users don't
> care about writing standard C++.

My point is the GNU compilers allow constructs which are not standard. Anyone 
starting a C++ project and wishing for it to be standard C++, should not use g++.

-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Re: __gnu_cxx error in OpenSolaris

[Jonathan Wakely]

On 20 May 2011 07:20, Dr. David Kirkby wrote:
> On 05/19/11 09:09 PM, Jonathan Wakely wrote:
>>
>> On 19 May 2011 20:03, David Kirkby<david.kirkby@onetel.net>  wrote:
>
>> I thought we were talking about C++ (my first clue was the subject of
>> the thread and your mention of "GNU C++")
>
>> Throughout your reply you only refer to C, which I'm not qualified or
>> interested enough to comment on.
>
> But for many practical purposes C++ is a superset of C, so g++ inherits the
> same GNUims as gcc.

Some, but not all of them.  G++ is not a superset of the C compiler in
GCC, they're separate front ends.

On the other hand, many C++ extensions have been removed over the years.

See
http://gcc.gnu.org/onlinedocs/gcc-4.6.0/gcc/Deprecated-Features.html
and
http://gcc.gnu.org/onlinedocs/gcc-4.6.0/gcc/Backwards-Compatibility.html
which support my point about removing non-standard extensions.

As for the other C++ extensions, three of them are now part of the
upcoming C++ standard:
http://gcc.gnu.org/onlinedocs/gcc-4.6.0/gcc/C_002b_002b-Extensions.html

That's why I say the trend is to remove non-standard extensions in the
C++ front end, can you see how I can say that now?


> For example:
>
> #include <iostream>
> using namespace std;
>
> int main() {
>   int a=0b1111111;
>   cout << a;
> }
>
> compiles with g++, but is not valid C++.
>
> There's not even a warning if -Wall is used

Well of course not, RTFM.

If you use -pedantic you get a warning.

> drkirkby@hawk:~$ g++ -Wall test.cc
> drkirkby@hawk:~$
>
> The Sun compiler quickly identifies this as invalid C++ code.
>
> drkirkby@hawk:~$ CC test.cc
> "test.cc", line 5: Error: 0b is not a valid constant.
> "test.cc", line 5: Error: Badly formed expression.
> 2 Error(s) detected.
>
>> I'm very interested in making G++ conform to the C++ standard as well
>> as possible and only objected to the assertion that G++ users don't
>> care about writing standard C++.
>
> My point is the GNU compilers allow constructs which are not standard.

So do all compilers so your point is pretty pointless.

e.g. the Sun compiler allows

struct X {
   mutable int& i;
};

but that's ill-formed (gcc accepted it until 4.6 too, but I fixed it.)

G++ is far stricter and more standard conforming than the Sun
compiler. Additionally it accepts some extensions, but most of them
can be disabled with -pedantic-errors if you don't want them.

> Anyone starting a C++ project and wishing for it to be standard C++, should
> not use g++.

Now you sound like a troll.  I'd ignore you, but I don't want to leave
a ridiculous statement like that unchallenged in the archives of this
list.

I've been starting C++ projects for years using G++ and it's not done
me or my code any harm.

Re: __gnu_cxx error in OpenSolaris

[Dr. David Kirkby]

On 05/20/11 06:23 AM, Miles Bader wrote:
> "Dr. David Kirkby"<david.kirkby@onetel.net>  writes:
>>> Stick with GCC and you will be happy.
>>
>> That's if you want to write in GNU C++ and don't care about writing
>> standard C++ code.
>
> ... or are capable of adding a "-std=..." option.

BUT IMHO, the default should be to use the standard C++, not a set of extensions 
GCC permits.

In any case, that does not work well.

drkirkby@hawk:~$ cat test.cc
#include <iostream>
using namespace std;

int main() {
    int a=0b1111111;
    cout << a;
}

drkirkby@hawk:~$ g++ -std=c++98 -Wall test.cc
drkirkby@hawk:~$ ./a.out
127drkirkby@hawk:~$

I don't have an official copy of the latest standard, but I don't believe 0b is 
anything other than a GNU extension.

http://gcc.gnu.org/onlinedocs/gcc/Binary-constants.html

> Even if there were no
> GNU extensions at all, one would usually need to think about this, as
> the differences between various standard dialects are significant.
>
> [Even by default, though, g++ is of vastly _vastly_ more
> standards-conforming than, e.g., Microsoft's C++ compiler...]
>
> -Miles

I use gcc a lot, but I'm not impressed with it.

Dave

Re: __gnu_cxx error in OpenSolaris

[Jonathan Wakely]

On 20 May 2011 07:49, Dr. David Kirkby wrote:
> On 05/20/11 06:23 AM, Miles Bader wrote:
>>
>> "Dr. David Kirkby"<david.kirkby@onetel.net>  writes:
>>>>
>>>> Stick with GCC and you will be happy.
>>>
>>> That's if you want to write in GNU C++ and don't care about writing
>>> standard C++ code.
>>
>> ... or are capable of adding a "-std=..." option.
>
> BUT IMHO, the default should be to use the standard C++, not a set of
> extensions GCC permits.

Have you seen the default C++ standard library used by the Sun compiler?
Or its treatment of the lifetime of temporaries? (See -features=tmplife)

And it allows __thread by default, but it's a non-standard extension -
the horror!

> In any case, that does not work well.
>
> drkirkby@hawk:~$ cat test.cc
> #include <iostream>
> using namespace std;
>
> int main() {
>   int a=0b1111111;
>   cout << a;
> }
>
> drkirkby@hawk:~$ g++ -std=c++98 -Wall test.cc
> drkirkby@hawk:~$ ./a.out
> 127drkirkby@hawk:~$
>
> I don't have an official copy of the latest standard, but I don't believe 0b
> is anything other than a GNU extension.
>
> http://gcc.gnu.org/onlinedocs/gcc/Binary-constants.html

Yes, it's an extension, so use -pedantic as documented in the manual.

Re: __gnu_cxx error in OpenSolaris

[Miles Bader]

Jonathan Wakely <jwakely.gcc@gmail.com> writes:
> On 20 May 2011 07:20, Dr. David Kirkby wrote:
>> Anyone starting a C++ project and wishing for it to be standard C++,
>> should not use g++.
>
> Now you sound like a troll.

Indeed.

-miles

-- 
Cannon, n. An instrument employed in the rectification of national boundaries.

Re: __gnu_cxx error in OpenSolaris

[asyropoulos]

>> I don't have an official copy of the latest standard, but I don't 
believe 0b
>> is anything other than a GNU extension.
>>
>> http://gcc.gnu.org/onlinedocs/gcc/Binary-constants.html
>
>Yes, it's an extension, so use -pedantic as documented in the manual.

And why not have this option as the default to so to discourage or even 
prevent people from
using the extensions?

Apostolos
  

Re: __gnu_cxx error in OpenSolaris

[Jonathan Wakely]

On 25 May 2011 09:30,  <asyropoulos@aol.com> wrote:
>
>>> I don't have an official copy of the latest standard, but I don't
>
> believe 0b
>>>
>>> is anything other than a GNU extension.
>>>
>>> http://gcc.gnu.org/onlinedocs/gcc/Binary-constants.html
>>
>> Yes, it's an extension, so use -pedantic as documented in the manual.
>
> And why not have this option as the default to so to discourage or even
> prevent people from
> using the extensions?

Because not everyone who uses the compiler wants the same settings, so
changing defaults can't be done lightly.

It's there if you want to use it.

Re: __gnu_cxx error in OpenSolaris

[asyropoulos]

>> And why not have this option as the default to so to discourage or 
even
>> prevent people from
>> using the extensions?
>
>Because not everyone who uses the compiler wants the same settings, so
>changing defaults can't be done lightly.

This is supposed to be the GNU C/C+/ compiler not the compiler of the 
GNU C,
GNU C++, etc. languages, so this is not an answer.

>It's there if you want to use it.

No the standard must the default and the GNUisms the extension not the
other way around. After all, this is exactly what certain big companies 
are doing
and people are blaming them for disrespecting standards...

A.S.
  

Re: __gnu_cxx error in OpenSolaris

[Jonathan Wakely]

On 25 May 2011 14:27,  <asyropoulos@aol.com> wrote:
>>> And why not have this option as the default to so to discourage or
>
> even
>>>
>>> prevent people from
>>> using the extensions?
>>
>> Because not everyone who uses the compiler wants the same settings, so
>> changing defaults can't be done lightly.
>
> This is supposed to be the GNU C/C+/ compiler not the compiler of the GNU C,
> GNU C++, etc. languages, so this is not an answer.

Is it?  Where does it say that?

The default mode for compiling C is -std=gnu89 and for C++ it's
-std=gnu++98, I'm pretty sure that those defaults weren't set that way
by accident.


>> It's there if you want to use it.
>
> No the standard must the default and the GNUisms the extension not the
> other way around. After all, this is exactly what certain big companies are
> doing
> and people are blaming them for disrespecting standards...

Feel free to file a bug - complaining on this list won't change anything.

Re: __gnu_cxx error in OpenSolaris

[Ian Lance Taylor]

asyropoulos@aol.com writes:

> This is supposed to be the GNU C/C+/ compiler not the compiler of the
> GNU C,
> GNU C++, etc. languages, so this is not an answer.

I'm not sure why you say that.


> No the standard must the default and the GNUisms the extension not the
> other way around. After all, this is exactly what certain big
> companies are doing
> and people are blaming them for disrespecting standards...

The compiler is a sharp knife.  You can make it do what you want.

The default behaviour is not going to change.

Ian

Re: __gnu_cxx error in OpenSolaris

[asyropoulos]

>> This is supposed to be the GNU C/C+/ compiler not the compiler of the
>> GNU C,
>> GNU C++, etc. languages, so this is not an answer.
>
>I'm not sure why you say that.

From http://gcc.gnu.org/:

#The GNU Compiler Collection includes front ends for C, C++, 
Objective-C, Fortran, Java, Ada, and Go, as well as
#libraries for these languages (libstdc++, libgcj,...). GCC was 
originally written as the compiler for the GNU operating system.
#The GNU system was developed to be 100% free software, free in the 
sense that it respects the user's freedom.

Here it is clearly stated that this is a C, C++, etc. compiler not 
something else. And when you press the C link it
shows to what degree the compiler supports the standard.  So what don't 
you understand?


>The compiler is a sharp knife.  You can make it do what you want.

No it is a tool that is supposed to work compilers work.

>The default behaviour is not going to change.

Too bad for GNU and gcc. And I had the impression that this is all 
about standards
that everyone should follow...

Regards,
A.S.

Re: __gnu_cxx error in OpenSolaris

[Jonathan Wakely]

On 25 May 2011 17:21,  <asyropoulos@aol.com> wrote:
>
>
>
>
>>> This is supposed to be the GNU C/C+/ compiler not the compiler of the
>>> GNU C,
>>> GNU C++, etc. languages, so this is not an answer.
>>
>> I'm not sure why you say that.
>
> From http://gcc.gnu.org/:
>
> #The GNU Compiler Collection includes front ends for C, C++, Objective-C,
> Fortran, Java, Ada, and Go, as well as
> #libraries for these languages (libstdc++, libgcj,...).

Did you miss this bit:

**********
> GCC was originally
> written as the compiler for the GNU operating system.
**********

> #The GNU system was developed to be 100% free software, free in the sense
> that it respects the user's freedom.
>
> Here it is clearly stated that this is a C, C++, etc. compiler not something

It doesn't say "ISO C".

> else. And when you press the C link it
> shows to what degree the compiler supports the standard.

That link was only very recently added:
http://gcc.gnu.org/ml/gcc/2011-05/msg00102.html
That page was chosen because there isn't a better page for the C
front-end, it's not really a good choice. It documents the conformance
to C99, and the default for GCC is -std=gnu90, not even -std=gnu99 let
alone -std=c99


> So what don't you
> understand?

You're arguing with two maintainers of GCC about what GCC is.

I can't see any result except making yourself look silly.


>> The compiler is a sharp knife.  You can make it do what you want.
>
> No it is a tool that is supposed to work compilers work.

I'm not even sure what you're trying to say here.

It's a tool, yes. A very flexible one, so there have to be some
defaults chosen for its behaviour.  No set of defaults will please
everyone, so on that basis keeping the same defaults as we have now
causes the least disruption.

>> The default behaviour is not going to change.
>
> Too bad for GNU and gcc. And I had the impression that this is all about
> standards
> that everyone should follow...

Your impression was wrong, it's not "all about" any single thing,
because what defines a useful compiler means different things to
different people.

I care very much about making G++ conform closely to the C++ standard
so I can use it to write conforming code whenever possible, but I
disagree that all extensions should be disabled by default.   If you
want GCC to follow the standards you can use the appropriate switches.
 Even if your preference is "right", changing the defaults would force
your opinion on everyone else and cause a lot of wasted time and
anger.

Re: __gnu_cxx error in OpenSolaris

[Ian Lance Taylor]

asyropoulos@aol.com writes:

>>> This is supposed to be the GNU C/C+/ compiler not the compiler of the
>>> GNU C,
>>> GNU C++, etc. languages, so this is not an answer.
>>
>>I'm not sure why you say that.
>
> From http://gcc.gnu.org/:
>
> #The GNU Compiler Collection includes front ends for C, C++,
> Objective-C, Fortran, Java, Ada, and Go, as well as
> #libraries for these languages (libstdc++, libgcj,...). GCC was
> originally written as the compiler for the GNU operating system.
> #The GNU system was developed to be 100% free software, free in the
> sense that it respects the user's freedom.
>
> Here it is clearly stated that this is a C, C++, etc. compiler not
> something else. And when you press the C link it
> shows to what degree the compiler supports the standard.  So what
> don't you understand?

gcc does by default compile all conforming ISO C90 programs and, with
the appropriate option, almost all conforming C99 programs.  I am not
aware of any compiler which by default rejects all non-conforming C90 or
C99 programs, though most compilers, including gcc, do have a mode in
which they reject non-conforming programs.

> Too bad for GNU and gcc. And I had the impression that this is all
> about standards
> that everyone should follow...

gcc does follow the standards.  You are talking about something else:
rejecting non-conforming programs.  The standard discusses conforming
programs, not non-conforming programs.

Ian

Re: __gnu_cxx error in OpenSolaris

[asyropoulos]

>Did you miss this bit:
>
>**********
>> GCC was originally
>> written as the compiler for the GNU operating system.
>**********

Which means what? That the compiler should not obey a standard?


>> #The GNU system was developed to be 100% free software, free in the 
sense
>> that it respects the user's freedom.
>>
>> Here it is clearly stated that this is a C, C++, etc. compiler not 
something
>
>It doesn't say "ISO C".

Yes it does:

This table is based on the list in the foreword to N1256 (ISO/IEC 
9899:1999 (E), consolidated with ISO/IEC 9899:1999/Cor.1:2001 (E),
ISO/IEC 9899:1999/Cor.2:2004 (E) and ISO/IEC 9899:1999/Cor.3:2007 (E)).

>front-end, it's not really a good choice. It documents the conformance
>to C99, and the default for GCC is -std=gnu90, not even -std=gnu99 let
>alone -std=c99

So it is not a C compiler!

>
>You're arguing with two maintainers of GCC about what GCC is.
>
>I can't see any result except making yourself look silly.

That is, everyone who argues with GCC developers is silly? Very nice!


>It's a tool, yes. A very flexible one, so there have to be some
>defaults chosen for its behaviour.  No set of defaults will please
>everyone, so on that basis keeping the same defaults as we have now
>causes the least disruption.

When you buy  screwdrivers, tools in general,. they all conform to 
standards
or else you wouldn't be able to use them. It is that simple. A compiler
must conform to standards. It must accept only strings (programs) that
follow the standard.


>Your impression was wrong, it's not "all about" any single thing,
>because what defines a useful compiler means different things to
>different people.

The problem is flexibility. Either you obey the standard and you have
a conforming compiler or else you have a program that is something
else. POSIX is similar example: either you follow it or don't care about
it. But if we start not to care about standards, we are in big trouble.


>I care very much about making G++ conform closely to the C++ standard
>so I can use it to write conforming code whenever possible, but I
>disagree that all extensions should be disabled by default.   If you

And I strongly disagree with this last statement! This is the root of 
all
evil. This is why people create programs that do not compile in
different architectures/systems.

>want GCC to follow the standards you can use the appropriate switches.

And how can I force developers to write conforming code when the
compiler itself welcomes violation of all standards?

A.S.


  

Re: __gnu_cxx error in OpenSolaris

[Paul Smith]

On Wed, 2011-05-25 at 14:22 -0400, asyropoulos@aol.com wrote:
> When you buy  screwdrivers, tools in general,. they all conform to 
> standards or else you wouldn't be able to use them. It is that simple.
> A compiler must conform to standards. It must accept only strings
> (programs) that follow the standard.

Ian already mentioned this but I'll reiterate it because I see this all
the time in my work as well: it appears to be a common misunderstanding
of what standards are for and what it means to be a conforming
implementation of a given standard.

If your compiler accepts input that is correct according to the standard
and it correctly generates the proper output as defined by the standard,
then it's a conforming implementation of that standard.

GCC is at least as conforming as any other compiler, that I'm aware of,
to the various standards.  All compilers have small areas where they're
not conforming and GCC does too, but these are being reduced all the
time.


What you are asking for here is something completely different: that the
compiler REJECT any input that does NOT conform exactly to the standard.
That behavior is NOT required in a conforming implementation of the
standard.  The standard does not, and cannot, describe what the compiler
should do when the input invokes undefined behavior... it can emit an
error, or crash, or even actually interpret that behavior and provide
useful results.  If the input is not strictly conforming then nothing
the compiler does can be said to violate the standard, by definition.

So.  You do not have a valid argument based on adherence to the
standard: GCC's behavior is absolutely, completely valid in terms of
what the standard requires and IS a (mostly) conforming
implementation--at any rate, changing the default behavior as you
suggest will not make GCC any MORE conforming than it is today.


You have a good argument to be made here based solely on quality of
implementation grounds: that it would be better, from a QOI point of
view, if the compiler were to by default complain about non-conforming
behavior and require flags to be specified to loosen the interpretation.
I can't disagree with you that _in the abstract_ that would be the
correct behavior.

But here's the thing: GCC was written (originally) before ISO published
the first C standard.  It _predates_ the standard.  At the time the
standard was published in 1989/1990 it was already outdated in various
ways.  Also, because the standard was just published, hardly any C code
actually complied with the standard.  If GCC had adopted a strict
adherence model almost no code would have passed that check.  So GCC
kept its "lax" interpretation as the default but allowed you to ask for
strict interpretations.  Maybe in hindsight a different choice would
have been better... or maybe not.

In any event, what Ian is saying is that the choice was made back then
and it's far too late now to change it.

Re: __gnu_cxx error in OpenSolaris

[asyropoulos]

>> and this time compilation completed with no problems. So it seems 
that
>> GNU ld does something
>> magical...
>
>Doe that not frighten you a bit ? I would think that one should never
>astonish the user with such things.

Hello Dennis,

I am not really sure I understand your point. It is not the first time
something is not working the way it "should".

Apostolos

  

Re: __gnu_cxx error in OpenSolaris

[Dennis Clarke]

>>See the docs for --enable-symvers at
>>http://gcc.gnu.org/onlinedocs/libstdc++/manual/configure.html
>>
>>If that isn't given explicitly then it will be guessed by configure.
>>The guess will depend on whether the linker supports symvers or not so
>>depends on what linker gcc is configured to use. Also support for
>>--enable-symvers=sun was added in gcc 4.6, so maybe that is being used
>>by your 4.6 build.
>
>
> Thank you for the info. I have tried to compiled Qt with gcc
>
> $  gcc -v
> Using built-in specs.
> COLLECT_GCC=gcc
> COLLECT_LTO_WRAPPER=/opt/gnu/gcc-4.6.0/libexec/gcc/i386-pc-solaris2.11/4.
> 6.0/lto-wrapper
> Target: i386-pc-solaris2.11
> Configured with: ../gcc-4.6.0/configure --prefix=/opt/gnu/gcc-4.6.0
> --enable-shared --disable-libtool-lock
> --target= --enable-objc-gc --disable-libada --enable-libssp
> --enable-languages=c,c++
> --enable-threads=posix --enable-tls=yes --with-system-zlib
> --with-gnu-ld --with-ld=/usr/gnu/bin/ld
> --with-gnu-as --with-as=/usr/sfw/bin/gas --with-gmp-lib=/usr/lib
> --with-mpfr-lib=/usr/lib
> --enable-c99 --enable-nls --enable-wchar_t
> --enable-libstdcxx-allocator=mt --with-pic --enable-multilib
> Thread model: posix
> gcc version 4.6.0 (GCC)
>
>
> and this time compilation completed with no problems. So it seems that
> GNU ld does something
> magical...

Doe that not frighten you a bit ? I would think that one should never
astonish the user with such things.

Dennis

Re: __gnu_cxx error in OpenSolaris

[asyropoulos]

>Try locating all files named libstdc++.*, there may be an older one 
being
>picked up first.

I don't think this is the problem:

$ cd /usr/lib
$ ls -l libstdc++.so.*
lrwxrwxrwx 1 root root      19 2010-12-21 20:05 libstdc++.so.6 -> 
libstdc++.so.6.0.14
-r-xr-xr-x 1 root bin  1487364 2010-10-02 15:41 libstdc++.so.6.0.10
-rwxr-xr-x 1 root bin  5692376 2010-12-21 20:05 libstdc++.so.6.0.14
-rw-r--r-- 1 root bin     2284 2010-12-21 20:05 
libstdc++.so.6.0.14-gdb.py

>Whereas gcc recommends using Sun ld ;-)

I know this, but my goal is to compile Qt.


>> $ ls -l /usr/ccs/bin/ld
>> lrwxrwxrwx 1 root root 12 2010-10-02 15:41 /usr/ccs/bin/ld -> 
../../bin/ld
>> $ /usr/bin/ld --version
>> GNU ld (GNU Binutils) 2.19
>
>On Solaris, really? Did you overwrite the system one?
>

Not really, I made a copy just to make the test:

$ cd /usr/bin/
$ ls -l ld*
-rwxr-xr-x   1 root     bin      1327156 Μαϊ 18 15:20 ld
-rwxr-xr-x   1 root     bin        17912 Μαϊ 18 14:21 ld.sol

>(--without-gnu-ld doesn't fit that well with using gnu ld)

Maybe I need to recompile GCC with gnu ld and see what happens.

A.S.


  

Re: __gnu_cxx error in OpenSolaris

[Marc Glisse]

On Wed, 18 May 2011, asyropoulos@aol.com wrote:

> I am trying to build the latest Qt (v. 4.7.3) with gcc but it fails and stops 
> with the following error message:
>
> /extra/sources/qt/qt-everywhere-opensource-src-4.7.3/lib/libQtCLucene.so.
> 4: undefined reference to `__gnu_cxx::__pool<true>::_M_initialize()'
> /extra/sources/qt/qt-everywhere-opensource-src-4.7.3/lib/libQtCLucene.so.
> 4: undefined reference to `std::_List_node_base::_M_unhook()'
> /extra/sources/qt/qt-everywhere-opensource-src-4.7.3/lib/libQtCLucene.so.
> 4: undefined reference to `__gnu_cxx::__pool<true>::_M_get_thread_id()'
> /extra/sources/qt/qt-everywhere-opensource-src-4.7.3/lib/libQtCLucene.so.
> 4: undefined reference to `__gnu_cxx::__pool<true>::_M_reclaim_block(char*, 
> unsigned int)'
> /extra/sources/qt/qt-everywhere-opensource-src-4.7.3/lib/libQtCLucene.so.
> 4: undefined reference to `__gnu_cxx::__pool<true>::_M_reserve_block(unsigned 
> int, unsigned int)'
> /extra/sources/qt/qt-everywhere-opensource-src-4.7.3/lib/libQtCLucene.so.
> 4: undefined reference to 
> `std::_List_node_base::_M_hook(std::_List_node_base*)'
> collect2: ld returned 1 exit status
> make: *** [../../../../bin/assistant] Error 1

Try locating all files named libstdc++.*, there may be an older one being 
picked up first.

> http://doc.qt.nokia.com/4.7-snapshot/platform-notes-x11.html
>
> it is advised that on Solaris one should use GNU ld/as and not the Solaris 
> ld/as.

Whereas gcc recommends using Sun ld ;-)

> $ /opt/gcc-4.6.0/bin/gcc -v
> Using built-in specs.
> COLLECT_GCC=/opt/gcc-4.6.0/bin/gcc
> COLLECT_LTO_WRAPPER=/opt/gcc-4.6.0/libexec/gcc/i386-pc-solaris2.11/4.6.0/
> lto-wrapper
> Target: i386-pc-solaris2.11
> Configured with: ../gcc-4.6.0/configure --prefix=/opt/gcc-4.6.0 
> --enable-shared --enable-static
> --disable-libtool-lock --target= --enable-objc-gc --disable-libada 
> --enable-libssp
> --enable-languages=c,c++,fortran,go,objc,obj-c++ --enable-threads=posix
> --enable-tls=yes --with-system-zlib --without-gnu-ld 
> --with-ld=/usr/ccs/bin/ld
> --with-gnu-as --with-as=/usr/sfw/bin/gas --with-gmp-lib=/usr/lib 
> --with-mpfr-lib=/usr/lib
> --enable-c99 --enable-nls --enable-wchar_t --enable-libstdcxx-allocator=mt 
> --with-pic --enable-multilib

Wow, that's a long line...

> $ ls -l /usr/ccs/bin/ld
> lrwxrwxrwx 1 root root 12 2010-10-02 15:41 /usr/ccs/bin/ld -> ../../bin/ld
> $ /usr/bin/ld --version
> GNU ld (GNU Binutils) 2.19

On Solaris, really? Did you overwrite the system one?

(--without-gnu-ld doesn't fit that well with using gnu ld)

-- 
Marc Glisse

Re: __gnu_cxx error in OpenSolaris

[Jonathan Wakely]

On 18 May 2011 21:59,  <asyropoulos@aol.com> wrote:
>
> $ elfdump -s /usr/lib/libstdc++.so.6.0.14|grep gnu_cxx
>
> shows that the sumbols are included in the library!

You said your compiler was configured with
--prefix=/opt/gcc-4.6.0
but that's in /usr/lib

what about the libstdc++ in /opt/gcc-4.6.0 ?

Check whether it uses symbol versioning, i.e. symbol names with e.g.
@_GLIBCXX3.14

If your compiler is configured to use symvers but it finds a shared
library built without them, it will cause problems.

Re: __gnu_cxx error in OpenSolaris

[asyropoulos]

>I have had good results for both Sparc and i386/AMD64 with or without 
gas
>( GNU as ) however you must always use Sun provided LD=/usr/ccs/bin/ld 
if
>you want things to work.

Yes but I have forgot to say that I have tried with the Solaris ld and 
the result
was in essence the same. Also,

$ elfdump -s /usr/lib/libstdc++.so.6.0.14|grep gnu_cxx

shows that the sumbols are included in the library!

BTW, have you compiled the latest Qt with gcc? You know solaris
studio is not an option as most useful programs do not compile
with it.

Apostolos


  

Re: __gnu_cxx error in OpenSolaris

[asyropoulos]

>Since you are getting a number of missing symbols from the C++ runtime
>library my first guess would be that libstdc++ is not being linked to.
> What is the linker command? is it using 'gcc' to link?  Using 'g++'
>instead would cause -lstdc++ to be used automatically.

Here is the command

g++ 
-Wl,-rpath-link,/extra/sources/qt/qt-everywhere-opensource-src-4.7.3/lib 
-Wl,-R,/opt/gnu/qt4/lib -Wl,-R,/opt/gnu/qt4/lib -o 
../../../../bin/assistant .obj/release-shared/fontpanel.o  
.obj/release-shared/aboutdialog.o  .obj/release-shared/bookmarkdialog.o 
  .obj/release-shared/bookmarkfiltermodel.o  
.obj/release-shared/bookmarkitem.o  
.obj/release-shared/bookmarkmanager.o  
.obj/release-shared/bookmarkmanagerwidget.o  
.obj/release-shared/bookmarkmodel.o  
.obj/release-shared/centralwidget.o  
.obj/release-shared/cmdlineparser.o  
.obj/release-shared/contentwindow.o  .obj/release-shared/findwidget.o  
.obj/release-shared/filternamedialog.o  
.obj/release-shared/helpenginewrapper.o  
.obj/release-shared/helpviewer.o  .obj/release-shared/indexwindow.o  
.obj/release-shared/installdialog.o  .obj/release-shared/main.o  
.obj/release-shared/mainwindow.o  
.obj/release-shared/preferencesdialog.o  
.obj/release-shared/qtdocinstaller.o  
.obj/release-shared/remotecontrol.o  .obj/release-shared/searchwidget.o 
  .obj/release-shared/topicchooser.o  .obj/release-shared/xbelsupport.o  
.obj/release-shared/collectionconfiguration.o  
.obj/release-shared/helpviewer_qtb.o  
.obj/release-shared/moc_fontpanel.o  
.obj/release-shared/moc_aboutdialog.o  
.obj/release-shared/moc_bookmarkdialog.o  
.obj/release-shared/moc_bookmarkfiltermodel.o  
.obj/release-shared/moc_bookmarkmanager.o  
.obj/release-shared/moc_bookmarkmanagerwidget.o  
.obj/release-shared/moc_bookmarkmodel.o  
.obj/release-shared/moc_centralwidget.o  
.obj/release-shared/moc_contentwindow.o  
.obj/release-shared/moc_findwidget.o  
.obj/release-shared/moc_filternamedialog.o  
.obj/release-shared/moc_helpenginewrapper.o  
.obj/release-shared/moc_indexwindow.o  
.obj/release-shared/moc_installdialog.o  
.obj/release-shared/moc_mainwindow.o  
.obj/release-shared/moc_preferencesdialog.o  
.obj/release-shared/moc_qtdocinstaller.o  
.obj/release-shared/moc_remotecontrol.o  
.obj/release-shared/moc_searchwidget.o  
.obj/release-shared/moc_topicchooser.o  
.obj/release-shared/moc_helpviewer_qtb.o  
.obj/release-shared/qrc_assistant.o  
.obj/release-shared/qrc_assistant_images.o    -L/opt/gnu/include 
-L/extra/sources/qt/qt-everywhere-opensource-src-4.7.3/lib 
-L/usr/sfw/lib 
-L/extra/sources/qt/qt-everywhere-opensource-src-4.7.3/plugins/sqldrivers
  -lQtHelp -L/opt/gnu/include 
-L/extra/sources/qt/qt-everywhere-opensource-src-4.7.3/lib 
-L/usr/sfw/lib -L/usr/X11/lib -lQtSql -lQtXml -lQtGui -lQtNetwork 
-lresolv -lsocket -lxnet -lnsl -lQtCore -lpthread -lrt
*** Error code 1

As you see it uses g++.

A.S.


  

Re: __gnu_cxx error in OpenSolaris

[Jonathan Wakely]

On 18 May 2011 19:17,  <asyropoulos@aol.com> wrote:
>
> Hello,
>
> I am trying to build the latest Qt (v. 4.7.3) with gcc but it fails and
> stops with the following error message:
>
> /extra/sources/qt/qt-everywhere-opensource-src-4.7.3/lib/libQtCLucene.so.
> 4: undefined reference to `__gnu_cxx::__pool<true>::_M_initialize()'
> /extra/sources/qt/qt-everywhere-opensource-src-4.7.3/lib/libQtCLucene.so.
> 4: undefined reference to `std::_List_node_base::_M_unhook()'
> /extra/sources/qt/qt-everywhere-opensource-src-4.7.3/lib/libQtCLucene.so.
> 4: undefined reference to `__gnu_cxx::__pool<true>::_M_get_thread_id()'
> /extra/sources/qt/qt-everywhere-opensource-src-4.7.3/lib/libQtCLucene.so.
> 4: undefined reference to `__gnu_cxx::__pool<true>::_M_reclaim_block(char*,
> unsigned int)'
> /extra/sources/qt/qt-everywhere-opensource-src-4.7.3/lib/libQtCLucene.so.
> 4: undefined reference to
> `__gnu_cxx::__pool<true>::_M_reserve_block(unsigned int, unsigned int)'
> /extra/sources/qt/qt-everywhere-opensource-src-4.7.3/lib/libQtCLucene.so.
> 4: undefined reference to
> `std::_List_node_base::_M_hook(std::_List_node_base*)'
> collect2: ld returned 1 exit status
> make: *** [../../../../bin/assistant] Error 1

Since you are getting a number of missing symbols from the C++ runtime
library my first guess would be that libstdc++ is not being linked to.
 What is the linker command? is it using 'gcc' to link?  Using 'g++'
instead would cause -lstdc++ to be used automatically.

Re: __gnu_cxx error in OpenSolaris

[Dennis Clarke]

>
> Hello,
>
> I am trying to build the latest Qt (v. 4.7.3) with gcc but it fails and
> stops with the following error message:
>
> /extra/sources/qt/qt-everywhere-opensource-src-4.7.3/lib/libQtCLucene.so.
> 4: undefined reference to `__gnu_cxx::__pool<true>::_M_initialize()'
> /extra/sources/qt/qt-everywhere-opensource-src-4.7.3/lib/libQtCLucene.so.
> 4: undefined reference to `std::_List_node_base::_M_unhook()'
> /extra/sources/qt/qt-everywhere-opensource-src-4.7.3/lib/libQtCLucene.so.
> 4: undefined reference to `__gnu_cxx::__pool<true>::_M_get_thread_id()'
> /extra/sources/qt/qt-everywhere-opensource-src-4.7.3/lib/libQtCLucene.so.
> 4: undefined reference to
> `__gnu_cxx::__pool<true>::_M_reclaim_block(char*, unsigned int)'
> /extra/sources/qt/qt-everywhere-opensource-src-4.7.3/lib/libQtCLucene.so.
> 4: undefined reference to
> `__gnu_cxx::__pool<true>::_M_reserve_block(unsigned int, unsigned int)'
> /extra/sources/qt/qt-everywhere-opensource-src-4.7.3/lib/libQtCLucene.so.
> 4: undefined reference to
> `std::_List_node_base::_M_hook(std::_List_node_base*)'
> collect2: ld returned 1 exit status
> make: *** [../../../../bin/assistant] Error 1
>
> I am using OpenSolaris and both gcc 4.5.4 and 4.6.0 stop with the same
> error.  In the "Platform and Compiler Notes"
>
> http://doc.qt.nokia.com/4.7-snapshot/platform-notes-x11.html
>
> it is advised that on Solaris one should use GNU ld/as and not the
> Solaris ld/as.  Now, gcc has been configured
> as follows:
>
> $ /opt/gcc-4.6.0/bin/gcc -v
> Using built-in specs.
> COLLECT_GCC=/opt/gcc-4.6.0/bin/gcc
> COLLECT_LTO_WRAPPER=/opt/gcc-4.6.0/libexec/gcc/i386-pc-solaris2.11/4.6.0/
> lto-wrapper
> Target: i386-pc-solaris2.11
> Configured with: ../gcc-4.6.0/configure --prefix=/opt/gcc-4.6.0
> --enable-shared --enable-static
> --disable-libtool-lock --target= --enable-objc-gc --disable-libada
> --enable-libssp
> --enable-languages=c,c++,fortran,go,objc,obj-c++ --enable-threads=posix
> --enable-tls=yes --with-system-zlib --without-gnu-ld
> --with-ld=/usr/ccs/bin/ld
> --with-gnu-as --with-as=/usr/sfw/bin/gas --with-gmp-lib=/usr/lib
> --with-mpfr-lib=/usr/lib
> --enable-c99 --enable-nls --enable-wchar_t
> --enable-libstdcxx-allocator=mt --with-pic --enable-multilib
> Thread model: posix
> gcc version 4.6.0 (GCC)
>
>
> and
> $ ls -l /usr/ccs/bin/ld
> lrwxrwxrwx 1 root root 12 2010-10-02 15:41 /usr/ccs/bin/ld ->
> ../../bin/ld
> $ /usr/bin/ld --version
> GNU ld (GNU Binutils) 2.19
> Copyright 2007 Free Software Foundation, Inc.
> This program is free software; you may redistribute it under the terms
> of
> the GNU General Public License version 3 or (at your option) a later
> version.
> This program has absolutely no warranty.
>
> So I am using gld when compiling. I would appreciate and
> comment/suggestion/idea
> that would help me.
>
> Regards,
>
> Apostolos


see http://gcc.gnu.org/gcc-4.6/buildstat.html

for i386-pc-solaris2.8
http://gcc.gnu.org/ml/gcc-testresults/2011-04/msg00175.html

and for sparc-sun-solaris2.8
http://gcc.gnu.org/ml/gcc-testresults/2011-03/msg02959.html

I have had good results for both Sparc and i386/AMD64 with or without gas
( GNU as ) however you must always use Sun provided LD=/usr/ccs/bin/ld if
you want things to work.


-- 
Dennis Clarke
dclarke@opensolaris.ca  <- Email related to the open source Solaris
dclarke@blastwave.org   <- Email related to open source for Solaris

__gnu_cxx error in OpenSolaris

[asyropoulos]

Hello,

I am trying to build the latest Qt (v. 4.7.3) with gcc but it fails and 
stops with the following error message:

/extra/sources/qt/qt-everywhere-opensource-src-4.7.3/lib/libQtCLucene.so.
4: undefined reference to `__gnu_cxx::__pool<true>::_M_initialize()'
/extra/sources/qt/qt-everywhere-opensource-src-4.7.3/lib/libQtCLucene.so.
4: undefined reference to `std::_List_node_base::_M_unhook()'
/extra/sources/qt/qt-everywhere-opensource-src-4.7.3/lib/libQtCLucene.so.
4: undefined reference to `__gnu_cxx::__pool<true>::_M_get_thread_id()'
/extra/sources/qt/qt-everywhere-opensource-src-4.7.3/lib/libQtCLucene.so.
4: undefined reference to 
`__gnu_cxx::__pool<true>::_M_reclaim_block(char*, unsigned int)'
/extra/sources/qt/qt-everywhere-opensource-src-4.7.3/lib/libQtCLucene.so.
4: undefined reference to 
`__gnu_cxx::__pool<true>::_M_reserve_block(unsigned int, unsigned int)'
/extra/sources/qt/qt-everywhere-opensource-src-4.7.3/lib/libQtCLucene.so.
4: undefined reference to 
`std::_List_node_base::_M_hook(std::_List_node_base*)'
collect2: ld returned 1 exit status
make: *** [../../../../bin/assistant] Error 1

I am using OpenSolaris and both gcc 4.5.4 and 4.6.0 stop with the same 
error.  In the "Platform and Compiler Notes"

http://doc.qt.nokia.com/4.7-snapshot/platform-notes-x11.html

it is advised that on Solaris one should use GNU ld/as and not the 
Solaris ld/as.  Now, gcc has been configured
as follows:

$ /opt/gcc-4.6.0/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/opt/gcc-4.6.0/bin/gcc
COLLECT_LTO_WRAPPER=/opt/gcc-4.6.0/libexec/gcc/i386-pc-solaris2.11/4.6.0/
lto-wrapper
Target: i386-pc-solaris2.11
Configured with: ../gcc-4.6.0/configure --prefix=/opt/gcc-4.6.0 
--enable-shared --enable-static
--disable-libtool-lock --target= --enable-objc-gc --disable-libada 
--enable-libssp
--enable-languages=c,c++,fortran,go,objc,obj-c++ --enable-threads=posix
--enable-tls=yes --with-system-zlib --without-gnu-ld 
--with-ld=/usr/ccs/bin/ld
--with-gnu-as --with-as=/usr/sfw/bin/gas --with-gmp-lib=/usr/lib 
--with-mpfr-lib=/usr/lib
--enable-c99 --enable-nls --enable-wchar_t 
--enable-libstdcxx-allocator=mt --with-pic --enable-multilib
Thread model: posix
gcc version 4.6.0 (GCC)


and
$ ls -l /usr/ccs/bin/ld
lrwxrwxrwx 1 root root 12 2010-10-02 15:41 /usr/ccs/bin/ld -> 
../../bin/ld
$ /usr/bin/ld --version
GNU ld (GNU Binutils) 2.19
Copyright 2007 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms 
of
the GNU General Public License version 3 or (at your option) a later 
version.
This program has absolutely no warranty.

So I am using gld when compiling. I would appreciate and 
comment/suggestion/idea
that would help me.

Regards,

Apostolos