orbitcpp-list

[orbitcpp-list] build issues

[Brian C. <bc...@th...>]

I'm having a number of problems with the build. I'm building from cvs, since it
has a spec file.

o Generating autoconf/automake/libtool files. Is there a doc anywhere on
  this? They don't seem to be decending into the compiler directory
  correctly, and so I end up having to manually run half a dozen commands
  to get the build off the ground.

o After running all the above, "make dist" fails to work because standard
  files (like AUTHORS) are missing in the compiler directory, as well as 
  CosNaming-cpp-common.hh, and perhaps others. Seems to be the same problem
  as above.

o The changelog in the .spec file is broken such that rpm refuses to attempt a
  build.

o There's an unchecked (by configure or rpm) dependency on <sstream>, which 
  appears to be supported only by recent gcc. I think this is supposed to
  be handled by checking HAVE_STD_IOSTREAM and typedef'ing ostrstream to
  ostringstream.

o The template partial specialization in orbitcpp_sequence.hh also seems to
  only work with recent gcc, though older versions reportedly support partial
  specialization. I'm not sure what the problem is.

b.c.

Re: [orbitcpp-list] build issues

[Sam C. <sc...@bi...>]

Brian Craft <bc...@th...> wrote:
> I'm having a number of problems with the build. I'm building from cvs, si=
nce it
> has a spec file.
>=20
> o Generating autoconf/automake/libtool files. Is there a doc anywhere on
>   this? They don't seem to be decending into the compiler directory
>   correctly, and so I end up having to manually run half a dozen commands
>   to get the build off the ground.
>=20
> o After running all the above, "make dist" fails to work because standard
>   files (like AUTHORS) are missing in the compiler directory, as well as=
=20
>   CosNaming-cpp-common.hh, and perhaps others. Seems to be the same probl=
em
>   as above.

There is a script provided, called "autogen.sh", which will run
automake, autoconf and friends correctly. This should solve both of the
above problems.

> o The changelog in the .spec file is broken such that rpm refuses to atte=
mpt a
>   build.

I've forgotten most of what I used to know about RPM, so I can't help
you with this. Braden may be able to provide more help, since he's
worked on the .spec file in the past.

You could just nuke the changelog to get it to build.

> o There's an unchecked (by configure or rpm) dependency on <sstream>, whi=
ch=20
>   appears to be supported only by recent gcc. I think this is supposed to
>   be handled by checking HAVE_STD_IOSTREAM and typedef'ing ostrstream to
>   ostringstream.

The stringstream is only used in one place, to convert an integer into a
string, so the dependency could be removed with very little trouble.

> o The template partial specialization in orbitcpp_sequence.hh also seems =
to
>   only work with recent gcc, though older versions reportedly support par=
tial
>   specialization. I'm not sure what the problem is.

I've been building with GCC 2.95 and 3.0, which both work fine. GCC has
historically had many many problems with templates.

However, templates are a C++ black art that I don't fully understand,
and I don't even know what partial specialization is, so I can't help
with this either. Are you unable to use a recent GCC for some reason?
--=20
Sam "Eddie" Couter  |  mailto:sc...@bi...
Debian Developer    |  mailto:ed...@de...
                    |  jabber:sa...@ja...
OpenPGP fingerprint:  A46B 9BB5 3148 7BEA 1F05  5BD5 8530 03AE DE89 C75C

Re: [orbitcpp-list] build issues

[Brian C. <bc...@th...>]

On Tue, Feb 26, 2002 at 09:12:49AM +1100, Sam Couter wrote:
> > o The template partial specialization in orbitcpp_sequence.hh also seems to
> >   only work with recent gcc, though older versions reportedly support partial
> >   specialization. I'm not sure what the problem is.
> 
> I've been building with GCC 2.95 and 3.0, which both work fine. GCC has
> historically had many many problems with templates.
> 
> However, templates are a C++ black art that I don't fully understand,
> and I don't even know what partial specialization is, so I can't help
> with this either. Are you unable to use a recent GCC for some reason?

The project I'm working on supports RedHat 6.x, which uses egcs 1.1.2. It's
supposed to support partial specialization, but the orbitcpp build fails, like
so:

c++ -DORBITCPP_MAJOR_VERSION=0 -DORBITCPP_MINOR_VERSION=30 -DORBITCPP_MICRO_VERSION=3 -DPACKAGE=\"orbitcpp\" -DVERSION=\"0.30.3\" -DSTDC_HEADERS=1 -I. -I. -I.. -I.. -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/include/orbit-1.0 -O2 -march=i386 -mcpu=i686 -Wp,-MD,.deps/orbitcpp_poa.pp -c orbitcpp_poa.cc  -fPIC -DPIC -o .libs/orbitcpp_poa.lo
In file included from orbitcpp_poa.cc:30:
../orb/orbitcpp_poa.hh:48: template-id `operator new<>' for `::_orbitcpp::::_orbitcpp::UnboundedSequenceTmpl<unsigned char,PortableServer_sequence_octet>::operator new<>(size_t)' does not match any template declaration
../orb/orbitcpp_poa.hh:48: confused by earlier errors, bailing out
make: *** [orbitcpp_poa.lo] Error 1

