>
>> Dennis Clarke wrote:
>>> James wrote:
Don't use the blastwave versions of libstdc++
>>>
>>> Why not ?
>>>
>>> Works perfectly for me.
>> ...
>>> $ ./hello
>>> Hello, world!
>>>
>>> So what/where is the problem ?
>>
>> Hi Dennis,
>> I wasn't aware when I sent that suggestion that Greg's b
> Dennis Clarke wrote:
>> James wrote:
>>> Don't use the blastwave versions of libstdc++
>>
>> Why not ?
>>
>> Works perfectly for me.
> ...
>> $ ./hello
>> Hello, world!
>>
>> So what/where is the problem ?
>
> Hi Dennis,
> I wasn't aware when I sent that suggestion that Greg's build
> system had
>
> You appear to be using a GCC release that is bundled with Blastwave. Is
> there a particular reason for this? I wouldn't expect consistent results
> out of *any* compiler which is not directly supported by Sun.
I won't shoot myself in the foot here but I built that GCC release and I
slaved ov
> Alright. Thanks very much to everyone for their input so far; now I (sort
> of) know what to look for. I have no control over the server's
> configuration, only my makefile, and this server is brand new to me. As it
> stands, the situation is pretty grim. Ready?
>
> sol:~/graphics>where gcc
> /o
> Greg wrote:
>> Hi all. For starters, uname -a:
>> SunOS sol 5.10 Generic_137111-08 sun4u sparc SUNW,Sun-Fire-880
>>
>> Something about my makefile and/or my environment is broken. When I
>> compile this program:
>>
>> #include
>> main(){std::cout << "Hello\n";}
>>
>> with
>>
>> g++ -O1 simple.c
Actually, C++ is *highly* sensitive to the compiler and libraries used.
At present, there is only one officially guaranteed compatible C++
library, and its not libstdc++ (its libC used with Studio.)
Using libstdc++ almost guarantees that you won't be able to link with
any other C++ libraries
Dennis Clarke wrote:
James wrote:
Don't use the blastwave versions of libstdc++
Why not ?
Works perfectly for me.
...
$ ./hello
Hello, world!
So what/where is the problem ?
Hi Dennis,
I wasn't aware when I sent that suggestion that Greg's build
system had several different versions of g+
Alright. Thanks very much to everyone for their input so far; now I (sort of)
know what to look for. I have no control over the server's configuration, only
my makefile, and this server is brand new to me. As it stands, the situation is
pretty grim. Ready?
sol:~/graphics>where gcc
/opt/csw/gcc4
Greg wrote:
Hi all. For starters, uname -a:
SunOS sol 5.10 Generic_137111-08 sun4u sparc SUNW,Sun-Fire-880
Something about my makefile and/or my environment is broken. When I compile
this program:
#include
main(){std::cout << "Hello\n";}
with
g++ -O1 simple.cpp -o simple
then ldd -r simple
I'm quite aware of proper return types, etc. but I wanted a very short sample
program.
The #include problem was caused by the forum system failing to properly escape
an angle bracket.
Assuming my sample program compiles and runs without -O (which it does), what
sort of environment misconfigura
Stroustrup writes in hello_world.c referenced above,
note that "return 0;" isn't required in ISO C++
--
This message posted from opensolaris.org
hello_world.c
Description: Binary data
___
opensolaris-code mailing list
opensolaris-code@opensolaris.org
h
Your program is wrong at line 1; #include is missing its filename.
cf. Stroustrup, The C++ Programming Language, pg 46, sec 3.2, Hello world
program.
I have:
# uname -a
SunOS hank 5.11 snv_123 sun4u sparc sun4u
# /usr/sfw/bin/g++ --version | head -1
g++ (GCC) 3.4.3 (csl-sol210-3_4-20050802)
I
Greg wrote:
Hi all. For starters, uname -a:
SunOS sol 5.10 Generic_137111-08 sun4u sparc SUNW,Sun-Fire-880
Something about my makefile and/or my environment is broken. When I compile
this program:
#include
main(){std::cout << "Hello\n";}
(Note I'm not the biggest fan of C++, but I do have s
Hi all. For starters, uname -a:
SunOS sol 5.10 Generic_137111-08 sun4u sparc SUNW,Sun-Fire-880
Something about my makefile and/or my environment is broken. When I compile
this program:
#include
main(){std::cout << "Hello\n";}
with
g++ -O1 simple.cpp -o simple
then ldd -r simple:
lib
I'm looking for code reviews for a fix to 6878048, if anyone's willing
to look at it. It's not a large change, less than 300 lines changed.
The webrev is here: http://cr.opensolaris.org/~cmynhier/6878048/.
The problem with fuser(1M) is that the kernel function dofusers() does
a walk of the addre
15 matches
Mail list logo