plib-users

Re: [Plib-users] Example config problem

[C. H. <cho...@at...>]

Sebastian,

 >...
> Hmm ... fix your Cygwin :)

Did that.  When updating cygwin I noticed that autoconf exists in both 
stable and devel versions. I went ahead and let it install both. Now I'm 
not so sure that was a good idea. It doesn't strike me that you are 
using the development version of autoconf. Anyhow, should I edit the 
file tree to move stable autoconf stuff where it apparently is expected?

Also. At this point I retried your original command sequence and 
autoconf still coughs a hairball about the missing .cfg file. Ditto make.

> and in the meantime, get this patch that I just
> created which adds the missing files:
> 
> http://www.ude.handshake.de/plib_examples-1.6.1-autoconf.patch.gz

Not succeeding with getting results from updating cygwin I put the patch 
file in the directory "/home/plib_examples-1.6.1", which is where the 
examples were unpacked. Was that the wrong location? Would you like 
another? BTW, you didn't say where to save the patch file.

> 
> To apply, cd into a vanilla plib_examples-1.6.1 directory and type:
> 
> gzip -cd /path/to/plib_examples-1.6.1-autoconf.patch.gz | patch -p1
> 

Didn't work. In /home/plib_examples-1.6.1 I entered

gzip -cd /home/plib_examples-1.6.1-autoconf.patch.gz | patch -p1

patch complained that it cannot find the file to patch. It then prompts 
for the file. This repeats for several make files that I know 
./configure did create (they show up on directory checks.) Is this patch 
looking for the original example tar ball?

I hope this continues to be at least a mildly interesting challenge for 
you as I hate exercising people on simple problems. It is an education 
for me in the assumptions that plib developers made in setting up the 
examples.

Regards,

Charlie H.

-- 
"C makes it easy to shoot yourself in the foot;
C++ makes it harder, but when you do, it blows
away your whole leg." - Bjarne Stroustrup

Re: [Plib-users] Example config problem

[C. H. <cho...@at...>]

Thanks, Norman. I have done an update before and know what you mean 
about checking keep vs update or add. Hope that helps. If it doesn't 
I'll send up another flare.

Regards,

Charlie H.

Norman Vine wrote:
> C. Hotchkiss writes:
> 
> 
>>Sebastian Ude wrote:
>>
>>>On Fri, 15 Nov 2002, ... Hotchkiss wrote:
>>>
>>>
>>>>...
>>>>
>>>>I tried building the examples from the 1.6.1 tar ball and...  ...
> 
> Charlie
> 
> I don't know where this error message is coming from
> 
> I would try updating my < autoconf , automake > Cygwin files 
> using the Cygwin setup program  
> < these are in the devel category >
> ...
-- 
"C makes it easy to shoot yourself in the foot;
C++ makes it harder, but when you do, it blows
away your whole leg." - Bjarne Stroustrup

Re: [Plib-users] Example config problem

[C. H. <cho...@at...>]

Thanks, Sebastian.

I'll update Cygwin first and then apply the patch. Grabbed the file 
immediately though, just to make sure I have it and not waste your 
storage time.

Regards,

Charlie H.
...
> 
> Yes, there is definately something wrong with your autoconf setup.
> 
> 
...
"C makes it easy to shoot yourself in the foot;
C++ makes it harder, but when you do, it blows
away your whole leg." - Bjarne Stroustrup

Re: [Plib-users] Example config problem

[Sebastian U. <ud...@ha...>]

On Sat, 16 Nov 2002, cho...@at... (C. Hotchkiss) wrote:
> Date: Sat, 16 Nov 2002 19:03:09 -0800
> To: pli...@li...
> From: cho...@at... (C. Hotchkiss)
> Reply-To: pli...@li...
> Subject: Re: [Plib-users] Example config problem

[...]

> > Known problem. For now, cd into the plib_examples-1.6.1 and type:
> >
> > aclocal
> > automake --add-missing
> > autoconf
> >
> > The missing files should be created during this process.
>
> Uh, yes and no. The first two commands run to completion without
> complaint. I now have the original missing files, but running "autoconf"
> gives this error message.
>
> autom4te: cannot open /usr/local/share/autoconf/autom4te.cfg: No such
> file or directory at /usr/local/bin/autom4te line 428
>
> I checked and the directory exists, but this is no cfg file at all. This
> leads me to believe that I didn't do something that probably should have
> been done in June when I installed Cygwin.

Yes, there is definately something wrong with your autoconf setup.


> Just to see what the first two command achieved I tried ./configure,
> which now seems to run to completion, but make complains that it cannot
> find the same .cfg file that autoconf cannot find.
>
> Even though the fix didn't completely work this is a considerable 
> improvement. Next magical incantation?

Hmm ... fix your Cygwin :) and in the meantime, get this patch that I just
created which adds the missing files:

http://www.ude.handshake.de/plib_examples-1.6.1-autoconf.patch.gz

To apply, cd into a vanilla plib_examples-1.6.1 directory and type:

gzip -cd /path/to/plib_examples-1.6.1-autoconf.patch.gz | patch -p1


Then, try to run ./configure again which should work flawlessly.


- Sebastian

Re: [Plib-users] Example config problem

[Norman V. <nh...@ca...>]

C. Hotchkiss writes:

> Sebastian Ude wrote:
> > 
> > On Fri, 15 Nov 2002, ... Hotchkiss wrote:
> > 
> >>...
> >>
> >>I tried building the examples from the 1.6.1 tar ball and...  it fails for lack of three files,
> >>install-sh, config.sub and config.guess. ...
> > 
> > Known problem. For now, cd into the plib_examples-1.6.1 and type:
> > 
> > aclocal
> > automake --add-missing
> > autoconf
> > 
> > The missing files should be created during this process.
> > 
> 
> Uh, yes and no. The first two commands run to completion without 
> complaint. I now have the original missing files, but running "autoconf" 
> gives this error message:
> 
> autom4te: cannot open /usr/local/share/autoconf/autom4te.cfg: No such 
> file or directory
> at /usr/local/bin/autom4te line 428
> 
> I checked and the directory exists, but this is no cfg file at all. This 
> leads me to believe that I didn't do something that probably should have 
> been done in June when I installed Cygwin.

Charlie

I don't know where this error message is coming from

I would try updating my < autoconf , automake > Cygwin files 
using the Cygwin setup program  
< these are in the devel category >

Cygwin will tell you that there are LOTs of things it will update
but you can click on the <View> button after you have made
your initial selections and 'view' what will be updated.  You
can now select what you want todo on an individual package
by clicking on the second column.  I would set all but those
you want to update to 'keep'

Cygwin has had many improvements since June and you might 
just want to update everything that it suggests though :-)

HTH

Norman


make sure you 

Re: [Plib-users] Example config problem

[C. H. <cho...@at...>]

Sebastian Ude wrote:
> 
> On Fri, 15 Nov 2002, ... Hotchkiss wrote:
> 
>>...
>>
>>I tried building the examples from the 1.6.1 tar ball and...  it fails for lack of three files,
>>install-sh, config.sub and config.guess. ...
> 
> Known problem. For now, cd into the plib_examples-1.6.1 and type:
> 
> aclocal
> automake --add-missing
> autoconf
> 
> The missing files should be created during this process.
> 

Uh, yes and no. The first two commands run to completion without 
complaint. I now have the original missing files, but running "autoconf" 
gives this error message:

autom4te: cannot open /usr/local/share/autoconf/autom4te.cfg: No such 
file or directory
at /usr/local/bin/autom4te line 428

I checked and the directory exists, but this is no cfg file at all. This 
leads me to believe that I didn't do something that probably should have 
been done in June when I installed Cygwin.

Just to see what the first two command achieved I tried ./configure, 
which now seems to run to completion, but make complains that it cannot 
find the same .cfg file that autoconf cannot find.

Even though the fix didn't completely work this is a considerable 
improvement. Next magical incantation?

Regards,

Charlie H.
-- 
"C makes it easy to shoot yourself in the foot;
C++ makes it harder, but when you do, it blows
away your whole leg." - Bjarne Stroustrup

Re: [Plib-users] Runway Lights and Undocumented Secrets of Plib

[David M. <da...@me...>]

Steve Baker writes:

 > Bear in mind though that your callback is only called when the 
 > object's parent is inside the field of view.  This is both an
 > advantage and a curse.  It means that expensive callbacks are
 > only called when they are needed - but also that callbacks with
 > side-effects are a bit unpredictable!

Right -- every once in a while I have to do the equivalent of a
traversal with a 360-deg FOV to make sure that everything's culled.
It's been a while, so I don't remember exactly how I implemented that,
but I do recall that Norm Vine helped me to fine-tune it


All the best,


David

-- 
David Megginson, da...@me..., http://www.megginson.com/

Re: [Plib-users] Runway Lights and Undocumented Secrets of Plib

[Steve B. <sjb...@ai...>]

David Megginson wrote:

