Thread: [orbitcpp-list] orbitcpp-0.30 is out!
Status: Beta
Brought to you by:
philipd
Menu
▾
▴
orbitcpp-list
|
From: Phil D. <ph...@us...> - 2001-02-06 20:43:31
|
Hi All,
I've just uploaded orbitcpp-0.30 to sourceforge...
Release notes:
This is the first release to track the 0.5-stable ORBit releases.
This version requires ORBit-0.5.7
Changes:
- new support for ORBit-0.5-stable series
- new support for typecodes and any
(Thanks to John Luebs and Sam Couter for this)
- lots of bugs in orbitcpp and ORBit squashed
Follow the download link off http://orbitcpp.sourceforge.net/
Have fun,
- Phil
|
|
From: Laszlo M. <las...@et...> - 2001-02-07 14:56:44
|
> I've just uploaded orbitcpp-0.30 to sourceforge... Be careful, Makefile.buildvars is missing from the tarball. Laszlo |
|
From: Konrad P. <ko...@cr...> - 2001-02-07 19:35:23
|
Hey guys,
Just read about the 0.30 release and wanted to try it out.
However I get the following error when trying to compile the
tarball vom sourceforge:
c++ -DHAVE_CONFIG_H -I. -I. -I. -I.. -I..
-I/usr/lib/glib/include -I/usr/include -g -O0 -Wall -c
orbitcpp_poa.cc -fPIC -DPIC -o .libs/orbitcpp_poa.lo
In file included from ../orb/orbitcpp_poa.hh:41,
from orbitcpp_poa.cc:30:
../orb/orbitcpp_sequence.hh:199: `operator new' takes type
`size_t' as first parameter
../orb/orbitcpp_sequence.hh:235: `operator new' takes type
`size_t' as first parameter
In file included from orbitcpp_poa.cc:30:
../orb/orbitcpp_poa.hh:49: `operator new' takes type `size_t' as
first parametermake[1]: *** [orbitcpp_poa.lo] Error 1
make[1]: Leaving directory `/home/konrad/build/orbitcpp-0.30/orb'
This is debian potato on alpha.
gcc version is 2.95.2 and orbit is 0.5.7.
I looked at these files but I couldn't quite figure out what's
wrong.
Thanx for any help in advance,
Konrad
________________________________________________________________
.~. Konrad Podloucky GnuPG/PGP-key available by request
/V\ Why Bill Gates has succeeded:
// \\ "The obvious mathematical breakthrough would be
/( )\ development of an easy way to factor large prime
^^-^^ numbers." The Road Ahead (1995), page 265
|
|
From: Phil D. <ph...@us...> - 2001-02-08 23:14:21
|
Hi Konrad,
I think I know what this is - you're running this on a 64 bit arch,
and I've only tested on 32bit intel.
The reason that the compiler barfs on yours and not on mine is because
on intel, sizeof(size_t) == sizeof(CORBA::ULong) (32 bits), but on 64
bit alpha sizeof(size_t) == 8, and sizeof(CORBA::ULong) == 4.
If you change the
void* operator new(CORBA::ULong size)
lines to
void* operator new(size_t size)
in orbitcpp_sequence, and
<< "::operator new(" IDL_CORBA_NS"::ULong size) {" << endl;
to
<< "::operator new(size_t size) {" << endl;
in compiler/types.cc, then that should fix it.
Please let me know how you get on - as I say, I haven't tested on a 64
bit platform.
I'll release an orbitcpp-0.30.1 with this fix and the
Makefile.buildvars included once we know this is working.
Thanks for the bug report,
Phil
Konrad Podloucky writes:
> Hey guys,
> Just read about the 0.30 release and wanted to try it out.
> However I get the following error when trying to compile the
> tarball vom sourceforge:
> c++ -DHAVE_CONFIG_H -I. -I. -I. -I.. -I..
> -I/usr/lib/glib/include -I/usr/include -g -O0 -Wall -c
> orbitcpp_poa.cc -fPIC -DPIC -o .libs/orbitcpp_poa.lo
> In file included from ../orb/orbitcpp_poa.hh:41,
> from orbitcpp_poa.cc:30:
> ../orb/orbitcpp_sequence.hh:199: `operator new' takes type
> `size_t' as first parameter
> ../orb/orbitcpp_sequence.hh:235: `operator new' takes type
> `size_t' as first parameter
> In file included from orbitcpp_poa.cc:30:
> ../orb/orbitcpp_poa.hh:49: `operator new' takes type `size_t' as
> first parametermake[1]: *** [orbitcpp_poa.lo] Error 1
> make[1]: Leaving directory `/home/konrad/build/orbitcpp-0.30/orb'
>
> This is debian potato on alpha.
> gcc version is 2.95.2 and orbit is 0.5.7.
>
> I looked at these files but I couldn't quite figure out what's
> wrong.
>
> Thanx for any help in advance,
> Konrad
>
>
> ________________________________________________________________
> .~. Konrad Podloucky GnuPG/PGP-key available by request
> /V\ Why Bill Gates has succeeded:
> // \\ "The obvious mathematical breakthrough would be
> /( )\ development of an easy way to factor large prime
> ^^-^^ numbers." The Road Ahead (1995), page 265
>
> _______________________________________________
> orbitcpp-list mailing list
> orb...@li...
> http://lists.sourceforge.net/lists/listinfo/orbitcpp-list
>
|
|
From: Konrad P. <ko...@cr...> - 2001-02-08 23:35:35
|
On 08-Feb-2001 Phil Dawes enlightened me with:
[...]
> If you change the
> void* operator new(CORBA::ULong size)
> lines to
> void* operator new(size_t size)
> in orbitcpp_sequence, and
> << "::operator new(" IDL_CORBA_NS"::ULong size) {" << endl;
> to
> << "::operator new(size_t size) {" << endl;
> in compiler/types.cc, then that should fix it.
>
> Please let me know how you get on - as I say, I haven't tested
> on a 64
> bit platform.
>
Thanx Phil! This works. I had to change 3 lines in
orbitcpp_sequence.hh and one in types.cc.
I haven't made any test programs yet, but it compiles fine.
thnx again,
Konrad
________________________________________________________________
.~. Konrad Podloucky GnuPG/PGP-key available by request
/V\ Why Bill Gates has succeeded:
// \\ "The obvious mathematical breakthrough would be
/( )\ development of an easy way to factor large prime
^^-^^ numbers." The Road Ahead (1995), page 265
|
|
From: Phil D. <ph...@us...> - 2001-02-09 09:37:18
|
Hi Konrad,
Could you do a 'make check' in the test directory, and let me know if
there are any failures.
Cheers,
Phil
Konrad Podloucky writes:
>
> On 08-Feb-2001 Phil Dawes enlightened me with:
> [...]
> > If you change the
> > void* operator new(CORBA::ULong size)
> > lines to
> > void* operator new(size_t size)
> > in orbitcpp_sequence, and
> > << "::operator new(" IDL_CORBA_NS"::ULong size) {" << endl;
> > to
> > << "::operator new(size_t size) {" << endl;
> > in compiler/types.cc, then that should fix it.
> >
> > Please let me know how you get on - as I say, I haven't tested
> > on a 64
> > bit platform.
> >
> Thanx Phil! This works. I had to change 3 lines in
> orbitcpp_sequence.hh and one in types.cc.
> I haven't made any test programs yet, but it compiles fine.
>
> thnx again,
> Konrad
>
> ________________________________________________________________
> .~. Konrad Podloucky GnuPG/PGP-key available by request
> /V\ Why Bill Gates has succeeded:
> // \\ "The obvious mathematical breakthrough would be
> /( )\ development of an easy way to factor large prime
> ^^-^^ numbers." The Road Ahead (1995), page 265
>
> _______________________________________________
> orbitcpp-list mailing list
> orb...@li...
> http://lists.sourceforge.net/lists/listinfo/orbitcpp-list
>
|
|
From: Konrad P. <ko...@cr...> - 2001-02-09 16:29:47
|
On 09-Feb-2001 Phil Dawes enlightened me with:
> Hi Konrad,
>
> Could you do a 'make check' in the test directory, and let me
> know if
> there are any failures.
>
Did that and it looks very good! No failures at all.
bye,
Konrad
________________________________________________________________
.~. Konrad Podloucky GnuPG/PGP-key available by request
/V\ Why Bill Gates has succeeded:
// \\ "The obvious mathematical breakthrough would be
/( )\ development of an easy way to factor large prime
^^-^^ numbers." The Road Ahead (1995), page 265
|
|
From: Phil D. <ph...@us...> - 2001-02-08 23:14:18
|
Hi Laszlo, Erk - you're right! Shouldn't affect the build though. It'll just mean that things arent built with debugging AFAICS. Cheers, Phil Laszlo Molnar writes: > > I've just uploaded orbitcpp-0.30 to sourceforge... > > Be careful, Makefile.buildvars is missing from the tarball. > > Laszlo > > _______________________________________________ > orbitcpp-list mailing list > orb...@li... > http://lists.sourceforge.net/lists/listinfo/orbitcpp-list > |
|
From: Laszlo M. <las...@et...> - 2001-02-09 10:01:55
|
Hi, Well, I just wanted to rerun automake to get rid of the debugging CXXFLAGS from orb/Makefile.in - and it missed this file. Finally I downloaded the file through cvsweb so no problems. Unfortunately there seems to be some other problems too: 1, on sparc-solaris libtool told me, that there are unresolved references in the idl c++ backend from libstdc++, which it can only resolv from a shared libstdc++. Which I don't have :( Is is possible to work around this problem, or should I build a shared libstdc++? 2, On linux/ia32 (where I have a shared libstdc++) I get tons of warnings in the generated files using -Wall -W. Most (or all?) of them is about an unused parameter in the "operator new"s. It would be nice to see a fix for this in 0.30.1. 3, I'm not sure whether '#pragma inhibit push/pop' is supported, but it does not seems to work for me. I'm not sure whether it should work in the C binding either. Is it supported? Anyway, thanks for your work Laszlo On Thu, Feb 08, 2001 at 05:03:14PM +0000, Phil Dawes wrote: > Hi Laszlo, > > Erk - you're right! > > Shouldn't affect the build though. It'll just mean that things arent > built with debugging AFAICS. |
|
From: Phil D. <ph...@us...> - 2001-02-12 12:49:46
|
Laszlo Molnar writes: > Hi, > > Well, I just wanted to rerun automake to get rid of the debugging > CXXFLAGS from orb/Makefile.in - and it missed this file. Finally I > downloaded the file through cvsweb so no problems. > > Unfortunately there seems to be some other problems too: > > 1, on sparc-solaris libtool told me, that there are unresolved > references in the idl c++ backend from libstdc++, which it can only > resolv from a shared libstdc++. Which I don't have :( Is is possible to > work around this problem, or should I build a shared libstdc++? > I'm afraid that the orbit-idl compiler dynamically loads compiler backends for other languages, so you do need a shared libstdc++. > 2, On linux/ia32 (where I have a shared libstdc++) I get tons of > warnings in the generated files using -Wall -W. Most (or all?) of them > is about an unused parameter in the "operator new"s. It would be nice > to see a fix for this in 0.30.1. > Could you mail me the error please? I only get warnings from the C code generated by ORBit on my 32bit intel. > 3, I'm not sure whether '#pragma inhibit push/pop' is supported, but it > does not seems to work for me. I'm not sure whether it should work in > the C binding either. Is it supported? > Not yet, but you mentioning it has pushed it to the top of my TODO list :-) > Anyway, thanks for your work > You're welcome, Cheers, Phil |
|
From: Laszlo M. <las...@et...> - 2001-02-12 14:42:44
|
> > 2, On linux/ia32 (where I have a shared libstdc++) I get tons of
> > warnings in the generated files using -Wall -W. Most (or all?) of them
> > is about an unused parameter in the "operator new"s. It would be nice
> > to see a fix for this in 0.30.1.
> Could you mail me the error please? I only get warnings from the C
> code generated by ORBit on my 32bit intel.
Well, I guess this is the relevant snippet from pass_xlate.cc:
if(idlStruct.isVariableLength()) {
m_header
<< endl
<< indent++ << "void* operator new(size_t size) {" << endl
<< indent << "return "
<< IDL_IMPL_C_NS "::"
<< idlStruct.getQualifiedCIdentifier() << "__alloc();" << endl;
m_header
<< --indent << "};" << endl << endl;
m_header
<< indent++ << "void operator delete(void* c_struct) {" << endl
<< indent << "::CORBA_free(c_struct);" << endl;
m_header
<< --indent << "};" << endl << endl;
}
In the generated "void* operator new(size_t size)" the "size" parameter
is not used, that's why I see warnings in the emitted code. Btw, for
clarity reasons I think op. new and delete could be explicitely defined
as "static". But this is just a syntactic sugar.
> > 3, I'm not sure whether '#pragma inhibit push/pop' is supported, but it
> > does not seems to work for me. I'm not sure whether it should work in
> > the C binding either. Is it supported?
> Not yet, but you mentioning it has pushed it to the top of my TODO
> list :-)
Cool :) In the mean time I simply inserted some "#include"s into the
generated headers, and now I can compile my application. Wow!
Laszlo
|
|
From: Laszlo M. <las...@et...> - 2001-02-13 12:21:54
|
On Mon, Feb 12, 2001 at 12:43:32PM +0000, Phil Dawes wrote: > > 1, on sparc-solaris libtool told me, that there are unresolved > > references in the idl c++ backend from libstdc++, which it can only > > resolv from a shared libstdc++. Which I don't have :( Is is possible to > > work around this problem, or should I build a shared libstdc++? > I'm afraid that the orbit-idl compiler dynamically loads compiler > backends for other languages, so you do need a shared libstdc++. FYI, it seems that stlport (www.stlport.org) can be used instead of libstdc++. Now orbitcpp works nicely on sparc/solaris. Laszlo |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X