headers
Oliver Tappe | 1 Aug 2004 16:31
Picon

libstdc++.r4.so

Hello there,

inspired by the thread-safety problems I encountered with R5's 
libstdc++.r4.so and a discussion on openbeosstorage, I have tried to build 
a stdc++-lib which could be used as a drop-in replacement for the one used 
in R5.

I try to be brief, but it isn't easy... >;o)

The current state of things is that I have built two versions of libstdc++ 
(one based on gnupro000224 and the other one on gcc-2.95.3) that seem to be 
compatible enough with the R5-one to let me use Pe and Beam on R5. So far, 
so good.

One general concept of libstdc++ is that it includes the c++-parts of libio 
and uses the c-parts of libio already contained in libroot. Thus, libio 
gets "split" across these two libs.
However, when trying to incorporate libstdc++ into the haiku-tree, I've 
noticed that there's a version-mismatch between the libio expected from 
libstdc++ and the one provided by haiku's libroot.

Ideally, we'd use the c++-parts of the very libio whose c-parts already 
live in src/kernel/libroot/posix/glibc/libio. Axel, which glibc version is 
that?

After doing some research on the net, I am still confused about the exact 
distributions of libio. There seems to be some correlation between gcc- and 
glibc-versions, but how that actually works escapes me. Anyone in the know?

cheers,
(Continue reading)

Permalink | Reply | 1 comment |
headers
Oliver Tappe | 1 Aug 2004 16:35
Picon

gcc-2.95.3

Hi again,

I know that the gcc-2.95.3 from bebits isn't working properly, so I would 
really like to try to make it *do* work (gcc-2.95.3 seems to be widely used 
on other systems, so it can't really be that bad).

In order to help me fix it, it'd be great if anyone could send me 
example-code of where this compiler fails (mostly template-related IIRC?).

cheers,
	Oliver
Permalink | Reply | 29 comments |
headers
Stefano Ceccherini | 2 Aug 2004 11:51
Picon

Re: gcc-2.95.3


			
-----Messaggio Originale----- 
Da: Oliver Tappe <openbeos@...>
A: openbeos@...
Data invio: Sun, 01 Aug 2004 16:35:32 +0200
Oggetto: Re: [openbeos] gcc-2.95.3

>In order to help me fix it, it'd be great if anyone could >send me 
>example-code of where this compiler fails (mostly template->related IIRC?).

Dunno about templates, but I know that the following code produces a crashing executable:

#include <fstream>

int main()
{
  ifstream s("SOMEVALIDFILENAME");

}

Hope that code compiles :)

Stefano Ceccherini aka Jack Burton
-----------------------------------------------------------
La nuova Email di superEva e' piu' veloce, piu' sicura, ed
ha molte nuove funzioni utili, provala!
http://webmail.supereva.it/
-----------------------------------------------------------
(Continue reading)

Permalink | Reply | 0 comments |
headers
Larry Baydak | 3 Aug 2004 04:01
Favicon

Re: need help, file copying problems!

This information may be redundant - forgive me for boring you.

SCSI -  Must have termination at both  'ends'  of the cable.
          - The controller card/motherboard usually has termination 
built in.
             So that end of the cable is already taken care of.
          - However - the other 'end'  of the cable can either be a 
SCSI
             device with  termination  enabled.  Or an actual SCSI 
termination plug.
          -  Some SCSI devices may not  have  any termination 
capability. 
             So they should not be used at the end of the cable.
           -  Finally - only use one termination device for each end.  
Having  two
              or more terminating devices (or termination plugs)  on 
the outboard
              end of the cable will also prevent SCSI from working.  

I have one other suggestion.

POWER SUPPLY -   Perhaps your power supply is  going bad.
This apparently is common failing of the 'cheap' power supply units 
they put
into many store assembled PC's.  It happened to me.
My boot disk went 'bad'.  I replaced it.  It worked for about 2 months
and then the new disk went 'bad' also. 
It Turned out that the power supply was slowly failing and some 
voltages were
degrading. A new power supply - and suddenly both my 'bad' disks were
(Continue reading)

Permalink | Reply | 6 comments |
headers
Finn Bastiansen | 3 Aug 2004 06:54
Picon

Re: gcc-2.95.3

Hi Oliver,

I once tried to compile 8Dock with the buggy gcc from BeBits. I got a lot of 
errors which do not occur when using another gcc build. You might want to 
try to build that for yourself to see what goes wrong.
I am sending you the source off-list.

Hope that helps,
Finn