> Plib has callbacks for branches as well as leaves, but the branch
> callbacks are not documented, so I had to dig trough the plib source
> code (they're the same ones I used for the dynamic scenery objects).
> For a branch, you can set pre-traversal and post-traversal callbacks;
> if the pre-traversal callback return false, then the branch will be
> skipped.  Here's a trivial (and not-so-efficient) example:
> 
>   static int cloaking_callback (ssgEntity * e, int mask)
>   {
>     return !fgGetBool("/controls/cloaking-device");
>   }
> 
>   ssgBranch * ship;
> 
>   // ...
> 
>   ship->setTravCallback(SSG_CALLBACK_PRETRAV, cloaking_callback);
> 
> Now, the 'ship' branch will automatically vanish whenever the
> /controls/cloaking-device property is true and reappear when it's
> false.

Yes - I apologise that this isn't documented - but it's vitally
important that you can do this -so it *should* be documented.

Bear in mind though that your callback is only called when the 
object's parent is inside the field of view.  This is both an
advantage and a curse.  It means that expensive callbacks are
only called when they are needed - but also that callbacks with
side-effects are a bit unpredictable!

> For the dynamic objects, I use a much more complicated approach -- the
> branches are actually empty until ssg attempts to traverse them, then
> (at first traversal) FlightGear populates them with pseudo-randomly
> placed objects.

Wow!

> That way, branches that never come into range or into
> the view direction are never populated.  I also have a callback to
> depopulate the branches once they fall out of range.  That turns out
> to be a fairly efficient way to add many objects (such as buildings or
> trees) to the scenery nearby without overwhelming the system.

Interesting.

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net

Re: [Plib-users] Example config problem

[Sebastian U. <ud...@ha...>]

On Fri, 15 Nov 2002, cho...@at... (C. Hotchkiss) wrote:
> Date: Fri, 15 Nov 2002 22:58:24 -0800
> To: pli...@li...
> From: cho...@at... (C. Hotchkiss)
> Reply-To: pli...@li...
> Subject: [Plib-users] Example config problem
>
> I tried building the examples from the 1.6.1 tar ball and, as noted in a
> previous post in the archives, it fails for lack of three files,
> install-sh, config.sub and config.guess. These files are not available 
> to me and are not in the 1.6.0 archive.
>
> Looking and the directory for the last version of the examples that I 
> built, 1.4.1, I found an install-sh file and tried using a copy of that. 
> It worked, but the other two files mentioned were never generated or are 
> long since gone. How do I generate them or should someone e-mail them to 
> me? I'm using cygwin in the standard default configuration set up. (Plib 
> 1.6.0 built nicely with no complaints.)

Known problem. For now, cd into the plib_examples-1.6.1 and type:

aclocal
automake --add-missing
autoconf

The missing files should be created during this process.


- Sebastian

[Plib-users] Runway Lights and Undocumented Secrets of Plib

[David M. <da...@me...>]

I've made a couple of trivial changes to FlightGear so that runway
lights turn off during the day in VMC.

Plib has callbacks for branches as well as leaves, but the branch
callbacks are not documented, so I had to dig trough the plib source
code (they're the same ones I used for the dynamic scenery objects).
For a branch, you can set pre-traversal and post-traversal callbacks;
if the pre-traversal callback return false, then the branch will be
skipped.  Here's a trivial (and not-so-efficient) example:

  static int cloaking_callback (ssgEntity * e, int mask)
  {
    return !fgGetBool("/controls/cloaking-device");
  }

  ssgBranch * ship;

  // ...

  ship->setTravCallback(SSG_CALLBACK_PRETRAV, cloaking_callback);

Now, the 'ship' branch will automatically vanish whenever the
/controls/cloaking-device property is true and reappear when it's
false.

For the dynamic objects, I use a much more complicated approach -- the
branches are actually empty until ssg attempts to traverse them, then
(at first traversal) FlightGear populates them with pseudo-randomly
placed objects.  That way, branches that never come into range or into
the view direction are never populated.  I also have a callback to
depopulate the branches once they fall out of range.  That turns out
to be a fairly efficient way to add many objects (such as buildings or
trees) to the scenery nearby without overwhelming the system.


All the best,


David

-- 
David Megginson, da...@me..., http://www.megginson.com/

[Plib-users] Weird problem

[Marco B. <F1...@so...>]

Hi!

I'm using PLIB successfully for my space combat game.
I have my GUI/HUD system that I wrote some time ago and it was easy
to make live them together because my GUI is written in OpenGL too.

I use two functions to start/end the 2D rendering, like this:

ssgCullAndDraw(pWorld);

Begin2D();
// ... all my GUI/HUD stuff
End2D();

All works fine. In Begin2D() I simply glEnable/glDisable some OpenGL
states and setup the Ortho projection.

Here's the problem:
yesterday I tried to use ssgaLensFlare and it works, but when the lens
flares are visible my 2D system draws the texture in the wrong way.
It's like the ssgaLensFlare changes some OpenGL state that I don't 
enable/disable in the Begin2D()... I looked plib sources but you set
only GL_BLEND and AlphaFunc in ssgaLensFlare and re-set them so it's
not the problem.

What could it be?

I post here my Begin2D() and End2D() code:

void Begin2D(int iWidth, int iHeight)
{
	glDisable      ( GL_LIGHTING ) ;
	glEnable      ( GL_TEXTURE_2D ) ;
	glDisable      ( GL_DEPTH_TEST ) ;
	glDisable      ( GL_CULL_FACE  ) ;
	glEnable       ( GL_ALPHA_TEST ) ;
	glEnable       ( GL_BLEND ) ;
	glAlphaFunc    ( GL_GREATER, 0.1f ) ;
	glBlendFunc    ( GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA ) ;
	//create an projection that acts like a 2D screen
	glMatrixMode   ( GL_PROJECTION ) ;
	glPushMatrix   () ;
	glLoadIdentity () ;
	glOrtho(0, iWidth, iHeight, 0, -1, 1);
	glMatrixMode   ( GL_MODELVIEW ) ;
	glPushMatrix   () ;
	glLoadIdentity () ;
}

void End2D()
{
	glMatrixMode   ( GL_PROJECTION ) ;
	glPopMatrix    () ;
	glMatrixMode   ( GL_MODELVIEW ) ;
	glPopMatrix    () ;

	glEnable(GL_LIGHTING);
	glEnable(GL_DEPTH_TEST);
	glEnable(GL_CULL_FACE);
	glDisable      ( GL_ALPHA_TEST ) ;
	glDisable      ( GL_BLEND ) ;
	glAlphaFunc    ( GL_ALWAYS, 0.0 ) ;
	glBlendFunc    ( GL_ONE, GL_ZERO ) ;
}

Sorry for my bad english... but hope to have been clear enough.

Thank you!

	Bye Bye
	F104/NA

[Plib-users] Example config problem

[C. H. <cho...@at...>]

I tried building the examples from the 1.6.1 tar ball and, as noted in a
previous post in the archives, it fails for lack of three files,
install-sh, config.sub and config.guess. These files are not available 
to me and are not in the 1.6.0 archive.

Looking and the directory for the last version of the examples that I 
built, 1.4.1, I found an install-sh file and tried using a copy of that. 
It worked, but the other two files mentioned were never generated or are 
long since gone. How do I generate them or should someone e-mail them to 
me? I'm using cygwin in the standard default configuration set up. (Plib 
1.6.0 built nicely with no complaints.)

