Re: NGPT + C++ = ?

> Can you give a complete code example?  That would be quite useful.

hmmm... can't reproduce it.. we've re-installed NGPT in the default
location (so without the --prefix=<wherever> option to configure). Now
everyting compiles smoothly.

As I said: we had to change the makefile of ngpt to get it to install in
a non-default location. We were having to much trouble to get everyting
linking and running when the ngpt-pthread lib was installed in a
non-default location. 

Apparently, on our system, (SuSE 7.3 Professional), /lib/libpthread.so.0
was not a symlink but a real shared library. This was causing system
binaries to get confused since /usr/lib/libpthread.so.0 was a symlink to
the ngpt-lib. Hence, you'd see that if you ldd'ed one of our binaries
there were to entries for libpthread.so, which is not what you want...
:)

Since installing NGPT for the first time, we've gained some experience
and I think that if we were to re-install NGPT in a non-default
location, we would be more successfull now. 

The fact remains that the installation procedure did not recognize the
fact that /lib/libpthread.so.0 was not a symlink and back that one up as
well and change it to either a symlink to the newly installed ngpt-lib
or replace it with the lib itself.


Would it be worthwhile if we re-installed ngpt in a non-default location
and try to reproduce the error?


Cheers,

Harro


> 
> -Corey
> 
> Harro Verkouter wrote:
> 
> >Hi,
> >
> >We wanted to switch to using NGPT for our MT apps (since the
> >non-Posixicity of LinuxThreads is killing us...) so of we went
> >installing 2.0.1 (first upgrading our system to 2.4.19, and patching
> >it)... so far so good...
> >
> >We did not install ngpt in the default location but in /usr/local.
> >We had to change to makefile since it could not cope with that.
> >
> >We moved on, trying to compile one of the modules of our project, which
> >does not use threads. We told the compiler (g++ 2.95.3) not to look in
> >the standard include paths, but rather in the paths we specified. Made
> >sure that /usr/local/include was before /usr/include.
> >
> >So far so good. However, the compiler barfs on the netinet/in.h file
> >(through inclusion of bits/in.h) over the following construction:
> >
> ><<< snippet from /usr/include/bits/in.h >>>
> >
> >/* Structure used to describe IP options for IP_OPTIONS. The `ip_dst'
> >   field is used for the first-hop gateway when using a source route
> >   (this gets put into the header proper).  */
> >struct ip_opts
> >  {
> >    struct in_addr ip_dst;     /* First hop; zero without source route.  */
> >    char ip_opts[40];          /* Actually variable in size.  */
> >
> >    ^^^^^^^^^^^^^^^^^
> >       this is where the compiler barfs on...
> >  };
> >
> ><<< /snippet >>>
> >
> >The output from g++:
> >
> >[master]:Okay->gmake
> >g++ -fPIC -nostdinc -g -Wall -fexceptions -ftemplate-depth-25
> >-D_REENTRANT -DBUILDTIME="\"Tuesday 13 August 2002/09:22:09\""
> >-D_POSIX_PTHREAD_SEMANTICS
> >-I/usr/lib/gcc-lib/i486-suse-linux/2.95.3/include -I/usr/local/include
> >-I/usr/include -I/usr/include/g++ -I/jop200_0/verkout/pci/src/libs/ -c
> >-o /jop200_0/verkout/pci/src/libs/myutil/Repos/i686/hostname.o
> >hostname.cc ;
> >In file included from /usr/include/netinet/in.h:250,
> >                 from
> >/jop200_0/verkout/pci/src/libs/myutil/hostname.h:28,
> >                 from hostname.cc:21:
> >/usr/include/bits/in.h:69: ANSI C++ forbids data member `ip_opts' with
> >same name as enclosing class
> >gmake: *** [/jop200_0/verkout/pci/src/libs/myutil/Repos/i686/hostname.o]
> >Error 1
> >[master]:Okay->
> >
> >
> >
> >When I cut and paste the struct definition (as in the snippet) into a .c
> >file and compile using gcc -> no problemo. If a write it to a .cc file
> >and compile with g++, I get exactly the same error about ANSI C++
> >forbidding etc.
> >
> >This would indicate that somehow, the compiler does not recognize the
> >ip_opts as a C-style struct...
> >
> >I've tried with an extern "C" {} declaration around it (in the test
> >file) but that made no difference (was to be expected, of course, but
> >you could always give it a try).
> >
> >
> >
> >Does anyone have an idea what's causing this and/or how to fix it?
> >
> >
> >The system is a dual PIII 1.13GHz running patched (fmutex-<..>-2.0.1
> >patch) 2.4.19 SMP kernel.
> >
> >
> >
> >
> >
> >Thanx in advance,
> >
> >
> >
> >

-- 

Groeten,


Harro Verkouter                 Joint Institute for VLBI in Europe
[email protected]		Radiosterrenwacht Dwingeloo 
			        Postbus 2
tel.: (+31)(0)521-596516	7990 AA DWINGELOO, the Netherlands
fax.: (+31)(0)521-597332 	

------------------------------------------------------------------

They laughed at Einstein.  They laughed at the Wright Brothers.
But they also laughed at Bozo the Clown.

                                                    -- Carl Sagan

------------------------------------------------------------------