orbitcpp-list

Re: [orbitcpp-list] What's this?

[Bruce I. <nr...@us...>]

Andreas Kloeckner wrote:
> 
> > > Now there's something strange here. 8-|
> >
> > What? Did it compile the IDL correctly for you?
> 
> This was actually referring to Netscape always clipping this one line I
> wanted to send. But heck, who cares. Yes, the IDL compiled correctly for
> me. Here's what I did, I suspect you omitted the -lc step.
> 
> orbit-idl -lc stuff.idl         # <-- this one
> orbit-idl -lc++ stuff.idl
> gcc -c *.c `orbit-config --cflags client server`
> g++ -c *.cc `orbit-config --cflags client server`

That, in fact, worked. I did get a bunch of compiler errors because I
was trying to use STL in a private variable. I suspect gcc 2.95.2
doesn't like STL. It errors out in the C headers and not in anything
that seems to be related to OrbitCPP. Has anyone else seen problems with
this? I'd really like to use the advanced features of C++ with OrbitCPP
:-)

If I'm not making another silly mistake here, maybe we should send a bug
report to the GCC maintainers.

> 
> (as you were told by the ... uh ... I guess we _really_ should document
> this step!)
> wasn't there someone who wanted to write a faq for orbitcpp some time
> ago? I'll put this into the FAQ in the archive.

I can write up some questions from things I encountered trying to get it
running when I get home from work tonight. Is there any particular
format that should be used? HTML? Plain Text? LaTeX? I can work with a
lot of them.

-- 
Bruce Ide                        nr...@us...
If trees screamed would we be as quick to cut them down? Possibly,
if they screamed all the time.

Re: [orbitcpp-list] What's this?

[Andreas K. <ak...@ix...>]

> > Now there's something strange here. 8-|
> 
> What? Did it compile the IDL correctly for you?

This was actually referring to Netscape always clipping this one line I
wanted to send. But heck, who cares. Yes, the IDL compiled correctly for
me. Here's what I did, I suspect you omitted the -lc step. 

orbit-idl -lc stuff.idl         # <-- this one
orbit-idl -lc++ stuff.idl
gcc -c *.c `orbit-config --cflags client server`
g++ -c *.cc `orbit-config --cflags client server`

(as you were told by the ... uh ... I guess we _really_ should document
this step!)
wasn't there someone who wanted to write a faq for orbitcpp some time
ago? I'll put this into the FAQ in the archive.

bye
andy

-- 
Don't innovate, intimidate.

Re: [orbitcpp-list] What's this?

[Bruce I. <bru...@ec...>]

Andreas Kloeckner wrote:
> 
> Now there's something strange here. 8-|
> 
> <SNIP>

What? Did it compile the IDL correctly for you?

-- 
Bruce Ide                                           
bru...@ec...
"GP: Is Eris True?" "M2: Everything is true." "GP: Even false things?"
"M2: Even false things are true." "GP: How can that be?" "M2: I don't 
know, man. I didn't do it."

Re: [orbitcpp-list] What's this?

[Andreas K. <ak...@ix...>]

Now there's something strange here. 8-|

Andreas Kloeckner wrote:
> 
> Hmmm, my message got truncated somehow. (Perhaps my stupidity, who
> knows.) Here's what I meant to say.
> 
> Andreas Kloeckner wrote:
> > Hi Bruce,
> >
> 
> > matter of fact, anything that makes the compiler generate erroneous c++
> > is) I'm sorry that you ran into this at this point, and it should help
> > us fix it if you'd post the idl that led to the error.
> >
> > thanks
> > andy
> 

-- 
Don't innovate, intimidate.

Re: [orbitcpp-list] What's this?

[Andreas K. <ak...@ix...>]

Hmmm, my message got truncated somehow. (Perhaps my stupidity, who
knows.) Here's what I meant to say.

Andreas Kloeckner wrote:
> Hi Bruce,
> 

From my point of view, this looks like a compiler bug. (as a

> matter of fact, anything that makes the compiler generate erroneous c++
> is) I'm sorry that you ran into this at this point, and it should help
> us fix it if you'd post the idl that led to the error.
> 
> thanks
> andy

Re: [orbitcpp-list] What's this?

[Bruce I. <bru...@ec...>]

Andreas Kloeckner wrote:
> 
> Hi Bruce,
> 
> >From my point of view, this looks like a bug in the idl compiler. (As a
> matter of fact, anything that makes the compiler generate erroneous c++
> is) I'm sorry that you ran into this at this point, and it should help
> us fix it if you'd post the idl that led to the error.

No problem, it's only a few lines. Here it is:

module TestModule {

   interface MyStack {
      void push(in long toPush);
      long pop();
   };
};