Regards,

Charlie H.

-- 
"You're not drunk if you can lie on the floor without holding on."
                      ---Dean Martin

[Plib-users] sl lib core dumps

[chad <cal...@at...>]

Hi,

I'm having problems with the sl library.  It is producing core dumps and =
other=20
than knowing that the sl library is causing the issue, I don't know what =
the=20
problem is.

With some quick testing it seems to be the result of having too many soun=
ds=20
playing in the library at one time.  The core dumps always occur when at=20
least 3 are playing and I request another.

This problem happens on two different machines so it isn't a machine issu=
e.

Any ideas?  (I know, not enough to go on)

Thanks,
=09Chad Calkins

Re: [Plib-users] multiple definitions

[Steve B. <sjb...@ai...>]

Mat Davidson wrote:
> Ok, so I've got a mild answer to this problem. The only way Ive found  
> to get it working is to:
> 
> 1.)  take the plib headers and move them from /usr/include/plib to the  
> directory that is local the project
> 2.)  move #include<plib/xx.h> to #include "xx.h"
> 
> its strange and I still don't have a decent explanation for it.  Got  
> any ideas?

Eh?  That's crazy.  So the allowed syntax depends on where the file is?

Is it perhaps possible that there is an old version of PLIB stored somewhere
else and that it *was* picking up the older version - but when you move
the files to the local directory, it's able to find the newer (local) copies?


---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net

[Plib-users] Fwd: Bug in fntTexFont::getBBox?

[Mark H. S. <sh...@pt...>]

I forgot to mention that is in plib-1.6.0. - Mark

