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

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...>]

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

[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...>]

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,

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...>]

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.
>

[orbitcpp-list] Postmortem

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

Don't try it with GCC 2.96

Adam

Re: [orbitcpp-list] Postmortem

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

On Fri, Jul 21, 2000 at 06:24:05PM -0700, Adam Young wrote:
> Don't try it with GCC 2.96
> 
> Adam
> 
> _______________________________________________
> orbitcpp-list mailing list
> orb...@li...
> http://lists.sourceforge.net/mailman/listinfo/orbitcpp-list
> 

I've checked the gcc homepage yesterday, they didn't say anything about
2.96 being out, nor did their ftp site carry it. :?

andy

PS: btw, what do you mean by "postmortem"? is that "bye folks, i'm going
for another project"?

-- 
Don't innovate, intimidate.

Re: [orbitcpp-list] Postmortem

[<bir...@co...>]

On 23 Jul 00, at 11:52, Andreas Kloeckner wrote:

> On Fri, Jul 21, 2000 at 06:24:05PM -0700, Adam Young wrote:
> > Don't try it with GCC 2.96
> > 
> > Adam
> > 
> > _______________________________________________
> > orbitcpp-list mailing list
> > orb...@li...
> > http://lists.sourceforge.net/mailman/listinfo/orbitcpp-list
> > 
> 
> I've checked the gcc homepage yesterday, they didn't say anything about
> 2.96 being out, nor did their ftp site carry it. :?
> 
> andy
> 
> PS: btw, what do you mean by "postmortem"? is that "bye folks, i'm going
> for another project"?
> 
> -- 
> Don't innovate, intimidate.
> 

The weekly release carry the 2.96 in its version documentation. Try the newest 
beta, do a gcc -v and you'll see it ;)



-------------------------------------------
Horst 'hellicop' Birthelmer
bir...@co...  
hel...@us...

http://www.birthelmer.de
http://www.hellicop.net
-------------------------------------------

Re: [orbitcpp-list] Postmortem

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

No no, I'm still; around.  Just the postmortem on the issue I filled
everyone's inbox with.. 2.96 was required for Mico development.  I didn
;t realize I still had a non supported gcc.  I've reformed my ways...for
now.

Adam





Andreas Kloeckner wrote:
> 
> On Fri, Jul 21, 2000 at 06:24:05PM -0700, Adam Young wrote:
> > Don't try it with GCC 2.96
> >
> > Adam
> >
> > _______________________________________________
> > orbitcpp-list mailing list
> > orb...@li...
> > http://lists.sourceforge.net/mailman/listinfo/orbitcpp-list
> >
> 
> I've checked the gcc homepage yesterday, they didn't say anything about
> 2.96 being out, nor did their ftp site carry it. :?
> 
> andy
> 
> PS: btw, what do you mean by "postmortem"? is that "bye folks, i'm going
> for another project"?
> 
> --
> Don't innovate, intimidate.
> 
> _______________________________________________
> 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...>]

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

[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