Debugging template problems is like divining stock prices from cloud
formations, in my experience. 

b.c.

Re: [orbitcpp-list] build issues

[<bb...@ya...>]

From memory RH 6.2 comes with gcc 2.95 - or it is at least available
as RPM in a mirror of contrib packages. Of course you might have
trouble finding an old version like that. rpmfind.net is your friend.

 --- Brian Craft <bc...@th...> wrote: 
> The project I'm working on supports RedHat 6.x, which uses egcs
> 1.1.2. It's
> supposed to support partial specialization, but the orbitcpp build
> fails, like
> so:
> 


http://movies.yahoo.com.au - Yahoo! Movies
- Vote for your nominees in our online Oscars pool.

Re: [orbitcpp-list] build issues, overloading new()

[Brian C. <bc...@th...>]

Looks like overloading new() is the real problem. I get the same error
with this code:

template <class T, class CSEQTYPE>
class UnboundedSequenceTmpl {
  public:
    void* operator new(int size);
};

void* UnboundedSequenceTmpl<char*, int>::operator new(int size)
{
  return 0;
}

Changing this to operator+ avoids the compile error. Dunno what's going on
here.

b.c.

Re: [orbitcpp-list] build issues, overloading new()

[Brian C. <bc...@th...>]

hm. Well, the new()/delete() problem can be avoided by creating static
functions that do the real work. But later in the build I run into this:

c++ -DORBITCPP_MAJOR_VERSION=0 -DORBITCPP_MINOR_VERSION=30 -DORBITCPP_MICRO_VERSION=3 -DPACKAGE=\"orbitcpp\" -DVERSION=\"0.30.3\" -DSTDC_HEADERS=1 -I. -I. -I../.. -I../.. -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/include/orbit-1.0 -O2 -march=i386 -mcpu=i686 -Wp,-MD,.deps/CosNaming.pp -c CosNaming.cc  -fPIC -DPIC -o .libs/CosNaming.lo
../../orb/orbitcpp_smartptr.hh: In method `::_orbitcpp::::_orbitcpp::ObjectPtr_out<::CosNaming::BindingIterator,::_orbitcpp::stub::CosNaming::BindingIterator *>::operator CORBA_Object_struct **<::CosNaming::BindingIterator, ::_orbitcpp::stub::CosNaming::BindingIterator *>()':
CosNaming.cc:304:   instantiated from here
../../orb/orbitcpp_smartptr.hh:180: non-lvalue in unary `&'
make: *** [CosNaming.lo] Error 1


Err. yeah. From CosNaming.cc, that's

void _orbitcpp::stub::CosNaming::NamingContext::list(CORBA::ULong how_many,::CosNaming::BindingList_out bl,::CosNaming::BindingIterator_out bi) {
  ::_orbitcpp::CEnvironment _ev;
  ::_orbitcpp::c::CosNaming_NamingContext_list(_orbitcpp_get_c_object(),reinterpret_cast< const CORBA_unsigned_long&>(how_many),reinterpret_cast< ::_orbitcpp::c::CosNaming_BindingList**>(&bl.ptr()),bi,_ev);
  _ev.propagate_sysex();
  if (_ev->_major == ::CORBA_USER_EXCEPTION) {
    throw CORBA::UnknownUserException();
  }
}

... and people think perl is unreadable. ;)

b.c.

Re: [orbitcpp-list] build issues, work-around

[Brian C. <bc...@th...>]

I seem to have the build working on RH 6.x, now. I punted egcs and installed
gcc 2.95, as someone suggested. There's still the issue of the stdc++ not
supporting ostringstream.

Would you accept a patch to fix the ostringstream thing? This could be either a
patch to conditionally use ostrstream (which I believe would require an
autoconf test to see which is available), or a patch to ditch it entirely and
use sprintf to a static buffer. The latter has the disadvantage that it could
overflow, but I think it's a safe call that no one will have more than a google
or two of skeleton wrappers. So, say, 100 bytes is way more than needed.

b.c.

Re: [orbitcpp-list] build issues, work-around

[<bb...@ya...>]

I would prefer to see an autoconf test. 
All STL implementation from now on must support ostringstream to have
a hope of calling themselves standard compliant. For this reason I'd
prefer to leave the ostringstream in there. It is legal code and it
follows "the C++ way" of doing things. Only legacy implementations of
the STL would have a problem.

From memory there is a standard compliant STL drop-in for gcc-2.95
(libstdc++-2.95.10 from memory) which supports ostringstream.

Note that gcc 2.95 requires the -fhonor-standard flag in some cases
to make the standard compliance code kick in.


--
Rich

 --- Brian Craft <bc...@th...> wrote: 
> Would you accept a patch to fix the ostringstream thing? This could
> be either a
> patch to conditionally use ostrstream (which I believe would
> require an
> autoconf test to see which is available), or a patch to ditch it
> entirely and
> use sprintf to a static buffer. The latter has the disadvantage
> that it could
> overflow, but I think it's a safe call that no one will have more
> than a google
> or two of skeleton wrappers. So, say, 100 bytes is way more than
> needed.


http://movies.yahoo.com.au - Yahoo! Movies
- Vote for your nominees in our online Oscars pool.