>X-Sender: sh...@ga...
>X-Mailer: QUALCOMM Windows Eudora Version 5.1.1
>Date: Sat, 09 Nov 2002 12:44:58 -0800
>To: pli...@li...
>From: "Mark H. Shirley" <sh...@pt...>
>Subject: Bug in fntTexFont::getBBox?
>Cc: msh...@ar...
>
>I'm trying to use the code that computes bounding boxes for
>strings in the fnt library.  The documentation page says it works
>for strings with embedded newlines, and the code that computes
>the bounding box does appear to handle that.  At least, it does so
>correctly in the Y direction.  In the X direction, it computes the
>width of the longest line but doesn't return that.  It returns the width
>of the last line.  (I'm referring to fntTexFont::getBBox in fnt.cxx.)
>
>I believe this is a bug, but I don't know what code elsewhere in
>the plib libraries might depend upon it.  Correcting the assignments at 
>the end
>of fntTexFont::getBBox like this:
>
>   if ( left  != NULL ) *left  = l * pointsize ;
>   if ( right != NULL ) *right = max_r * pointsize ;  /* return max_r */
>   if ( top   != NULL ) *top   = t * pointsize ;
>   if ( bot   != NULL ) *bot   = max_b * pointsize ;  /* return max_b */
>
>... fixes things in my application.
>  - Mark Shirley

[Plib-users] Bug in fntTexFont::getBBox?

[Mark H. S. <sh...@pt...>]

I'm trying to use the code that computes bounding boxes for
strings in the fnt library.  The documentation page says it works
for strings with embedded newlines, and the code that computes
the bounding box does appear to handle that.  At least, it does so
correctly in the Y direction.  In the X direction, it computes the
width of the longest line but doesn't return that.  It returns the width
of the last line.  (I'm referring to fntTexFont::getBBox in fnt.cxx.)

I believe this is a bug, but I don't know what code elsewhere in
the plib libraries might depend upon it.  Correcting the assignments at the end
of fntTexFont::getBBox like this:

   if ( left  != NULL ) *left  = l * pointsize ;
   if ( right != NULL ) *right = max_r * pointsize ;  /* return max_r */
   if ( top   != NULL ) *top   = t * pointsize ;
   if ( bot   != NULL ) *bot   = max_b * pointsize ;  /* return max_b */

... fixes things in my application.
  - Mark Shirley

[Plib-users] OS X Solution

[Mat D. <mdd...@en...>]

So I've made some headway on the OSX problem.

In order to get everything working correctly, I made a Carbon  
Framework, called plib, with all headers in it and compiled it with the  
libs in /usr/lib.  Then, I installed the framework in  
/System/Library/Frameworks/ and included it into my project.  I also  
removed all the headers from /usr/include/plib so that there wouldn't  
be any confusion.  For some reason, OSX was treating those headers as C  
headers and wasn't using C++.  You might post this solution to the site  
or something, it was a major hassle to get working.

m.

On Saturday, November 9, 2002, at 11:17 AM, Mat Davidson wrote:

> Ok, so I've got a mild answer to this problem. The only way Ive found  
> to get it working is to:
>
> 1.)  take the plib headers and move them from /usr/include/plib to the  
> directory that is local the project
> 2.)  move #include<plib/xx.h> to #include "xx.h"
>
> its strange and I still don't have a decent explanation for it.  Got  
> any ideas?
>
> mat.
>
>
> On Saturday, November 9, 2002, at 09:49 AM, Steve Baker wrote:
>
>> Mat Davidson wrote:
>>> the exact g++ errors are:
>>> Mkdir  
>>> /Volumes/Storage/mat/Desktop/ttt3d-0.2.0/ttt3d/build/ttt3d.build/ 
>>> ttt3d.build/Objects-normal/ppc CompileCplusplus  
>>> /Volumes/Storage/mat/Desktop/ttt3d-0.2.0/ttt3d/build/ttt3d.build/ 
>>> ttt3d.build/Objects-normal/ppc/cell.o In file included from  
>>> /usr/include/plib/ssg.h:28,
>>> from /Volumes/Storage/mat/Desktop/ttt3d-0.2.0/src/p3d.h:36,
>>> from /Volumes/Storage/mat/Desktop/ttt3d-0.2.0/src/cell.cxx:25:
>>
>> ttt3d sounds like the program in plib/demos - is that correct?
>> (it contains a file called 'cell.cxx' and another called 'p3d.h'
>> so I think it must be).
>>
>> Have you changed the code at all from what's in the PLIB demos distro?
>>
>> The standard version doesn't include any 'extern "C"' stuff - so any  
>> problem
>> like that would have to be a bug in the official OS-X headers...which  
>> seems
>> unlikely.
>>
>>> These are the kinds of errors Im getting.
>>> It might be interesting to note that it says "declaration of C  
>>> function".....but I still don't know how to fix it
>>
>> Neither do I.
>>
>> There should be an option in GCC to make it emit the results of
>> the pre-processing stage.  This is after the '#include' and '#define'
>> processing has been done.
>>
>> I would look through that and see if there are any unmatched 'extern  
>> "C"'
>> commands.
>>
>> I'd also try to compile a VERY simple source file containing something
>> that's allowed in C++ and not in C and check that it compiles - just  
>> as
>> a way to be sure that you really are using the compiler with the C++
>> part enabled and not somehow telling it to be a 'pure' C compiler.
>>
>> eg:
>>
>> int main ()
>> {
>>    int x = 0 ;
>>
>>    x = 123 ;
>>
>>    int y = 0 ;         <--- Legal in C++ - should generate an error  
>> in C
>>
>>    y = 456 ;
>> }
>>
>>
>> ...if that produces an error then the problem is that you have some  
>> funny
>> problem with the compiler not recognising this as a C++ program and  
>> compiling
>> it as C instead.
>> ---------------------------- Steve Baker -------------------------
>> HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
>> HomePage : http://web2.airmail.net/sjbaker1
>> Projects : http://plib.sf.net    http://tuxaqfh.sf.net
>>            http://tuxkart.sf.net http://prettypoly.sf.net
>>
>>
>>
>> -------------------------------------------------------
>> This sf.net email is sponsored by:ThinkGeek
>> Welcome to geek heaven.
>> http://thinkgeek.com/sf
>> _______________________________________________
>> plib-users mailing list
>> pli...@li...
>> https://lists.sourceforge.net/lists/listinfo/plib-users
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> plib-users mailing list
> pli...@li...
> https://lists.sourceforge.net/lists/listinfo/plib-users