On 2004-08-01 at 16:36:10 [+0200], you wrote:
> Hi again,
> 
> I know that the gcc-2.95.3 from bebits isn't working properly, so I would
> really like to try to make it *do* work (gcc-2.95.3 seems to be widely used
> on other systems, so it can't really be that bad).
> 
> In order to help me fix it, it'd be great if anyone could send me
> example-code of where this compiler fails (mostly template-related IIRC?).
> 
> cheers,
>     Oliver
Permalink | Reply | 0 comments |
headers
Kevin Field | 3 Aug 2004 14:36
Favicon
Gravatar

Re: need help, file copying problems!

Thanks for the info--it was a store-assembled one (and it's getting old, too),
so that may just be the cause.  I'll drag the ol' voltmeter out tonight and
see what it's reading.

Thanks,

Kev

----- Original Message ---------------
>This information may be redundant - forgive me for boring you.
>
>SCSI -  Must have termination at both  'ends'  of the cable.
>          - The controller card/motherboard usually has termination 
>built in.
>             So that end of the cable is already taken care of.
>          - However - the other 'end'  of the cable can either be a 
>SCSI
>             device with  termination  enabled.  Or an actual SCSI 
>termination plug.
>          -  Some SCSI devices may not  have  any termination 
>capability. 
>             So they should not be used at the end of the cable.
>           -  Finally - only use one termination device for each end.  
>Having  two
>              or more terminating devices (or termination plugs)  on 
>the outboard
>              end of the cable will also prevent SCSI from working.  
>              
>I have one other suggestion.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Axel Dörfler | 3 Aug 2004 22:07
Picon

Re: libstdc++.r4.so

Oliver Tappe <openbeos@...> wrote:
> One general concept of libstdc++ is that it includes the c++-parts of 
> libio 
> and uses the c-parts of libio already contained in libroot. Thus, 
> libio 
> gets "split" across these two libs.
> However, when trying to incorporate libstdc++ into the haiku-tree, 
> I've 
> noticed that there's a version-mismatch between the libio expected 
> from 
> libstdc++ and the one provided by haiku's libroot.

I guess this is not good :)

> Ideally, we'd use the c++-parts of the very libio whose c-parts 
> already 
> live in src/kernel/libroot/posix/glibc/libio. Axel, which glibc 
> version is 
> that?

Judging from the version.h file, it might be 2.3.2 - but it came 
straight from CVS, so it's probably something inbetween this and a 
newer version.

> After doing some research on the net, I am still confused about the 
> exact 
> distributions of libio. There seems to be some correlation between 
> gcc- and 
> glibc-versions, but how that actually works escapes me. Anyone in the 
> know?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alan Westbrook | 5 Aug 2004 00:34

Re: [Open-beos-cvs]CVS: current/src/add-ons/print/transports/usb_port print_transport.cpp,1.4,1.5

I saw this checkin, and am concenred about the symantics of InitCheck() here.

I believe that InitCheck() everywhere else should be returning a status_t.

It returns a bool here. This could be the cause of major future bugs, as people will likely be 
checking against B_OK (which is equivalent to false, or 0), and not know why InitCheck() is failing.

Might I suggest

	return fFile > -1 ? B_OK : B_ERROR;

or ever caching the error value in fFile or another var and returning that. It seems a shame to 
throw away perfectly good error values as the code currently does.

Alan

Philippe Houdoin wrote:
> Update of /cvsroot/open-beos/current/src/add-ons/print/transports/usb_port
> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv25424/src/add-ons/print/transports/usb_port
> 
> Modified Files:
> 	print_transport.cpp 
> Log Message:
> Follow the InitCheck() model. 
> 
> Index: print_transport.cpp
> CVS Browser:
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/open-beos/current/src/add-ons/print/transports/usb_port/print_transport.cpp
> ===================================================================
> RCS file: /cvsroot/open-beos/current/src/add-ons/print/transports/usb_port/print_transport.cpp,v
(Continue reading)

Permalink | Reply | 5 comments |
headers
Michael Pfeiffer | 5 Aug 2004 07:38
Picon

Re: [Open-beos-cvs]CVS: current/src/add-ons/print/transports/usb_port print_transport.cpp,1.4,1.5

On Wed, 04 Aug 2004 15:34:54 -0700, Alan Westbrook <alan@...>  
wrote:

> I saw this checkin, and am concenred about the symantics of InitCheck()  
> here.
>
> I believe that InitCheck() everywhere else should be returning a  
> status_t.

InitCheck is used in this source file only and it is not intended to
be used anywhere else, so why should we worry about it?

- Michael
Permalink | Reply | 4 comments |
headers
Alan Westbrook | 5 Aug 2004 10:20

Re: [Open-beos-cvs]CVS: current/src/add-ons/print/transports/usb_port print_transport.cpp,1.4,1.5

Consistency, especially internally, is always good.

I mean, that's the reason it got changed to InitCheck() in the first place, right?

Ok, so in this case, it's super specific to the code in question, and isn't going to affect any 3rd 
party devs. But it could conceviably have a tertiary effect of influencing other internal code, and 
evenutally spin out of control to consume existence as we know it!

Perhaps not ...

Alan

Michael Pfeiffer wrote:
> On Wed, 04 Aug 2004 15:34:54 -0700, Alan Westbrook 
> <alan@...>  wrote:
> 
>> I saw this checkin, and am concenred about the symantics of 
>> InitCheck()  here.
>>
>> I believe that InitCheck() everywhere else should be returning a  
>> status_t.
> 
> 
> InitCheck is used in this source file only and it is not intended to
> be used anywhere else, so why should we worry about it?
> 
> - Michael
>
(Continue reading)

Permalink | Reply | 3 comments |

Gmane