-- 
Bruce Ide                                           
bru...@ec...
"GP: Is Eris True?" "M2: Everything is true." "GP: Even false things?"
"M2: Even false things are true." "GP: How can that be?" "M2: I don't 
know, man. I didn't do it."

Re: [orbitcpp-list] What's this?

[Andreas K. <ak...@ix...>]

Hi Bruce,

From my point of view, this looks like a bug in the idl compiler. (As a
matter of fact, anything that makes the compiler generate erroneous c++
is) I'm sorry that you ran into this at this point, and it should help
us fix it if you'd post the idl that led to the error.

thanks
andy

> I've created a cheesy little stack IDL modelling off the examples. The
> IDL compiled, and I created a teststack-impl.hh and teststack-impl.cc
> and derived the classes as I see the examples are. The problem is when I
> try to compile the this tiny bit of code (using g++ -c teststack-impl.cc
> `orbitcpp-config --cflags server` I get the following errors:
> 
> teststack-cpp-skels.hh:18: parse error before `m_cservant'
> teststack-cpp-skels.hh:24: parse error before `_TestModule_MyStack_epv'
> teststack-cpp-skels.hh:25: parse error before `_vepv'

-- 
Don't innovate, intimidate.

[orbitcpp-list] What's this?

[Bruce I. <bru...@ec...>]

I recently downloaded and compiled OrbitCPP, but I'm kind of fumbling
around in the dark here, so please forgive me if this is a stupid
question.

I've created a cheesy little stack IDL modelling off the examples. The
IDL compiled, and I created a teststack-impl.hh and teststack-impl.cc
and derived the classes as I see the examples are. The problem is when I
try to compile the this tiny bit of code (using g++ -c teststack-impl.cc
`orbitcpp-config --cflags server` I get the following errors:

teststack-cpp-skels.hh:18: parse error before `m_cservant'
teststack-cpp-skels.hh:24: parse error before `_TestModule_MyStack_epv'
teststack-cpp-skels.hh:25: parse error before `_vepv'

Along with a bunch of unhappy C++ fluff messages that I can post here if
necessary.

Looking at teststack-cpp-skels.hh, I see the following code:

...
        public:
                struct _orbitcpp_Servant {
                        ::_orbitcpp::c::POA_TestModule_MyStack
m_cservant; // <-- Line 18
                        POA_TestModule::MyStack *m_cppservant;
                } m_target;
...

This strikes me as kind of strange (But I'm fairly new to C++, too.) Is
this supposed to be happening? Did I miss a necessary flag when using
orbit-idl (I did orbit-idl -lc++ teststack.idl) Am I missing a necessary
C flag or include file? Any insights would be appreciated.

PS: FWIW, I'm currently on GCC Version 2.95.2, which I downloaded and
compiled off prep.ai.mit.edu after the egcs that came with RedHat
crapped out trying to compile OrbitCPP. I have the correctly patched
version of ORBIT from the orbitcpp FTP site on my system. The system is
running RedHat 6.2. Please let me know if any more information is
needed.

-- 
Bruce Ide                                           
bru...@ec...
"GP: Is Eris True?" "M2: Everything is true." "GP: Even false things?"
"M2: Even false things are true." "GP: How can that be?" "M2: I don't
know,
man. I didn't do it."

Re: [orbitcpp-list] Yep, I'm the FNG

[Adam Y. <ay...@fo...>]

Yup, that worked.  Got me back to the cross compliling error:
here's my config.log

where does bad_cast come from?  

On my machine I have 

/usr/local/lib/gcc-lib/i386-pc-linux-gnu/2.96/include/exception
and 
/usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/include/exception

Neither have a reference to bad_cast.  
What is the issue with cross compiling?  Cross compiling what? Is there
some way to ignore this test to see what happens?


Adam



This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

configure:603: checking for a BSD compatible install
configure:656: checking whether build environment is sane
configure:713: checking whether make sets ${MAKE}
configure:752: checking for working aclocal
configure:765: checking for working autoconf
configure:778: checking for working automake
configure:791: checking for working autoheader
configure:804: checking for working makeinfo
configure:818: checking whether to enable maintainer-specific portions
of Makefiles
configure:937: checking host system type
configure:958: checking build system type
configure:978: checking for ranlib
configure:1008: checking for gcc
configure:1121: checking whether the C compiler (gcc -g ) works
configure:1137: gcc -o conftest -g   conftest.c  1>&5
configure:1163: checking whether the C compiler (gcc -g ) is a
cross-compiler
configure:1168: checking whether we are using GNU C
configure:1177: gcc -E conftest.c
configure:1196: checking whether gcc accepts -g
configure:1239: checking for ld used by GCC
configure:1301: checking if the linker (/usr/bin/ld) is GNU ld
GNU ld version 2.9.5 (with BFD 2.9.5.0.22)
configure:1317: checking for BSD-compatible nm
configure:1353: checking whether ln -s works
ltconfig:603: checking for object suffix
ltconfig:604: gcc -c -g  conftest.c 1>&5
ltconfig:629: checking for executable suffix
ltconfig:630: gcc -o conftest -g   conftest.c  1>&5
ltconfig:776: checking if gcc PIC flag -fPIC works
ltconfig:777: gcc -c -g -fPIC -DPIC  conftest.c 1>&5
ltconfig:829: checking if gcc supports -c -o file.o
ltconfig:830: gcc -c -g -o out/conftest2.o  conftest.c 1>&5
ltconfig:862: checking if gcc supports -c -o file.lo
ltconfig:863: gcc -c -g -c -o conftest.lo  conftest.c 1>&5
ltconfig:914: checking if gcc supports -fno-rtti -fno-exceptions
ltconfig:915: gcc -c -g -fno-rtti -fno-exceptions -c conftest.c 
conftest.c 1>&5ltconfig:958: checking if gcc static flag -static works
ltconfig:959: gcc -o conftest -g   -static conftest.c  1>&5
GNU ld version 2.9.5 (with BFD 2.9.5.0.22)
ltconfig:1653: checking if global_symbol_pipe works
ltconfig:1654: gcc -c -g  conftest.c 1>&5
ltconfig:1657: eval "/usr/bin/nm -B conftest.o | sed -n -e 's/^.*[ 
]\([ABCDGISTW]\)[ 	][ 	]*\(\)\([_A-Za-z][_A-Za-z0-9]*\)$/\1 \2\3 \3/p' >
conftest.nm"
ltconfig:1709: gcc -o conftest -g -fno-builtin -fno-rtti
-fno-exceptions   conftest.c conftstm.o 1>&5
configure:1541: checking for gcc
configure:1654: checking whether the C compiler (gcc -g ) works
configure:1670: gcc -o conftest -g   conftest.c  1>&5
configure:1696: checking whether the C compiler (gcc -g ) is a
cross-compiler
configure:1701: checking whether we are using GNU C
configure:1729: checking whether gcc accepts -g
configure:1765: checking for c++
configure:1797: checking whether the C++ compiler (c++ -g -Wall ) works
configure:1813: c++ -o conftest -g -Wall   conftest.C  1>&5
configure:1839: checking whether the C++ compiler (c++ -g -Wall ) is a
cross-compiler
configure:1844: checking whether we are using GNU C++
configure:1853: c++ -E conftest.C
configure:1872: checking whether c++ accepts -g
configure:1915: checking for a BSD compatible install
configure:2024: checking for orbit-config
configure:2059: checking for ORBit - version >= 0.5.1
configure:2242: checking for orbit-idl
configure:2288: checking how to run the C preprocessor
configure:2309: gcc -E  conftest.c >/dev/null 2>conftest.out
configure:2368: checking for ANSI C header files
configure:2381: gcc -E  conftest.c >/dev/null 2>conftest.out
configure:2474: checking whether c++ compiler (c++) supports bad_cast
configure:2491: c++ -c -g -Wall  conftest.C 1>&5
configure: In function `int main ()':
configure:2487: `bad_cast' undeclared (first use this function)
configure:2487: (Each undeclared identifier is reported only once for
each function it appears in.)
configure:2487: parse error before `;'
configure: failed program was:
#line 2484 "configure"
#include "confdefs.h"
#include <exception>
int main() {
 bad_cast a; 
; return 0; }
configure:2518: checking for size of c++ new memory info block
[ayoung@yosemite orbitcpp]$ 


Phil Dawes wrote:
> 
> Hi Adam,
> 
> It looks like autoconf/automake can't find the ORBit.m4 macro. If you
> have installed ORBit from source then this is in your installation
> prefix under $PREFIX/share/aclocal/ORBit.m4  (e.g.
> /usr/local/share/aclocal/ORBit.m4).
> 
> I suspect that this macro is not being picked up because aclocal is
> looking in /usr/share/aclocal/
> Try copying the file there and see what happens. (Looks like the same
> for libtool.m4)
> 
> I'm confused about your config.log being empty - noramlly this is filled
> up as the configure script works AFAIK.
> 
> Cheers,
> 
> Phil.
>

Re: [orbitcpp-list] Yep, I'm the FNG

[Phil D. <ph...@us...>]

Hi Adam,

It looks like autoconf/automake can't find the ORBit.m4 macro. If you
have installed ORBit from source then this is in your installation
prefix under $PREFIX/share/aclocal/ORBit.m4  (e.g.
/usr/local/share/aclocal/ORBit.m4).

I suspect that this macro is not being picked up because aclocal is
looking in /usr/share/aclocal/
Try copying the file there and see what happens. (Looks like the same
for libtool.m4)


I'm confused about your config.log being empty - noramlly this is filled
up as the configure script works AFAIK.

Cheers,

Phil.



Adam Young wrote:
> 
> config.log had nothing in it.  I think that is only used once the
> compilation process starts...
> 
> Here's the result of running auotgen.  Does Autoget require ORBIT_LIBS
> to be set from my shell?  If so, what is it looking for?
> 
> Once I get through this, I'll update the HACKING file with these lessons
> learned.
> 
> Adam
> 
> [ayoung@yosemite orbitcpp]$ ./autogen.sh
> I am going to run ./configure with no arguments - if you wish
> to pass any to it, please specify them on the ./autogen.sh command line.
> processing .
> You should add the contents of `/usr/local/share/aclocal/libtool.m4' to
> `aclocal.m4'.
> aclocal: configure.in: 76: macro `AM_PROG_LIBTOOL' not found in library
> Makefile.am:5: HAVE_ORBIT_IDL_BACKENDDIR does not appear in
> AM_CONDITIONAL
> configure.in: 103: required file `orb/orbitcpp_config.hh.in' not found
> orb/Makefile.am:34: variable `ORBIT_LIBS' not defined
> services/name/Makefile.am:17: HAVE_ORBIT_IDL_BACKENDDIR does not appear
> in AM_CONDITIONAL
> test/basic/Makefile.am:4: variable `ORBIT_LIBS' not defined
> test/basic/Makefile.am:4: variable `ORBIT_LIBS' not defined
> test/basic/generated/Makefile.am:21: HAVE_ORBIT_IDL_BACKENDDIR does not
> appear in AM_CONDITIONAL
> test/string/Makefile.am:6: variable `ORBIT_LIBS' not defined
> test/string/Makefile.am:6: variable `ORBIT_LIBS' not defined
> test/string/generated/Makefile.am:21: HAVE_ORBIT_IDL_BACKENDDIR does not
> appear in AM_CONDITIONAL
> test/boolean/Makefile.am:6: variable `ORBIT_LIBS' not defined
> test/boolean/Makefile.am:6: variable `ORBIT_LIBS' not defined
> test/boolean/generated/Makefile.am:21: HAVE_ORBIT_IDL_BACKENDDIR does
> not appear in AM_CONDITIONALtest/everything/Makefile.am:6: variable
> `ORBIT_LIBS' not defined
> test/everything/Makefile.am:6: variable `ORBIT_LIBS' not defined
> test/everything/generated/Makefile.am:21: HAVE_ORBIT_IDL_BACKENDDIR does
> not appear in AM_CONDITIONAL
> test/everything-typedef/Makefile.am:6: variable `ORBIT_LIBS' not defined
> test/everything-typedef/Makefile.am:6: variable `ORBIT_LIBS' not defined
> test/everything-typedef/generated/Makefile.am:21:
> HAVE_ORBIT_IDL_BACKENDDIR does not appear in AM_CONDITIONAL
> test/name/generated/Makefile.am:21: HAVE_ORBIT_IDL_BACKENDDIR does not
> appear in AM_CONDITIONAL
> Running ./configure --enable-maintainer-mode
> loading cache ./config.cache
> ./configure: syntax error near unexpected token
> `AM_INIT_AUTOMAKE($PACKAGE,'
> ./configure: ./configure: line 552: `AM_INIT_AUTOMAKE($PACKAGE,
> $VERSION, no-define)'
> 
> Phil Dawes wrote:
> >
> > Hi Adam,
> >
> > Sorry I took so long to reply - I've been away from the fray for a few
> > days,
> >
> > The standard dev approach we use is to grab autoconf, automake and
> > libtool, then do:
> >
> > ./autogen.sh
> > make
> > make check
> >
> > Then start hacking!
> >
> > Could you mail your config.log file to the mailing list? That file
> > contains more information.
> >
> > I'm not sure what's wrong - I use redhat 6.1 and the configure script
> > works out of the box. It could be a gcc 2.96 thing (I'm using gcc
> > 2.95.2). I'll try and grab a copy of gcc 2.96 today if I remember.
> >
> > Cheers,
> >
> > Phil.
> >
> 
> _______________________________________________
> orbitcpp-list mailing list
> orb...@li...
> http://lists.sourceforge.net/mailman/listinfo/orbitcpp-list

Re: [orbitcpp-list] Yep, I'm the FNG

[Adam Y. <ay...@fo...>]

config.log had nothing in it.  I think that is only used once the
compilation process starts...

Here's the result of running auotgen.  Does Autoget require ORBIT_LIBS
to be set from my shell?  If so, what is it looking for?

Once I get through this, I'll update the HACKING file with these lessons
learned.

Adam


[ayoung@yosemite orbitcpp]$ ./autogen.sh 
I am going to run ./configure with no arguments - if you wish 
to pass any to it, please specify them on the ./autogen.sh command line.
processing .
You should add the contents of `/usr/local/share/aclocal/libtool.m4' to
`aclocal.m4'.
aclocal: configure.in: 76: macro `AM_PROG_LIBTOOL' not found in library
Makefile.am:5: HAVE_ORBIT_IDL_BACKENDDIR does not appear in
AM_CONDITIONAL
configure.in: 103: required file `orb/orbitcpp_config.hh.in' not found
orb/Makefile.am:34: variable `ORBIT_LIBS' not defined
services/name/Makefile.am:17: HAVE_ORBIT_IDL_BACKENDDIR does not appear
in AM_CONDITIONAL
test/basic/Makefile.am:4: variable `ORBIT_LIBS' not defined
test/basic/Makefile.am:4: variable `ORBIT_LIBS' not defined
test/basic/generated/Makefile.am:21: HAVE_ORBIT_IDL_BACKENDDIR does not
appear in AM_CONDITIONAL
test/string/Makefile.am:6: variable `ORBIT_LIBS' not defined
test/string/Makefile.am:6: variable `ORBIT_LIBS' not defined
test/string/generated/Makefile.am:21: HAVE_ORBIT_IDL_BACKENDDIR does not
appear in AM_CONDITIONAL
test/boolean/Makefile.am:6: variable `ORBIT_LIBS' not defined
test/boolean/Makefile.am:6: variable `ORBIT_LIBS' not defined
test/boolean/generated/Makefile.am:21: HAVE_ORBIT_IDL_BACKENDDIR does
not appear in AM_CONDITIONALtest/everything/Makefile.am:6: variable
`ORBIT_LIBS' not defined
test/everything/Makefile.am:6: variable `ORBIT_LIBS' not defined
test/everything/generated/Makefile.am:21: HAVE_ORBIT_IDL_BACKENDDIR does
not appear in AM_CONDITIONAL
test/everything-typedef/Makefile.am:6: variable `ORBIT_LIBS' not defined
test/everything-typedef/Makefile.am:6: variable `ORBIT_LIBS' not defined
test/everything-typedef/generated/Makefile.am:21:
HAVE_ORBIT_IDL_BACKENDDIR does not appear in AM_CONDITIONAL
test/name/generated/Makefile.am:21: HAVE_ORBIT_IDL_BACKENDDIR does not
appear in AM_CONDITIONAL
Running ./configure --enable-maintainer-mode
loading cache ./config.cache
./configure: syntax error near unexpected token
`AM_INIT_AUTOMAKE($PACKAGE,'
./configure: ./configure: line 552: `AM_INIT_AUTOMAKE($PACKAGE,
$VERSION, no-define)'










Phil Dawes wrote:
> 
> Hi Adam,
> 
> Sorry I took so long to reply - I've been away from the fray for a few
> days,
> 
> The standard dev approach we use is to grab autoconf, automake and
> libtool, then do:
> 
> ./autogen.sh
> make
> make check
> 
> Then start hacking!
> 
> Could you mail your config.log file to the mailing list? That file
> contains more information.
> 
> I'm not sure what's wrong - I use redhat 6.1 and the configure script
> works out of the box. It could be a gcc 2.96 thing (I'm using gcc
> 2.95.2). I'll try and grab a copy of gcc 2.96 today if I remember.
> 
> Cheers,
> 
> Phil.
>

Re: [orbitcpp-list] Yep, I'm the FNG

[Phil D. <ph...@us...>]

Hi Adam,

Sorry I took so long to reply - I've been away from the fray for a few
days,

The standard dev approach we use is to grab autoconf, automake and
libtool, then do:

./autogen.sh
make
make check

Then start hacking!


Could you mail your config.log file to the mailing list? That file
contains more information.

I'm not sure what's wrong - I use redhat 6.1 and the configure script
works out of the box. It could be a gcc 2.96 thing (I'm using gcc
2.95.2). I'll try and grab a copy of gcc 2.96 today if I remember.

Cheers,

Phil.


Adam Young wrote:
> 
> Yeah, I kept digging but figured I'd keep my spam's down to two per
> day.   conftest is created, compiled, run and removed by configure.  I
> commented out the code that removes it, and after running configure I
> still didn't see it.
> 
> So I got the CVS source and tried autoconf orbitcpp-config.in  crapped
> out in the middle
> 
> Then I tried running ./autogen.sh and it told me I needed libtool.  SO
> now I am in the process of getting libtool and trying that.
> 
> How do y'all work this?  What is the standard Development tactic?
> 
> Adam
> 
> > I believe that conftest is generated during the configure process. the
> > configure script outputs, compiles, and runs little programs to figure
> > out how your system works.
> >
> > It looks like for some reason configure thinks you are running a
> > cross-compiler, which should not be the case.  I don't exactly know
> > how it tells that.
> 
> _______________________________________________
> orbitcpp-list mailing list
> orb...@li...
> http://lists.sourceforge.net/mailman/listinfo/orbitcpp-list

Re: [orbitcpp-list] Yep, I'm the FNG

[Adam Y. <ay...@fo...>]

Yeah, I kept digging but figured I'd keep my spam's down to two per
day.   conftest is created, compiled, run and removed by configure.  I
commented out the code that removes it, and after running configure I
still didn't see it.  

So I got the CVS source and tried autoconf orbitcpp-config.in  crapped
out in the middle

Then I tried running ./autogen.sh and it told me I needed libtool.  SO
now I am in the process of getting libtool and trying that.

How do y'all work this?  What is the standard Development tactic?


Adam


> I believe that conftest is generated during the configure process. the
> configure script outputs, compiles, and runs little programs to figure
> out how your system works.
> 
> It looks like for some reason configure thinks you are running a
> cross-compiler, which should not be the case.  I don't exactly know
> how it tells that.

Re: [orbitcpp-list] Yep, I'm the FNG

[Ronald G. <rga...@ir...>]

>>>>> "ay" == Adam Young <ay...@fo...> writes:

    ay> Found this in the ./configure
...

    ay> can't find conftest on my system.  Is this missing from the
    ay> .tar.gz?
I believe that conftest is generated during the configure process. the
configure script outputs, compiles, and runs little programs to figure
out how your system works.  

It looks like for some reason configure thinks you are running a
cross-compiler, which should not be the case.  I don't exactly know
how it tells that.

ron

    ay> Adam

    ay> _______________________________________________ orbitcpp-list
    ay> mailing list orb...@li...
    ay> http://lists.sourceforge.net/mailman/listinfo/orbitcpp-list

Re: [orbitcpp-list] Yep, I'm the FNG

[Adam Y. <ay...@fo...>]

Found this in the ./configure

if { (eval echo configure:1815: \"$ac_link\") 1>&5; (eval $ac_link)
2>&5; } && test -s conftest${ac_exeext}; then
  ac_cv_prog_cxx_works=yes
  # If we can't run a trivial program, we are probably using a cross
compiler.
  if (./conftest; exit) 2>/dev/null; then
    ac_cv_prog_cxx_cross=no
  else
    ac_cv_prog_cxx_cross=yes
  fi
else
  echo "configure: failed program was:" >&5
  cat conftest.$ac_ext >&5
  ac_cv_prog_cxx_works=no
fi


can't find conftest on my system.  Is this missing from the .tar.gz?

Should I just not bother and go right to the CVS tree?

Adam

Re: [orbitcpp-list] Yep, I'm the FNG

[Adam Y. <ay...@fo...>]

In ./configure


cross_compiling=$ac_cv_prog_cxx_cross

  if test "$cross_compiling" = yes; then
    { echo "configure: error: can not run test program while cross
compiling" 1>&2; exit 1; }


Here's the complete log


checking for a BSD compatible install... (cached) /usr/bin/install -c
checking whether build environment is sane... yes
checking whether make sets ${MAKE}... (cached) yes
checking for working aclocal... found
checking for working autoconf... found
checking for working automake... found
checking for working autoheader... found
checking for working makeinfo... found
checking whether to enable maintainer-specific portions of Makefiles...
no
checking host system type... i686-pc-linux-gnu
checking build system type... i686-pc-linux-gnu
checking for ranlib... (cached) ranlib
checking for gcc... (cached) gcc
checking whether the C compiler (gcc -g ) works... yes
checking whether the C compiler (gcc -g ) is a cross-compiler... no
checking whether we are using GNU C... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for ld used by GCC... (cached) /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... (cached) yes
checking for BSD-compatible nm... (cached) /usr/bin/nm -B
checking whether ln -s works... (cached) yes
checking for object suffix... o
checking for executable suffix... no
checking for gcc option to produce PIC... -fPIC
checking if gcc PIC flag -fPIC works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.lo... yes
checking if gcc supports -fno-rtti -fno-exceptions ... yes
checking if gcc static flag -static works... -static
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking whether the linker (/usr/bin/ld) supports shared libraries...
yes
checking command to parse /usr/bin/nm -B output... ok
checking how to hardcode library paths into programs... immediate
checking for /usr/bin/ld option to reload object files... -r
checking dynamic linker characteristics... Linux ld.so
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking for objdir... .libs
creating libtool
loading cache ./config.cache
checking for gcc... (cached) gcc
checking whether the C compiler (gcc -g ) works... yes
checking whether the C compiler (gcc -g ) is a cross-compiler... no
checking whether we are using GNU C... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for c++... c++
checking whether the C++ compiler (c++ -g -Wall ) works... yes
checking whether the C++ compiler (c++ -g -Wall ) is a cross-compiler...
yes
checking whether we are using GNU C++... yes
checking whether c++ accepts -g... yes
checking for a BSD compatible install... /usr/bin/install -c
checking for orbit-config... /usr/bin/orbit-config
checking for ORBit - version >= 0.5.1... cross compiling; assumed OK...
yes
checking for orbit-idl... /usr/bin/orbit-idl
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking whether c++ compiler (c++) supports bad_cast... no
checking for size of c++ new memory info block... configure: error: can
not run test program while cross compiling






Ronald Garcia wrote:
> 
> >>>>> "ay" == Adam Young <ay...@fo...> writes:
> 
>     ay> So I figure its time to get involved in an Open source project
>     ay> and I am a definie C++phile, figured I'd try to get involved
>     ay> with ORBit-C++.  However, fdoing the download, tar
>     ay> -zxf,./configure didn't work for me.  Seems like there is an
>     ay> issue with cross compiling with gcc that causes the
>     ay> ./configure to fail.  Using Gcc v 2.96.  Didn't see anything
>     ay> in the email archives, although they just go back to late
>     ay> 1999.  Any help would be most appreciated.
> 
> could you give some more detail on what's going wronng?  perhaps a
> transcript of your compilation process?
> 
> ron
> 
> _______________________________________________
> orbitcpp-list mailing list
> orb...@li...
> http://lists.sourceforge.net/mailman/listinfo/orbitcpp-list

Re: [orbitcpp-list] Yep, I'm the FNG

[Ronald G. <rga...@ir...>]

>>>>> "ay" == Adam Young <ay...@fo...> writes:

    ay> So I figure its time to get involved in an Open source project
    ay> and I am a definie C++phile, figured I'd try to get involved
    ay> with ORBit-C++.  However, fdoing the download, tar
    ay> -zxf,./configure didn't work for me.  Seems like there is an
    ay> issue with cross compiling with gcc that causes the
    ay> ./configure to fail.  Using Gcc v 2.96.  Didn't see anything
    ay> in the email archives, although they just go back to late
    ay> 1999.  Any help would be most appreciated.

could you give some more detail on what's going wronng?  perhaps a
transcript of your compilation process? 

ron

[orbitcpp-list] Yep, I'm the FNG

[Adam Y. <ay...@fo...>]

So I figure its time to get involved in an Open source project and I am
a definie C++phile, figured I'd try to get involved with ORBit-C++. 
However, fdoing the download, tar -zxf,./configure didn't work for me. 
Seems like there is an issue with cross compiling with gcc that causes
the ./configure to fail.  Using Gcc v 2.96.  Didn't see anything in the
email archives, although they just go back to late 1999.  Any help would
be most appreciated.

Adam

Re: [orbitcpp-list] Question ??

[Andreas K. <ak...@ix...>]

XXXXXX wrote:
> 
>  Hello !!
> 
>   I am installed orbitcpp-0.28.1 version at my solaris system and operable.
> 
>    but I have question.
> 
>     1)  I found that interoperability between omniORB C++ server and ORBit C++ Client program .
>          I want to know that interopability between ORBit C++ server/client and ORBit C client/server program.
>          If it is not support, How can I do ?
>           If it is support, Everybody, Please send me example programs(C and C++ Program).
>        * It is very important for process my project.
> 
>     2)  How can use Naming service ?
> 
>    Please send me developer e-main address.
> 
>   ETRI, KOREA
> 
>    Jang Jong Hyun.

Hi,

1) marshalling and demarshalling (the conversion of method invocation
data to and from the on-the-wire representation, GIOP in this case) is
not done at the ORBit-C++, but rather at ORBit-C level, so you should
better turn to the ORBit-C folks for this kind of issue. Their list is
orb...@cu..., but you had better browse their archives before
starting to ask questions.

2) * you start the ORBit (or any) COSNaming daemon (orbit-name-server)
* you make sure your local ORBit gets the daemon's service IOR
* you should be all set.

bye
andreas

ps: though i don't know where you grabbed my personal e-mail address,
i'd consider it good style to mail the list first and _only_ when
requesting help.

Re: [orbitcpp-list] Question ??

[Phil D. <ph...@us...>]

Hi Jang Jong Hyun,

Interoperability does work between C and C++, even if both are in the
same program (address space).
You can get an example of using the nameserver from
ftp://orbitcpp.sourceforge.net/pub/orbitcpp

(I think it still works - mail me if it doesn't!)

Hope this helps,

Phil.

ÀåÁ¾Çö wrote:
> 
>  Hello !!
> 
>   I am installed orbitcpp-0.28.1 version at my solaris system and operable.
> 
>    but I have question.
> 
>     1)  I found that interoperability between omniORB C++ server and ORBit C++ Client program .
>          I want to know that interopability between ORBit C++ server/client and ORBit C client/server program.
>          If it is not support, How can I do ?
>           If it is support, Everybody, Please send me example programs(C and C++ Program).
>        * It is very important for process my project.
> 
>     2)  How can use Naming service ?
> 
>    Please send me developer e-main address.
> 
>   ETRI, KOREA
> 
>    Jang Jong Hyun.
> 
> 
> 
> _______________________________________________
> orbitcpp-list mailing list
> orb...@li...
> http://lists.sourceforge.net/mailman/listinfo/orbitcpp-list

[orbitcpp-list] Question ??

[<jj...@ni...>]

 Hello !!
 
  I am installed orbitcpp-0.28.1 version at my solaris system and operable.
   
   but I have question.
   
    1)  I found that interoperability between omniORB C++ server and ORBit C++ Client program .
         I want to know that interopability between ORBit C++ server/client and ORBit C client/server program.
         If it is not support, How can I do ?
          If it is support, Everybody, Please send me example programs(C and C++ Program).
       * It is very important for process my project.

    2)  How can use Naming service ?

   Please send me developer e-main address.

  ETRI, KOREA
  
   Jang Jong Hyun.
         
         

[orbitcpp-list] Rpm build

[<mon...@di...>]

Hi,
    I noticed that the orbit-C++ from the gnome cvs has a spec file. and
that the
orbitcpp-0.28.1.tar.gz from sourceforge doesn't. Is anyone working on
the specfile,
or if not, would anyone mind if I monster the gnome one for 0.28.1 and
send it in?

--
Nowadays you can even use Gimp on that thing from Redmond they call an OS.

[orbitcpp-list] Can't compile :(

[<mon...@di...>]

Hi,
    I have ORBit-C++ and ORBit from the gnome cvs rep.

I get this when attempting to compile ORBit-C++

c++ -DHAVE_CONFIG_H -I. -I. -I../../.. -I../../..
-I/usr/lib/glib/include -I -I/usr/lib/glib/include -I/usr/include     -g
-O0  -c sequence-cpp-stubs.cc
In file included from sequence-cpp-stubs.cc:2:
sequence.hh:31: template-id `operator new<>' for
`::ORBIT_CPP::::ORBIT_CPP::SequenceTmpl<::CORBA::String_mgr,::ORBIT_C::CORBA_sequence_CORBA_string,::test::CORBA_sequence_CORBA_string_cppseqstruct>::operator
new<>(size_t)' does not match any template declaration
sequence.hh:31: confused by earlier errors, bailing out
make[4]: *** [sequence-cpp-stubs.o] Error 1
make[4]: Leaving directory
`/store/cvsGnome/ORBit-C++/test/sequence/generated'

any ideas. :-/



--
Nowadays you can even use Gimp on that thing from Redmond they call an OS.

Re: [orbitcpp-list] stub wrapper model

[Phil D. <ph...@us...>]

Ronald Garcia wrote:
> 
> howdy folks,
> 
>      I've been poking and prodding at ocpp here and there, and i was
> wondering if in a nutshell someone could explain the current stubs
> model...at least:
> 
> - why are there two classes (_orbitcpp::stubs::xxx and ::xxx) for an
> object?
> 

The ::xxx class provides the static methods for a corba object of that
type. (_duplicate(), _narrow(), _nil()) and must be there because they
are specified. 

The actual object stub is a completely unconnected class
(_orbitcpp::stubs::xxx). I don't why it's done like this (Andreas?), but
it is perfectly legal as long as the user can reference the stubs using
the _ptr and _var types declared in the xxx namespace.

Logically it's a nice seperation. The 'stubs' are a different thing from
the 'corba object'. Having the stubs in a different namespace physically
represents this.


> - does anything go in xxx-cpp-common.cc?
> 

Exception packing functions. (Exceptions are the only type which isn't
marshalled via a reinterpret_cast, and so must be built out of a C
exception type by copying the members.

> - is there an updated list of features that are already implemented
> and features that still need work?
> 

I think language mapping types wise, everything in CORBA 2.2 is
implemented apart from arrays, unions, fixed and any.

Also, we lack wrapping for the majority of the POA functionality. This
should be a simple task, but neither me or Andreas have got round to it.

We don't have any of the dynamic stuff yet: dii, dsi, dynany etc..

The only supported service is naming so far...

Cheers,

Phil.

[orbitcpp-list] stub wrapper model

[Ronald G. <rga...@pi...>]

howdy folks,

     I've been poking and prodding at ocpp here and there, and i was
wondering if in a nutshell someone could explain the current stubs
model...at least:

- why are there two classes (_orbitcpp::stubs::xxx and ::xxx) for an
object?

- does anything go in xxx-cpp-common.cc?

- is there an updated list of features that are already implemented
and features that still need work?

thanks

ron