Re: [Plib-users] multiple definitions

[Mat D. <mdd...@en...>]

Ok, so I've got a mild answer to this problem. The only way Ive found  
to get it working is to:

1.)  take the plib headers and move them from /usr/include/plib to the  
directory that is local the project
2.)  move #include<plib/xx.h> to #include "xx.h"

its strange and I still don't have a decent explanation for it.  Got  
any ideas?

mat.


On Saturday, November 9, 2002, at 09:49 AM, Steve Baker wrote:

> Mat Davidson wrote:
>> the exact g++ errors are:
>> Mkdir  
>> /Volumes/Storage/mat/Desktop/ttt3d-0.2.0/ttt3d/build/ttt3d.build/ 
>> ttt3d.build/Objects-normal/ppc CompileCplusplus  
>> /Volumes/Storage/mat/Desktop/ttt3d-0.2.0/ttt3d/build/ttt3d.build/ 
>> ttt3d.build/Objects-normal/ppc/cell.o In file included from  
>> /usr/include/plib/ssg.h:28,
>> from /Volumes/Storage/mat/Desktop/ttt3d-0.2.0/src/p3d.h:36,
>> from /Volumes/Storage/mat/Desktop/ttt3d-0.2.0/src/cell.cxx:25:
>
> ttt3d sounds like the program in plib/demos - is that correct?
> (it contains a file called 'cell.cxx' and another called 'p3d.h'
> so I think it must be).
>
> Have you changed the code at all from what's in the PLIB demos distro?
>
> The standard version doesn't include any 'extern "C"' stuff - so any  
> problem
> like that would have to be a bug in the official OS-X headers...which  
> seems
> unlikely.
>
>> These are the kinds of errors Im getting.
>> It might be interesting to note that it says "declaration of C  
>> function".....but I still don't know how to fix it
>
> Neither do I.
>
> There should be an option in GCC to make it emit the results of
> the pre-processing stage.  This is after the '#include' and '#define'
> processing has been done.
>
> I would look through that and see if there are any unmatched 'extern  
> "C"'
> commands.
>
> I'd also try to compile a VERY simple source file containing something
> that's allowed in C++ and not in C and check that it compiles - just as
> a way to be sure that you really are using the compiler with the C++
> part enabled and not somehow telling it to be a 'pure' C compiler.
>
> eg:
>
> int main ()
> {
>    int x = 0 ;
>
>    x = 123 ;
>
>    int y = 0 ;         <--- Legal in C++ - should generate an error in  
> C
>
>    y = 456 ;
> }
>
>
> ...if that produces an error then the problem is that you have some  
> funny
> problem with the compiler not recognising this as a C++ program and  
> compiling
> it as C instead.
> ---------------------------- Steve Baker -------------------------
> HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
> HomePage : http://web2.airmail.net/sjbaker1
> Projects : http://plib.sf.net    http://tuxaqfh.sf.net
>            http://tuxkart.sf.net http://prettypoly.sf.net
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> plib-users mailing list
> pli...@li...
> https://lists.sourceforge.net/lists/listinfo/plib-users

Re: [Plib-users] multiple definitions

[Steve B. <sjb...@ai...>]

Mat Davidson wrote:
> the exact g++ errors are:
> 
> 
> Mkdir 
> /Volumes/Storage/mat/Desktop/ttt3d-0.2.0/ttt3d/build/ttt3d.build/ttt3d.build/Objects-normal/ppc 
> 
> CompileCplusplus 
> /Volumes/Storage/mat/Desktop/ttt3d-0.2.0/ttt3d/build/ttt3d.build/ttt3d.build/Objects-normal/ppc/cell.o 
> 
> In file included from /usr/include/plib/ssg.h:28,
> from /Volumes/Storage/mat/Desktop/ttt3d-0.2.0/src/p3d.h:36,
> from /Volumes/Storage/mat/Desktop/ttt3d-0.2.0/src/cell.cxx:25:

ttt3d sounds like the program in plib/demos - is that correct?
(it contains a file called 'cell.cxx' and another called 'p3d.h'
so I think it must be).

Have you changed the code at all from what's in the PLIB demos distro?

The standard version doesn't include any 'extern "C"' stuff - so any problem
like that would have to be a bug in the official OS-X headers...which seems
unlikely.

> These are the kinds of errors Im getting.
> It might be interesting to note that it says "declaration of C 
> function".....but I still don't know how to fix it

Neither do I.

There should be an option in GCC to make it emit the results of
the pre-processing stage.  This is after the '#include' and '#define'
processing has been done.

I would look through that and see if there are any unmatched 'extern "C"'
commands.

I'd also try to compile a VERY simple source file containing something
that's allowed in C++ and not in C and check that it compiles - just as
a way to be sure that you really are using the compiler with the C++
part enabled and not somehow telling it to be a 'pure' C compiler.

eg:

int main ()
{
    int x = 0 ;

    x = 123 ;

    int y = 0 ;         <--- Legal in C++ - should generate an error in C

    y = 456 ;
}


...if that produces an error then the problem is that you have some funny
problem with the compiler not recognising this as a C++ program and compiling
it as C instead.
---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net

Re: [Plib-users] multiple definitions

[Steve B. <sjb...@ai...>]

Mat Davidson wrote:
> Im running Mac OSX Jaguar, GCC 3.1
> 
> I can compile the libs from source and install them without a problem. 
> When I try to use the libs though I get a ton of errors associated with 
> the use of "inline" translation functions and overloads used in header 
> files such as ul.h and sg.h. For example, the following code throws errors:
> 
> ul.h: line 275
> static inline void _ulEndianSwap(unsigned int *x) {
> *x = (( *x >> 24 ) & 0x000000FF ) |
> (( *x >> 8 ) & 0x0000FF00 ) |
> (( *x << 8 ) & 0x00FF0000 ) |
> (( *x << 24 ) & 0xFF000000 ) ;
> }
> 
> 
> static inline void _ulEndianSwap(unsigned short *x) {
> *x = (( *x >> 8 ) & 0x00FF ) |
> (( *x << 8 ) & 0xFF00 ) ;
> }
> 
> and also
> 
> 
> sg.h: line 835
> extern void sgReflectInPlaneVec3 ( sgVec3 dst, const sgVec3 src, const 
> sgVec4 plane ) ;
> inline void sgReflectInPlaneVec3 ( sgVec3 dst, const sgVec4 plane )
> {
> sgReflectInPlaneVec3 ( dst, dst, plane ) ;
> }
> 
> 
> 
> Im compiling the projects with g++. Has anyone ever run into this? 
> Theres no way I can use plib like this, hopefully theres a way to fix 
> this. Please let me know if you have any ideas.

This is weird, we've compiled PLIB with many C++ compilers and never seen
this kind of thing before.

I know GCC 3.1 is a lot tighter on the C++ standard than previous
revisions - but I can't see what we are doing wrong here.  I think
this is your own fault somehow.

It's almost as if you were using a C compiler instead of C++.

Since this doesn't show up as a problem when you compile the LIBRARIES,
but only when you compile the APPLICATION, that's not impossible.  After
all, PLIB includes those exact same functions - it would not have compiled
if there was an error in those function definitions.

   1) Are you sure you are compiling these headers into C++ programs?
      PLIB doesn't support C.

   2) Are you sure you didn't accidentally wrap the header with:

         extern "C"
         {
         #include <plib/ul.h>
         }

   3) Is it possible that you have an 'extern "C"{...}' wrapping some
      other header file...or inside some other header that might have
      a missing '}' ??

That's the only thing I can imagine this could be.

My suspicions were raised by the nature of the error message you
sent me earlier:

/usr/include/plib/ul.h:273: declaration of C function `void _ulEndianSwap(short unsigned int*)' conflicts with

Why "declaration of C function" ??  Why not just "declaration of function" ?

That leads me to think that for some reason the compiler thinks these are C functions
and not C++ - and of course function overloading is illegal in C.   Since C++ functions
with 'extern "C"' in front of them have to abide by C-style linkage conventions, they
*CANNOT* be overloaded - even if they happen to be written in C++.

That's my best shot - dunno if anyone else has any ideas.


---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net

Re: [Plib-users] multiple definitions

[Mat D. <mdd...@en...>]

the exact g++ errors are:


Mkdir  
/Volumes/Storage/mat/Desktop/ttt3d-0.2.0/ttt3d/build/ttt3d.build/ 
ttt3d.build/Objects-normal/ppc
CompileCplusplus  
/Volumes/Storage/mat/Desktop/ttt3d-0.2.0/ttt3d/build/ttt3d.build/ 
ttt3d.build/Objects-normal/ppc/cell.o
In file included from /usr/include/plib/ssg.h:28,
                  from  
/Volumes/Storage/mat/Desktop/ttt3d-0.2.0/src/p3d.h:36,
                  from  
/Volumes/Storage/mat/Desktop/ttt3d-0.2.0/src/cell.cxx:25:
/usr/include/plib/sg.h: In function `void sgMakeCoordMat4(float (*)[4],  
const float*, const float*)':
/usr/include/plib/sg.h:145: declaration of C function `void  
sgMakeCoordMat4(float (*)[4], const float*, const float*)' conflicts  
with
/usr/include/plib/sg.h:142: previous declaration `void  
sgMakeCoordMat4(float (*)[4], float, float, float, float, float,  
float)' here

These are the kinds of errors Im getting.
It might be interesting to note that it says "declaration of C  
function".....but I still don't know how to fix it

mat.


On Friday, November 8, 2002, at 08:26 PM, Mat Davidson wrote:

> Im running Mac OSX Jaguar, GCC 3.1
>
> I can compile the libs from source and install them without a problem.  
>  When I try to use the libs though I get a ton of errors associated  
> with the use of "inline" translation functions and overloads used in  
> header files such as ul.h and sg.h.  For example, the following code  
> throws errors:
>
> ul.h: line 275
> static inline void _ulEndianSwap(unsigned int *x) {
>   *x = (( *x >> 24 ) & 0x000000FF ) |
>     (( *x >>  8 ) & 0x0000FF00 ) |
>     (( *x <<  8 ) & 0x00FF0000 ) |
>     (( *x << 24 ) & 0xFF000000 ) ;
> }
>
> static inline void _ulEndianSwap(unsigned short *x) {
>   *x = (( *x >>  8 ) & 0x00FF ) |
>     (( *x <<  8 ) & 0xFF00 ) ;
> }
>
> and also
>
>
> sg.h: line 835
> extern void sgReflectInPlaneVec3 ( sgVec3 dst, const sgVec3 src, const  
> sgVec4 plane ) ;
> inline void sgReflectInPlaneVec3 ( sgVec3 dst, const sgVec4 plane )
> {
>   sgReflectInPlaneVec3 ( dst, dst, plane ) ;
> }
>
>
>
> Im compiling the projects with g++.  Has anyone ever run into this?   
> Theres no way I can use plib like this, hopefully theres a way to fix  
> this.  Please let me know if you have any ideas.
>
>
> mat.

[Plib-users] Re: ./configure opengl problem - solved

[The M. <ndm...@oz...>]

Thanks for all your help ... plib compiled ok !

Adding AC_CHECK_LIB(pthread, pthread_create) line to ./configure.in
worked !

(Also I had Mesa 3.3).

Nick

[Plib-users] multiple definitions

[Mat D. <mdd...@en...>]

Im running Mac OSX Jaguar, GCC 3.1

I can compile the libs from source and install them without a problem.  
When I try to use the libs though I get a ton of errors associated with 
the use of "inline" translation functions and overloads used in header 
files such as ul.h and sg.h.  For example, the following code throws 
errors:

ul.h: line 275
static inline void _ulEndianSwap(unsigned int *x) {
   *x = (( *x >> 24 ) & 0x000000FF ) |
     (( *x >>  8 ) & 0x0000FF00 ) |
     (( *x <<  8 ) & 0x00FF0000 ) |
     (( *x << 24 ) & 0xFF000000 ) ;
}

static inline void _ulEndianSwap(unsigned short *x) {
   *x = (( *x >>  8 ) & 0x00FF ) |
     (( *x <<  8 ) & 0xFF00 ) ;
}

and also


sg.h: line 835
extern void sgReflectInPlaneVec3 ( sgVec3 dst, const sgVec3 src, const 
sgVec4 plane ) ;
inline void sgReflectInPlaneVec3 ( sgVec3 dst, const sgVec4 plane )
{
   sgReflectInPlaneVec3 ( dst, dst, plane ) ;
}



Im compiling the projects with g++.  Has anyone ever run into this?  
Theres no way I can use plib like this, hopefully theres a way to fix 
this.  Please let me know if you have any ideas.


mat.

Re: [Plib-users] Re: ./configure opengl problem

[Steve B. <sjb...@ai...>]

McEvoy, Nick wrote:


>>Anyhow - for now, search for the following line in configure.in:
>>AC_CHECK_LIB(GL, glNewList)
>>.. and add this line prior to it:
>>AC_CHECK_LIB(pthread, pthread_create)


> Does this mean its now fixed in plib cvs ? :)

It is *NOW*.

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net

[Plib-users] Re: ./configure opengl problem

[McEvoy, N. <nic...@ds...>]

Sebastian Ude wrote:
>Known bug - the configure script does not link against the pthread library,
>which is necessary for certain Mesa versions.
>Didn't I intend to change that prior to the 1.6.0 release ? Hmm ... seems
>like I did not.
>Anyhow - for now, search for the following line in configure.in:
>AC_CHECK_LIB(GL, glNewList)
>.. and add this line prior to it:
>AC_CHECK_LIB(pthread, pthread_create)
>Then, while in the root of the plib source tree, run
>/autogen.sh
>and
>/configure
>(which should work flawlessly now).

Thanks for the info ... I'll try it this weekend.

Does this mean its now fixed in plib cvs ? :)

Nick