plib-devel

Re: [Plib-devel] Windows, multiple joystick support

[Jonah W. \(R. Student\) <ja...@ri...>]

Would a member of the devel list be kind enough to grant me access to =
commit changes to subversion or commit the following patch for me?

In jsWindows.cxx I suggest replacing the current constructor with the =
following code to allow support for more than 2 joystick devices. =
Windows 95 and higher support at least 16 devices and there does not =
seem to be any reason why plib should artificially limit itself to only =
2.

jsJoystick::jsJoystick ( int ident )
{
  id =3D ident ;
  os =3D new struct os_specific_s;

  if (ident >=3D 0 && ident < joyGetNumDevs()) {
	os->js_id =3D JOYSTICKID1 + ident;
	open();
  }
  else {
	num_axes =3D 0;
	setError();
  }
}

joyGetNumDevs() is documented here: =
http://msdn2.microsoft.com/en-us/library/ms709351.aspx

Thanks,
-Jonah (sourceforge account "jw_rit")

Re: [Plib-devel] patch for compiling on Solaris 10

[Vikas N K. <vik...@us...>]

Hi John,
Thanks for doing that. It fixes the socklen_t problem as well.

Regards,
Vikas

On 12/15/06, Fay John F Dr CTR USAF AFSEO/SK <joh...@eg...> wrote:
>
>
>
> Vikas,
>
>         OK, I have put it into SVN.  Please check that I have done it
> correctly.
>
> John F. Fay
> Technical Fellow
> Jacobs/Sverdrup TEAS Group
> 850-883-1294
>
> -----Original Message-----
> From: pli...@li...
> [mailto:pli...@li...] On Behalf
> Of Vikas N Kumar
>
> Sent: Friday, December 15, 2006 1:55 PM
> To: PLIB Developers
> Subject: Re: [Plib-devel] patch for compiling on Solaris 10
>
>
> Hi John,
> Below is the patch for setting the "-Wall" flag to null if the
> compiler is not GCC. It works, for both Linux and Solaris.
>
> Regards,
> Vikas
>
>
> Index: configure.in
> ===================================================================
> --- configure.in        (revision 2112)
> +++ configure.in        (working copy)
> @@ -346,6 +346,10 @@
>      if test "x$CXX" = "xicpc" || test "x$CXX" = "xicc"; then
>          WFLAG="-w1"
>      fi
> +    if test "x$GCC" != xyes; then
> +       # if the compiler is not GCC we reset WFLAG to null for safety
> +       WFLAG=""
> +    fi
>         ;;
>  esac
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> https://lists.sourceforge.net/lists/listinfo/plib-devel
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> https://lists.sourceforge.net/lists/listinfo/plib-devel
>
>
>


-- 
http://www.vikaskumar.org/

Re: [Plib-devel] patch for compiling on Solaris 10

[Fay J. F Dr C. U. AFSEO/SK <joh...@eg...>]

Vikas,

	OK, I have put it into SVN.  Please check that I have done it
correctly.

John F. Fay
Technical Fellow
Jacobs/Sverdrup TEAS Group
850-883-1294 

-----Original Message-----
From: pli...@li...
[mailto:pli...@li...] On Behalf Of Vikas N Kumar
Sent: Friday, December 15, 2006 1:55 PM
To: PLIB Developers
Subject: Re: [Plib-devel] patch for compiling on Solaris 10

Hi John,
Below is the patch for setting the "-Wall" flag to null if the
compiler is not GCC. It works, for both Linux and Solaris.

Regards,
Vikas


Index: configure.in
===================================================================
--- configure.in        (revision 2112)
+++ configure.in        (working copy)
@@ -346,6 +346,10 @@
     if test "x$CXX" = "xicpc" || test "x$CXX" = "xicc"; then
         WFLAG="-w1"
     fi
+    if test "x$GCC" != xyes; then
+       # if the compiler is not GCC we reset WFLAG to null for safety
+       WFLAG=""
+    fi
        ;;
 esac

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel

Re: [Plib-devel] patch for compiling on Solaris 10

[Vikas N K. <vik...@us...>]

Hi John,
Below is the patch for setting the "-Wall" flag to null if the
compiler is not GCC. It works, for both Linux and Solaris.

Regards,
Vikas


Index: configure.in
===================================================================
--- configure.in        (revision 2112)
+++ configure.in        (working copy)
@@ -346,6 +346,10 @@
     if test "x$CXX" = "xicpc" || test "x$CXX" = "xicc"; then
         WFLAG="-w1"
     fi
+    if test "x$GCC" != xyes; then
+       # if the compiler is not GCC we reset WFLAG to null for safety
+       WFLAG=""
+    fi
        ;;
 esac

Re: [Plib-devel] patch for compiling on Solaris 10

[Fay J. F Dr C. U. AFSEO/SK <joh...@eg...>]

Vikas,

	I have a Windows box and it does not have "sys/socket.h" at all.  I
do not have Cygwin and so have not been able to check that.

	Of note, Windows does not define "socklen_t" at all.

	I think out best bet would be to make the "-Wall" flag
system-dependent.  It is necessary on some systems and creates an error on
other systems, so the most logical step would (in my mind) be to make it
system-dependent.  Do please look into how we do this.

John F. Fay
Technical Fellow
Jacobs/Sverdrup TEAS Group
850-883-1294 

-----Original Message-----
From: pli...@li...
[mailto:pli...@li...] On Behalf Of Vikas N Kumar
Sent: Friday, December 15, 2006 9:46 AM
To: PLIB Developers
Subject: Re: [Plib-devel] patch for compiling on Solaris 10

Hi John,
my comments below.

On 12/14/06, Fay John F Dr CTR USAF AFSEO/SK <joh...@eg...>
wrote:
>         It appears from the message below that the "configure" test for
> "socklen_t" fails on Sun Studio 11 compilers because they do not support
> "-Wall".  I see three options:
>
> (1)  Drop the "-Wall" flag.  I do not like this option because I like the
> compiler to warn me when things are iffy.

Actually John, the "-Wall" flag is required for the GNU compilers to
show all the warnings. The Sun Studio 11 compilers show all the
warnings by default, and the "-Wall" flag is not accepted. Hence, you
might just need to keep the "-Wall" flag for GNU compilers.

>
> (2)  Quit checking for "socklen_t" in the "configure" step.  Vijay Kumar,
> who flagged the error, supports this option.  The reasoning is that
> "socklen_t" is pretty much universal by now.

I am not sure about Windows & *BSDs in this regard. socklen_t is
present in Linux and Solaris for sure. If someone has a *BSD or
Windows and can check for the presence of socklen_t in " netinet/in.h"
and  "sys/socket.h" then we can remove it from the configure.in
script. Is plib supported on IRIX too ?
I have an IRIX 6.2 system at home but I am not sure what version of
IRIX you currently support. I can check there for socklen_t.

>
> (3)  Make the "-Wall" flag system-dependent and don't use it Sun Studio 11
> compilers.  Is such a thing possible?

yes this should be possible. If you want I can look into doing this.


Regards,
Vikas

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel

Re: [Plib-devel] patch for compiling on Solaris 10

[Bert D. <dri...@pl...>]

On Thu, 14 Dec 2006, Fay John F Dr CTR USAF AFSEO/SK wrote:

> 	It appears from the message below that the "configure" test for
> "socklen_t" fails on Sun Studio 11 compilers because they do not support
> "-Wall".  I see three options:
>
> (1)  Drop the "-Wall" flag.  I do not like this option because I like the
> compiler to warn me when things are iffy.
>
> (2)  Quit checking for "socklen_t" in the "configure" step.  Vijay Kumar,
> who flagged the error, supports this option.  The reasoning is that
> "socklen_t" is pretty much universal by now.
>
> (3)  Make the "-Wall" flag system-dependent and don't use it Sun Studio 11
> compilers.  Is such a thing possible?

My two cents: dropping the check for socklen_t is not the desirable 
solution. It was obviously put there for a reason, and PLIB is used on 
platforms some of us haven't even heard of. So unless someone recalls 
what platforms were unbroken by adding that check, I would not call 
dropping it a safe change.

Obviously, when a compiler barfs on -Wall, we should not add -Wall to 
the compiler options. There is autoconf magic to check for GCC and set 
-Wall as required (I seem to recall that the AC_PROG_CPP does the 
appropriate magic).

Re: [Plib-devel] patch for compiling on Solaris 10

[Vikas N K. <vik...@us...>]

Hi John,
my comments below.

On 12/14/06, Fay John F Dr CTR USAF AFSEO/SK <joh...@eg...> wrote:
>         It appears from the message below that the "configure" test for
> "socklen_t" fails on Sun Studio 11 compilers because they do not support
> "-Wall".  I see three options:
>
> (1)  Drop the "-Wall" flag.  I do not like this option because I like the
> compiler to warn me when things are iffy.

Actually John, the "-Wall" flag is required for the GNU compilers to
show all the warnings. The Sun Studio 11 compilers show all the
warnings by default, and the "-Wall" flag is not accepted. Hence, you
might just need to keep the "-Wall" flag for GNU compilers.

>
> (2)  Quit checking for "socklen_t" in the "configure" step.  Vijay Kumar,
> who flagged the error, supports this option.  The reasoning is that
> "socklen_t" is pretty much universal by now.

I am not sure about Windows & *BSDs in this regard. socklen_t is
present in Linux and Solaris for sure. If someone has a *BSD or
Windows and can check for the presence of socklen_t in " netinet/in.h"
and  "sys/socket.h" then we can remove it from the configure.in
script. Is plib supported on IRIX too ?
I have an IRIX 6.2 system at home but I am not sure what version of
IRIX you currently support. I can check there for socklen_t.

>
> (3)  Make the "-Wall" flag system-dependent and don't use it Sun Studio 11
> compilers.  Is such a thing possible?

yes this should be possible. If you want I can look into doing this.


Regards,
Vikas

Re: [Plib-devel] patch for compiling on Solaris 10

[Fay J. F Dr C. U. AFSEO/SK <joh...@eg...>]

Vikas,

	I've not looked at the "socklen_t" problem yet.  I fixed the
"strstr" typecast problem by adding a conditional compilation--it seems that
the Borland compiler does the same thing, so I set the "UL_BB" flag--but
changed its name to "UL_EXPLICIT_CASTS".

John F. Fay
Technical Fellow
Jacobs/Sverdrup TEAS Group
850-883-1294 

-----Original Message-----
From: pli...@li...
[mailto:pli...@li...] On Behalf Of Vikas N Kumar
Sent: Monday, December 11, 2006 1:17 PM
To: pli...@li...
Subject: Re: [Plib-devel] patch for compiling on Solaris 10

Hi John,
The configure script added the -Dsocklen_t=int in my compile line.
Why it did that I have no idea, I did not look. I will look at it and
let you know.

The sun studio 11 C++ compiler was giving an error in saying strstr
was returning a const char*. I guess that is how it is on Solaris 10.
I shall look into that too. You could however use the UL_BB #ifdefs
and do it instead of the explicit cast.

Even for the socklen_t=int problem, one could test for UL_SOLARIS and
then do the #undef statements as given in the patch as opposed to
undefining it without any Operating system checks.


Regards,
Vikas

> From: Fay John F Dr CTR USAF AFSEO/SK <joh...@eg...>
> Subject: Re: [Plib-devel] patch for compiling on Solaris 10
> Vikas,
>
>         I'm a little confused about the "socklen_t" problem you mention.
I
> looked around the Linux system header files a bit and find
>
> #ifndef __socklen_t_defined
> typedef __socklen_t socklen_t
> #endif
>
> The only place I see "socklen_t" used in PLIB is in "netSocket.cxx", where
> it is defined to be "int" under MSVC if it has not already been defined.
As
> such, perhaps the problem lies with the "configure" adding that flag to
your
> compile line.  Does anybody know what causes it?
>
>         I am similarly confused by the addition of "(char *)" to the
> "strstr" call in netChat.cxx.  The "strstr" function already returns a
value
> of type "char *" so the cast should be unnecessary.  Is there something
> about the Sun Studio 11 compiler that is nonstandard?  If there is, I will
> certainly be willing to add the explicit cast, but if not I would just as
> soon leave it out.  (Perhaps we should use a "#ifdef UL_BB" block here.)
>
> John F. Fay
> Technical Fellow
> Jacobs/Sverdrup TEAS Group
> 850-883-1294

-- 
http://www.vikaskumar.org/

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel

Re: [Plib-devel] patch for compiling on Solaris 10

[Fay J. F Dr C. U. AFSEO/SK <joh...@eg...>]

Gentlemen,

	It appears from the message below that the "configure" test for
"socklen_t" fails on Sun Studio 11 compilers because they do not support
"-Wall".  I see three options:

(1)  Drop the "-Wall" flag.  I do not like this option because I like the
compiler to warn me when things are iffy.

(2)  Quit checking for "socklen_t" in the "configure" step.  Vijay Kumar,
who flagged the error, supports this option.  The reasoning is that
"socklen_t" is pretty much universal by now.

(3)  Make the "-Wall" flag system-dependent and don't use it Sun Studio 11
compilers.  Is such a thing possible?

John F. Fay
Technical Fellow
Jacobs/Sverdrup TEAS Group
850-883-1294 

-----Original Message-----
From: pli...@li...
[mailto:pli...@li...] On Behalf Of Vikas N Kumar
Sent: Monday, December 11, 2006 10:36 PM
To: pli...@li...
Subject: Re: [Plib-devel] patch for compiling on Solaris 10

Hi John,
The socklen_t problem is occurring since you have the following in
your configure.in
Here are the details in config.log for the Sun Studio 11 compiler
running on Solaris 10.
socklen_t is defined in /usr/include/sys/socket.h but yet, the test
below (at the end of the email) fails.

Why? Because of the "-Wall" option. Sun Studio 11 compilers on Solaris
10 do not support the -Wall option. Hence the exit code $? is 1
because of which socklen_t gets defined as int instead of size_t or
uint32_t.
You could try "+w2" for a certain level of warnings.

In any case, we should not check for socklen_t since it is defined on
most systems. This checking is very antiquated on Unixes. If you look
at configure.in the check has been added for Unix98. Even if it is
defined in the header files, if socklen_t gets into the compile line
as -Dsocklen_t=int or -Dsocklen_t=size_t, we will still have to
undefine it before it is typedef'd in <netinet/in.h>

Regarding strstr(), on Solaris10 in the header files the strstr()
function returns a const char* for __cplusplus>=199711L which
apparently is some C++ standard (ISO/IEC 14882:1998) (lifted this off
the header file, i.e. in /usr/include/iso/string_iso.h) The header
file /usr/include/string.h uses this iso/string_iso.h header file for
all its string functions.


Regards,
Vikas

configure:7169: checking for socklen_t
configure:7191: /opt/SUNWspro/bin/cc -c -g -Wall
-I/export/home/vicash/FLIGHTGEAR/run/include conftest.c >&5
cc: illegal option -Wall
configure:7197: $? = 1
configure: failed program was:
| /* confdefs.h.  */
|
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE "plib"
| #define VERSION "1.8.4"
| #ifdef __cplusplus
| extern "C" void exit (int);
| #endif
| #define HAVE_LIBPTHREAD 1
| #define HAVE_LIBGL 1
| #define HAVE_LIBDL 1
| #define STDC_HEADERS 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| /* end confdefs.h.  */
|
| #include <sys/types.h>
| #include <sys/socket.h>
| socklen_t apa;
|
| int
| main ()
| {
|
|   ;
|   return 0;
| }
configure:7240: /opt/SUNWspro/bin/cc -c -g -Wall
-I/export/home/vicash/FLIGHTGEAR/run/include conftest.c >&5
cc: illegal option -Wall
configure:7246: $? = 1
configure: failed program was:
| /* confdefs.h.  */
|
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE "plib"
| #define VERSION "1.8.4"
| #ifdef __cplusplus
| extern "C" void exit (int);
| #endif
| #define HAVE_LIBPTHREAD 1
| #define HAVE_LIBGL 1
| #define HAVE_LIBDL 1
| #define STDC_HEADERS 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| /* end confdefs.h.  */
|
| #include <sys/types.h>
| #include <sys/socket.h>
| int accept (int, struct sockaddr *, size_t *);
|
| int
| main ()
| {
|
|   ;
|   return 0;
| }
configure:7273: result: int

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel

[Plib-devel] R: R: R: Texture loading problems (bmp/rgb)

[Paolo L. <p.l...@ci...>]

It does work perfectly, thanks a lot.
=20
Greetings -
=20
Paolo

=20
-----Messaggio originale-----
Da: pli...@li...
[mailto:pli...@li...] Per conto di Fay John =
F Dr
CTR USAF AFSEO/SK
Inviato: marted=EC 12 dicembre 2006 16.45
A: 'PLIB Developers'
Oggetto: Re: [Plib-devel] R: R: Texture loading problems (bmp/rgb)

OK, I have put the "ulMin" and "ulMax" into UL and made the appropriate
changes to the "ssgLoad3ds.cxx" file.  As always, please check them out =
to
make sure I have done them correctly.

I would suggest that other occurrences of "min" and "max" (that are not
local variables or elements of structures/classes) be changed over to =
the
new defined constants.

John F. Fay=20
Technical Fellow=20
Jacobs/Sverdrup TEAS Group=20
850-883-1294=20

-----Original Message-----=20
From: pli...@li...
[mailto:pli...@li...] On Behalf Of Paolo
Leoncini

Sent: Tuesday, December 12, 2006 5:13 AM=20
To: Mar...@mg...; 'PLIB Developers'=20
Subject: [Plib-devel] R: R: Texture loading problems (bmp/rgb)=20

> -----Messaggio originale-----=20
> Da: pli...@li...=20
> [mailto:pli...@li...] Per conto=20
> di Martin Spott=20
> Inviato: marted=EC 12 dicembre 2006 11.25=20
> A: pli...@li...=20
> Oggetto: Re: [Plib-devel] R: Texture loading problems (bmp/rgb)=20
>=20
>=20
> "Paolo Leoncini" wrote:=20
>=20
> > Main modifications dealed the following points:=20
> >=20
> >=20
> > ssgLoad3DS.cxx:=20
> >=20
> > 1. removal of the y-tex coord flipping for BMPs - harmful after the=20
> > Jan Reucker's patch to the BMP loader;=20
> >=20
> > 2. support for the $$$DUMMY object name - it is part of the=20
> "standard"=20
> > format definition, and occurs sometime in actual data=20
> files; when not=20
> > managed it invalidates hierarchy reconstruction;=20
> >=20
> > 3. split of large objects in leaves of max 10922 triangles=20
> each - in=20
> > such a way that each vertex index doesn't exceed sizeof(short),=20
> > putting in crisis SSG geom get functions;=20
>=20
> I guess something's missing here - unfortunately I can't=20
> remember where this 'min' is being declared:=20
>=20
> make[2]: Entering directory `/usr/local/src/plib/src/ssg'=20
> x86_64-linux-g++-3.4 -O3 -march=3Dopteron -DPACKAGE_NAME=3D\"\"=20
>   -DPACKAGE_TARNAME=3D\"\" -DPACKAGE_VERSION=3D\"\" =
-DPACKAGE_STRING=3D\"\"=20
>   -DPACKAGE_BUGREPORT=3D\"\" -DPACKAGE=3D\"plib\" =
-DVERSION=3D\"1.8.4\"=20
>   -DHAVE_LIBPTHREAD=3D1 -DHAVE_LIBGL=3D1 -DHAVE_LIBDL=3D1 =
-DSTDC_HEADERS=3D1=20
>   -DHAVE_SYS_TYPES_H=3D1 -DHAVE_SYS_STAT_H=3D1 -DHAVE_STDLIB_H=3D1=20
>   -DHAVE_STRING_H=3D1 -DHAVE_MEMORY_H=3D1 -DHAVE_STRINGS_H=3D1=20
>   -DHAVE_INTTYPES_H=3D1 -DHAVE_STDINT_H=3D1 -DHAVE_UNISTD_H=3D1 -I. =
-I.=20
>   -I../../src/sg -I../../src/util -I/opt/gnu/include=20
> -I/usr/local/include=20
>   -I/usr/X11R6/include -g -O2 -Wall -c ssgLoad3ds.cxx=20
> ssgLoad3ds.cxx: In function `int parse_face_list(unsigned int)':=20
> ssgLoad3ds.cxx:837: error: `min' undeclared (first use this function)=20
> ssgLoad3ds.cxx:837: error: (Each undeclared identifier is=20
> reported only once for each function it appears in.)=20
> ssgLoad3ds.cxx: In function `int parse_face_materials(unsigned int)':=20
> ssgLoad3ds.cxx:1040: error: `min' undeclared (first use this function) =

> ssgLoad3ds.cxx: At global scope:=20
> ssgLoad3ds.cxx:1117: warning: 'last_structure_id' defined but not used =

> make[2]: *** [ssgLoad3ds.o] Error 1=20

Sorry, my fault. The include hierarchy here is:=20
ssgLoad3ds.cxx=20
- ssglocal.h=20
-- ssg.h=20
--- sg.h=20
---- ul.h=20
Under Win32/MSVC=20
----- windows.h=20
------ windef.h (which contains the min() macro)=20

For a local solution I kindly ask someone to apply the attached patch.=20

A general solution could be adding the two classic min/max macros in =
ul.h=20
once for all:=20

#define ulMax(a,b)      ((a)>(b)?(a):(b))=20
#define ulMin(a,b)      ((a)<(b)?(a):(b))=20

Furthermore still regarding the UL, by preceeding the windows.h include =
by=20
the symbol definition=20

WIN32_LEAN_AND_MEAN=20

makes such include much lighter, i.e. avoids including most of the =
non-basic

Windows declarations, which Plib does not need anyway.=20

> Martin.=20

Greetings -=20

Paolo=20

Re: [Plib-devel] build break on mac os x plib with svn version and gcc > 3.3 ( patched)

[Fay J. F Dr C. U. AFSEO/SK <joh...@eg...>]

Ima,

	Thank you for pointing out the error.  I will fix it in SVN.

	While the earlier versions of GCC didn't complain about the static
linkage of the static class member function, I don't think it is good C++
practice (anybody who disagrees with me is free to correct me on this point)
so I have not bothered with the GCC version checking.  I have simply taken
out the word "static" on line 279.

John F. Fay
Technical Fellow
Jacobs/Sverdrup TEAS Group
850-883-1294 

-----Original Message-----
From: Ima Sudonim [mailto:Ima...@co...] 
Sent: Sunday, December 10, 2006 6:06 AM
To: joh...@eg...
Subject: build break on mac os x plib with svn version and gcc > 3.3
(patched)

John,

Hi, there is an error in the mac os x js code (jsMacOSX.cxx) that is  
in svn.

gcc 3.3 just warns about the problem (static member function  
declaration)

[g4:plib/src/js] ima% gcc-3.3 jsmacosx.cxx -I/include/plib
jsmacosx.cxx:279: warning: cannot declare member function `static void
    os_specific_s::elementEnumerator(const void*, void*)' to have  
static linkage

at least 4.0 and later treat this as an error and break the plib  
build on mac os x

[g4:plib/src/js] ima% gcc-4.0 jsmacosx.cxx -I/include/plib
jsmacosx.cxx:278: error: cannot declare member function 'static void  
os_specific_s::elementEnumerator(const void*, void*)' to have static  
linkage

I have enclosed a patch to fix this problem for versions of gcc > 3.3  
(I'm not sure when the behavior changed). The static in the function  
prototype does not cause problems even on versions of gcc > 3.3 so I  
left that alone.

I don't know if any previous versions of mac os x relied on this  
static behavior so I left the 'static' keyword in for compiles with  
gcc versions 3.3 or earlier

With these changes, I verified that the file builds without this  
error on mac os x (10.4.8) with gcc versions 3.3, 4.0, and 4.01

g++ -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\"  
-DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"plib\" - 
DVERSION=\"1.8.4\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 - 
DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 - 
DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 - 
DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1  -I. -I. -I../../src/util    -g - 
O2 -Wall -c -o jsMacOSX.o `test -f 'jsMacOSX.cxx' || echo  
'./'`jsMacOSX.cxx
rm -f libplibjs.a
ar cru libplibjs.a js.o jsLinux.o jsLinuxOld.o jsMacOS.o jsMacOSX.o  
jsWindows.o jsBSD.o jsNone.o
ranlib libplibjs.a

If this meets with your approval, could you please patch the file in  
svn?

Thank you for your help and thank you for all your work on the plib  
project...

Best regards

Ima

---------
--- jsmacosx.cxx.orig   2006-10-17 17:45:32.000000000 -0400
+++ jsMacosx.cxx        2006-12-10 06:49:57.000000000 -0500
@@ -18,7 +18,7 @@
       For further information visit http://plib.sourceforge.net
-     $Id: jsMacOSX.cxx 1960 2004-09-21 11:45:55Z smokydiamond $
+     $Id: jsMacOSX.cxx,v 1.4 2004/09/21 11:45:55 smokydiamond Exp $
*/
#include "js.h"
@@ -275,8 +275,13 @@
                 &elementEnumerator, joy);
}
+// compiling with gcc newer than v. 3.3 breaks build if static used  
here
+#if ( ( __GNUC__ >= 4 ) || ( __GNUC__ == 3 ) && (__GNUC_MINOR__  >  
3 ) )
+void os_specific_s::elementEnumerator( const void *element, void* vjs)
+#else
static void os_specific_s::elementEnumerator( const void *element,  
void* vjs)
-{
+#endif // GNU C version test
+{
         if (CFGetTypeID((CFTypeRef) element) != CFDictionaryGetTypeID 
()) {
                 ulSetError(UL_WARNING, "element enumerator passed  
non-dictionary value");
                 return;
---------

Re: [Plib-devel] R: R: Texture loading problems (bmp/rgb)

[Fay J. F Dr C. U. AFSEO/SK <joh...@eg...>]

OK, I have put the "ulMin" and "ulMax" into UL and made the appropriate
changes to the "ssgLoad3ds.cxx" file.  As always, please check them out =
to
make sure I have done them correctly.

I would suggest that other occurrences of "min" and "max" (that are not
local variables or elements of structures/classes) be changed over to =
the
new defined constants.

John F. Fay
Technical Fellow
Jacobs/Sverdrup TEAS Group
850-883-1294=20

-----Original Message-----
From: pli...@li...
[mailto:pli...@li...] On Behalf Of Paolo
Leoncini
Sent: Tuesday, December 12, 2006 5:13 AM
To: Mar...@mg...; 'PLIB Developers'
Subject: [Plib-devel] R: R: Texture loading problems (bmp/rgb)

> -----Messaggio originale-----
> Da: pli...@li...=20
> [mailto:pli...@li...] Per conto=20
> di Martin Spott
> Inviato: marted=EC 12 dicembre 2006 11.25
> A: pli...@li...
> Oggetto: Re: [Plib-devel] R: Texture loading problems (bmp/rgb)
>=20
>=20
> "Paolo Leoncini" wrote:
>=20
> > Main modifications dealed the following points:
> >=20
> >=20
> > ssgLoad3DS.cxx:
> >=20
> > 1. removal of the y-tex coord flipping for BMPs - harmful after the =

> > Jan Reucker's patch to the BMP loader;
> >=20
> > 2. support for the $$$DUMMY object name - it is part of the=20
> "standard"=20
> > format definition, and occurs sometime in actual data=20
> files; when not=20
> > managed it invalidates hierarchy reconstruction;
> >=20
> > 3. split of large objects in leaves of max 10922 triangles=20
> each - in=20
> > such a way that each vertex index doesn't exceed sizeof(short),=20
> > putting in crisis SSG geom get functions;
>=20
> I guess something's missing here - unfortunately I can't=20
> remember where this 'min' is being declared:
>=20
> make[2]: Entering directory `/usr/local/src/plib/src/ssg'=20
> x86_64-linux-g++-3.4 -O3 -march=3Dopteron -DPACKAGE_NAME=3D\"\"
>   -DPACKAGE_TARNAME=3D\"\" -DPACKAGE_VERSION=3D\"\" =
-DPACKAGE_STRING=3D\"\"
>   -DPACKAGE_BUGREPORT=3D\"\" -DPACKAGE=3D\"plib\" =
-DVERSION=3D\"1.8.4\"
>   -DHAVE_LIBPTHREAD=3D1 -DHAVE_LIBGL=3D1 -DHAVE_LIBDL=3D1 =
-DSTDC_HEADERS=3D1
>   -DHAVE_SYS_TYPES_H=3D1 -DHAVE_SYS_STAT_H=3D1 -DHAVE_STDLIB_H=3D1
>   -DHAVE_STRING_H=3D1 -DHAVE_MEMORY_H=3D1 -DHAVE_STRINGS_H=3D1
>   -DHAVE_INTTYPES_H=3D1 -DHAVE_STDINT_H=3D1 -DHAVE_UNISTD_H=3D1 -I. =
-I.=20
>   -I../../src/sg -I../../src/util -I/opt/gnu/include=20
> -I/usr/local/include
>   -I/usr/X11R6/include -g -O2 -Wall -c ssgLoad3ds.cxx
> ssgLoad3ds.cxx: In function `int parse_face_list(unsigned int)':
> ssgLoad3ds.cxx:837: error: `min' undeclared (first use this function)
> ssgLoad3ds.cxx:837: error: (Each undeclared identifier is=20
> reported only once for each function it appears in.)
> ssgLoad3ds.cxx: In function `int parse_face_materials(unsigned int)':
> ssgLoad3ds.cxx:1040: error: `min' undeclared (first use this =
function)
> ssgLoad3ds.cxx: At global scope:
> ssgLoad3ds.cxx:1117: warning: 'last_structure_id' defined but not =
used
> make[2]: *** [ssgLoad3ds.o] Error 1

Sorry, my fault. The include hierarchy here is:
ssgLoad3ds.cxx
- ssglocal.h=20
-- ssg.h=20
--- sg.h=20
---- ul.h
Under Win32/MSVC
----- windows.h
------ windef.h (which contains the min() macro)

For a local solution I kindly ask someone to apply the attached patch.

A general solution could be adding the two classic min/max macros in =
ul.h
once for all:

#define ulMax(a,b)	((a)>(b)?(a):(b))
#define ulMin(a,b)	((a)<(b)?(a):(b))

Furthermore still regarding the UL, by preceeding the windows.h include =
by
the symbol definition

WIN32_LEAN_AND_MEAN

makes such include much lighter, i.e. avoids including most of the =
non-basic
Windows declarations, which Plib does not need anyway.

> Martin.

Greetings -

Paolo

Re: [Plib-devel] R: Texture loading problems (bmp/rgb)

[Fay J. F Dr C. U. AFSEO/SK <joh...@eg...>]

Jan,

	It is done.  As before, please check out the new changes to see if I
have done them correctly.

John F. Fay
Technical Fellow
Jacobs/Sverdrup TEAS Group
850-883-1294 

-----Original Message-----
From: pli...@li...
[mailto:pli...@li...] On Behalf Of Jan Reucker
Sent: Monday, December 11, 2006 1:40 PM
To: pli...@li...
Subject: Re: [Plib-devel] R: Texture loading problems (bmp/rgb)

Am Mon, 11 Dec 2006 15:22:27 +0100 schrieb "Paolo Leoncini"
<p.l...@ci...>:

> John,
>  
> following your kind offer, here are the patches for the 3DS loader/writer
> against current SVN versions.

Hello John,

and here's the matching BMP loader patch. Thanks again for your
kind offer to apply these.

The patch was made against the latest release candidate because I
couldn't access the SVN repo at this time, but nothing has changed
in this file for a long time so the patch should work fine with
the latest SVN revision.

Kind regards,
Jan R.

-- 
Jan Reucker
email: jan dot reucker at web dot de
web:   http://www.reucker-online.de

[Plib-devel] R: R: Texture loading problems (bmp/rgb)

[Paolo L. <p.l...@ci...>]

> -----Messaggio originale-----
> Da: pli...@li...=20
> [mailto:pli...@li...] Per conto=20
> di Martin Spott
> Inviato: marted=EC 12 dicembre 2006 11.25
> A: pli...@li...
> Oggetto: Re: [Plib-devel] R: Texture loading problems (bmp/rgb)
>=20
>=20
> "Paolo Leoncini" wrote:
>=20
> > Main modifications dealed the following points:
> >=20
> >=20
> > ssgLoad3DS.cxx:
> >=20
> > 1. removal of the y-tex coord flipping for BMPs - harmful after the=20
> > Jan Reucker's patch to the BMP loader;
> >=20
> > 2. support for the $$$DUMMY object name - it is part of the=20
> "standard"=20
> > format definition, and occurs sometime in actual data=20
> files; when not=20
> > managed it invalidates hierarchy reconstruction;
> >=20
> > 3. split of large objects in leaves of max 10922 triangles=20
> each - in=20
> > such a way that each vertex index doesn't exceed sizeof(short),=20
> > putting in crisis SSG geom get functions;
>=20
> I guess something's missing here - unfortunately I can't=20
> remember where this 'min' is being declared:
>=20
> make[2]: Entering directory `/usr/local/src/plib/src/ssg'=20
> x86_64-linux-g++-3.4 -O3 -march=3Dopteron -DPACKAGE_NAME=3D\"\"
>   -DPACKAGE_TARNAME=3D\"\" -DPACKAGE_VERSION=3D\"\" =
-DPACKAGE_STRING=3D\"\"
>   -DPACKAGE_BUGREPORT=3D\"\" -DPACKAGE=3D\"plib\" =
-DVERSION=3D\"1.8.4\"
>   -DHAVE_LIBPTHREAD=3D1 -DHAVE_LIBGL=3D1 -DHAVE_LIBDL=3D1 =
-DSTDC_HEADERS=3D1
>   -DHAVE_SYS_TYPES_H=3D1 -DHAVE_SYS_STAT_H=3D1 -DHAVE_STDLIB_H=3D1
>   -DHAVE_STRING_H=3D1 -DHAVE_MEMORY_H=3D1 -DHAVE_STRINGS_H=3D1
>   -DHAVE_INTTYPES_H=3D1 -DHAVE_STDINT_H=3D1 -DHAVE_UNISTD_H=3D1 -I. =
-I.=20
>   -I../../src/sg -I../../src/util -I/opt/gnu/include=20
> -I/usr/local/include
>   -I/usr/X11R6/include -g -O2 -Wall -c ssgLoad3ds.cxx
> ssgLoad3ds.cxx: In function `int parse_face_list(unsigned int)':
> ssgLoad3ds.cxx:837: error: `min' undeclared (first use this function)
> ssgLoad3ds.cxx:837: error: (Each undeclared identifier is=20
> reported only once for each function it appears in.)
> ssgLoad3ds.cxx: In function `int parse_face_materials(unsigned int)':
> ssgLoad3ds.cxx:1040: error: `min' undeclared (first use this function)
> ssgLoad3ds.cxx: At global scope:
> ssgLoad3ds.cxx:1117: warning: 'last_structure_id' defined but not used
> make[2]: *** [ssgLoad3ds.o] Error 1

Sorry, my fault. The include hierarchy here is:
ssgLoad3ds.cxx
- ssglocal.h=20
-- ssg.h=20
--- sg.h=20
---- ul.h
Under Win32/MSVC
----- windows.h
------ windef.h (which contains the min() macro)

For a local solution I kindly ask someone to apply the attached patch.

A general solution could be adding the two classic min/max macros in =
ul.h
once for all:

#define ulMax(a,b)	((a)>(b)?(a):(b))
#define ulMin(a,b)	((a)<(b)?(a):(b))

Furthermore still regarding the UL, by preceeding the windows.h include =
by
the symbol definition

WIN32_LEAN_AND_MEAN

makes such include much lighter, i.e. avoids including most of the =
non-basic
Windows declarations, which Plib does not need anyway.

> Martin.

Greetings -

Paolo

Re: [Plib-devel] R: Texture loading problems (bmp/rgb)

[Martin S. <Mar...@mg...>]

"Paolo Leoncini" wrote:

> Main modifications dealed the following points:
> 
> 
> ssgLoad3DS.cxx:
> 
> 1. removal of the y-tex coord flipping for BMPs - harmful after the Jan
> Reucker's patch to the BMP loader;
> 
> 2. support for the $$$DUMMY object name - it is part of the "standard"
> format definition, and occurs sometime in actual data files; when not
> managed it invalidates hierarchy reconstruction;
> 
> 3. split of large objects in leaves of max 10922 triangles each - in such a
> way that each vertex index doesn't exceed sizeof(short), putting in crisis
> SSG geom get functions;

I guess something's missing here - unfortunately I can't remember where
this 'min' is being declared:

make[2]: Entering directory `/usr/local/src/plib/src/ssg'
x86_64-linux-g++-3.4 -O3 -march=opteron -DPACKAGE_NAME=\"\"
  -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\"
  -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"plib\" -DVERSION=\"1.8.4\"
  -DHAVE_LIBPTHREAD=1 -DHAVE_LIBGL=1 -DHAVE_LIBDL=1 -DSTDC_HEADERS=1
  -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1
  -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1
  -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -I. -I. 
  -I../../src/sg -I../../src/util -I/opt/gnu/include -I/usr/local/include
  -I/usr/X11R6/include -g -O2 -Wall -c ssgLoad3ds.cxx
ssgLoad3ds.cxx: In function `int parse_face_list(unsigned int)':
ssgLoad3ds.cxx:837: error: `min' undeclared (first use this function)
ssgLoad3ds.cxx:837: error: (Each undeclared identifier is reported only once for each function it appears in.)
ssgLoad3ds.cxx: In function `int parse_face_materials(unsigned int)':
ssgLoad3ds.cxx:1040: error: `min' undeclared (first use this function)
ssgLoad3ds.cxx: At global scope:
ssgLoad3ds.cxx:1117: warning: 'last_structure_id' defined but not used
make[2]: *** [ssgLoad3ds.o] Error 1


Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------

Re: [Plib-devel] patch for compiling on Solaris 10

[Vikas N K. <vik...@us...>]

Hi John,
The socklen_t problem is occurring since you have the following in
your configure.in
Here are the details in config.log for the Sun Studio 11 compiler
running on Solaris 10.
socklen_t is defined in /usr/include/sys/socket.h but yet, the test
below (at the end of the email) fails.

Why? Because of the "-Wall" option. Sun Studio 11 compilers on Solaris
10 do not support the -Wall option. Hence the exit code $? is 1
because of which socklen_t gets defined as int instead of size_t or
uint32_t.
You could try "+w2" for a certain level of warnings.

In any case, we should not check for socklen_t since it is defined on
most systems. This checking is very antiquated on Unixes. If you look
at configure.in the check has been added for Unix98. Even if it is
defined in the header files, if socklen_t gets into the compile line
as -Dsocklen_t=int or -Dsocklen_t=size_t, we will still have to
undefine it before it is typedef'd in <netinet/in.h>

Regarding strstr(), on Solaris10 in the header files the strstr()
function returns a const char* for __cplusplus>=199711L which
apparently is some C++ standard (ISO/IEC 14882:1998) (lifted this off
the header file, i.e. in /usr/include/iso/string_iso.h) The header
file /usr/include/string.h uses this iso/string_iso.h header file for
all its string functions.


Regards,
Vikas

configure:7169: checking for socklen_t
configure:7191: /opt/SUNWspro/bin/cc -c -g -Wall
-I/export/home/vicash/FLIGHTGEAR/run/include conftest.c >&5
cc: illegal option -Wall
configure:7197: $? = 1
configure: failed program was:
| /* confdefs.h.  */
|
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE "plib"
| #define VERSION "1.8.4"
| #ifdef __cplusplus
| extern "C" void exit (int);
| #endif
| #define HAVE_LIBPTHREAD 1
| #define HAVE_LIBGL 1
| #define HAVE_LIBDL 1
| #define STDC_HEADERS 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| /* end confdefs.h.  */
|
| #include <sys/types.h>
| #include <sys/socket.h>
| socklen_t apa;
|
| int
| main ()
| {
|
|   ;
|   return 0;
| }
configure:7240: /opt/SUNWspro/bin/cc -c -g -Wall
-I/export/home/vicash/FLIGHTGEAR/run/include conftest.c >&5
cc: illegal option -Wall
configure:7246: $? = 1
configure: failed program was:
| /* confdefs.h.  */
|
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE "plib"
| #define VERSION "1.8.4"
| #ifdef __cplusplus
| extern "C" void exit (int);
| #endif
| #define HAVE_LIBPTHREAD 1
| #define HAVE_LIBGL 1
| #define HAVE_LIBDL 1
| #define STDC_HEADERS 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| /* end confdefs.h.  */
|
| #include <sys/types.h>
| #include <sys/socket.h>
| int accept (int, struct sockaddr *, size_t *);
|
| int
| main ()
| {
|
|   ;
|   return 0;
| }
configure:7273: result: int

Re: [Plib-devel] R: Texture loading problems (bmp/rgb)

[Fay J. F Dr C. U. AFSEO/SK <joh...@eg...>]

Paolo,

	I have put your changes into SVN.  Please check out a new version
and make sure I have done it right.

John F. Fay
Technical Fellow
Jacobs/Sverdrup TEAS Group
850-883-1294 

-----Original Message-----
From: pli...@li...
[mailto:pli...@li...] On Behalf Of Paolo
Leoncini
Sent: Monday, December 11, 2006 8:22 AM
To: 'PLIB Developers'
Subject: [Plib-devel] R: Texture loading problems (bmp/rgb)

John,
 
following your kind offer, here are the patches for the 3DS loader/writer
against current SVN versions.
 
<snip>

Re: [Plib-devel] R: Texture loading problems (bmp/rgb)

[Jan R. <slo...@gm...>]

Am Mon, 11 Dec 2006 15:22:27 +0100 schrieb "Paolo Leoncini" <p.l...@ci...>:

> John,
>  
> following your kind offer, here are the patches for the 3DS loader/writer
> against current SVN versions.

Hello John,

and here's the matching BMP loader patch. Thanks again for your
kind offer to apply these.

The patch was made against the latest release candidate because I
couldn't access the SVN repo at this time, but nothing has changed
in this file for a long time so the patch should work fine with
the latest SVN revision.

Kind regards,
Jan R.

-- 
Jan Reucker
email: jan dot reucker at web dot de
web:   http://www.reucker-online.de

Re: [Plib-devel] patch for compiling on Solaris 10

[Vikas N K. <vik...@us...>]

Hi John,
The configure script added the -Dsocklen_t=int in my compile line.
Why it did that I have no idea, I did not look. I will look at it and
let you know.

The sun studio 11 C++ compiler was giving an error in saying strstr
was returning a const char*. I guess that is how it is on Solaris 10.
I shall look into that too. You could however use the UL_BB #ifdefs
and do it instead of the explicit cast.

Even for the socklen_t=int problem, one could test for UL_SOLARIS and
then do the #undef statements as given in the patch as opposed to
undefining it without any Operating system checks.


Regards,
Vikas

> From: Fay John F Dr CTR USAF AFSEO/SK <joh...@eg...>
> Subject: Re: [Plib-devel] patch for compiling on Solaris 10
> Vikas,
>
>         I'm a little confused about the "socklen_t" problem you mention.  I
> looked around the Linux system header files a bit and find
>
> #ifndef __socklen_t_defined
> typedef __socklen_t socklen_t
> #endif
>
> The only place I see "socklen_t" used in PLIB is in "netSocket.cxx", where
> it is defined to be "int" under MSVC if it has not already been defined.  As
> such, perhaps the problem lies with the "configure" adding that flag to your
> compile line.  Does anybody know what causes it?
>
>         I am similarly confused by the addition of "(char *)" to the
> "strstr" call in netChat.cxx.  The "strstr" function already returns a value
> of type "char *" so the cast should be unnecessary.  Is there something
> about the Sun Studio 11 compiler that is nonstandard?  If there is, I will
> certainly be willing to add the explicit cast, but if not I would just as
> soon leave it out.  (Perhaps we should use a "#ifdef UL_BB" block here.)
>
> John F. Fay
> Technical Fellow
> Jacobs/Sverdrup TEAS Group
> 850-883-1294

-- 
http://www.vikaskumar.org/

Re: [Plib-devel] patch for compiling on Solaris 10

[Fay J. F Dr C. U. AFSEO/SK <joh...@eg...>]

Vikas,

	I'm a little confused about the "socklen_t" problem you mention.  I
looked around the Linux system header files a bit and find

#ifndef __socklen_t_defined
typedef __socklen_t socklen_t
#endif

The only place I see "socklen_t" used in PLIB is in "netSocket.cxx", where
it is defined to be "int" under MSVC if it has not already been defined.  As
such, perhaps the problem lies with the "configure" adding that flag to your
compile line.  Does anybody know what causes it?

	I am similarly confused by the addition of "(char *)" to the
"strstr" call in netChat.cxx.  The "strstr" function already returns a value
of type "char *" so the cast should be unnecessary.  Is there something
about the Sun Studio 11 compiler that is nonstandard?  If there is, I will
certainly be willing to add the explicit cast, but if not I would just as
soon leave it out.  (Perhaps we should use a "#ifdef UL_BB" block here.)

John F. Fay
Technical Fellow
Jacobs/Sverdrup TEAS Group
850-883-1294 
-----Original Message-----
From: pli...@li...
[mailto:pli...@li...] On Behalf Of Vikas N Kumar
Sent: Sunday, December 10, 2006 2:24 AM
To: pli...@li...
Subject: [Plib-devel] patch for compiling on Solaris 10

Hi
To compile with the Sun Studio 11 compilers on Solaris 10 on a SPARC I
had to do the following changes to make plib compile cleanly.
When I run configure, the flag "-Dsocklen_t=int" is added to my
compile line for all files. Hence I have to undefine it in 2 files to
get them to compile properly since socklen_t is defined as a typedef
of "uint32_t" in those files.

Regards,
Vikas


<snip>

Re: [Plib-devel] patch for compiling on Solaris 10

[Martin S. <Mar...@mg...>]

"Vikas N Kumar" wrote:

> To compile with the Sun Studio 11 compilers on Solaris 10 on a SPARC I
> had to do the following changes to make plib compile cleanly.
> When I run configure, the flag "-Dsocklen_t=int" is added to my
> compile line for all files. Hence I have to undefine it in 2 files to
> get them to compile properly since socklen_t is defined as a typedef
> of "uint32_t" in those files.

I'd love to see such a patch incorporated into PLIB. For the past years
or so, after PLIB development stalled, I've been using a workaround
that looks like this:

for i in `find . -type f -name Makefile`; do
  echo -e ",s/-Dsocklen_t=int//g\nwq" | ed $i
done


....  which I consider as "elegant" but not a "real solution" (TM  ;-),
I guess your's is much better,

	Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------

[Plib-devel] patch for compiling on Solaris 10

[Vikas N K. <wa...@gm...>]

Hi
To compile with the Sun Studio 11 compilers on Solaris 10 on a SPARC I
had to do the following changes to make plib compile cleanly.
When I run configure, the flag "-Dsocklen_t=int" is added to my
compile line for all files. Hence I have to undefine it in 2 files to
get them to compile properly since socklen_t is defined as a typedef
of "uint32_t" in those files.

Regards,
Vikas


Index: src/net/netMessage.h
===================================================================
--- src/net/netMessage.h        (revision 2106)
+++ src/net/netMessage.h        (working copy)
@@ -43,6 +43,9 @@
 #include "netBuffer.h"

 #ifndef UL_MSVC
+#ifdef socklen_t
+#undef socklen_t
+#endif
 #include <netinet/in.h> // ntohs() etc prototypes
 #endif

Index: src/net/netChat.cxx
===================================================================
--- src/net/netChat.cxx (revision 2106)
+++ src/net/netChat.cxx (working copy)
@@ -63,7 +63,7 @@
   if (needle && *needle)
   {
     const char* data = haystack.getData();
-    char* ptr = strstr(data,needle);
+    char* ptr = (char*)strstr(data,needle);
     if (ptr != NULL)
       return(ptr-data);
   }Index: src/net/netSocket.cxx
===================================================================
--- src/net/netSocket.cxx       (revision 2106)
+++ src/net/netSocket.cxx       (working copy)
@@ -29,6 +29,10 @@
 #  include <netinet/in.h>
 #endif

+#ifdef socklen_t
+#undef socklen_t
+#endif
+
 #include <sys/types.h>
 #include <sys/socket.h>
 #include <netinet/in.h>
Index: src/util/ul.h
===================================================================
--- src/util/ul.h       (revision 2106)
+++ src/util/ul.h       (working copy)
@@ -87,6 +87,7 @@
 #elif defined(SOLARIS) || defined(sun)

 #define UL_SOLARIS   1
+#define UL_BB  1

 #elif defined(hpux)

Re: [Plib-devel] Example Program Changes

[Fay J. F Dr C. U. AFSEO/SK <joh...@eg...>]

Gentlemen,

	At Wolfram's request--and because it is the Right Thing To Do--I
have removed the "CreateWidget.cxx" file from the SVN tree.  It was
redundant.

	I have also modified pGuide's MSVC project files to define
"FREEGLUT_STATIC" so that it links statically to "freeglut" and have removed
the reference to "glut32.lib" which was redundant at best and caused link
errors at worst.

John F. Fay
Technical Fellow
Jacobs/Sverdrup TEAS Group
850-883-1294 

-----Original Message-----
From: pli...@li...
[mailto:pli...@li...] On Behalf Of Wolfram Kuss
Sent: Wednesday, November 08, 2006 8:54 AM
To: PLIB Developers
Subject: Re: [Plib-devel] Example Program Changes

@ Melchior:
As you see, it does not compile CreateWidget.cxx and renaming that
file does not affect compilation. Please take that file out of the
makefile and see what happens. 

@John F. Fay:
Please check that file is superfluous and then remove it from SVN.

[Plib-devel] R: R: Texture loading problems (bmp/rgb)

[Paolo L. <p.l...@ci...>]

Thanks a lot.
=20
Jan Reucker (for the BMP loader) and I (for the 3DS loader) are going to
finalize the private thread on the impact of BMP loader patches on the =
3DS
one, then I'll send you the 3DS loader updates.
=20
Greetings -
=20
Paolo
=20
 -----Messaggio originale-----
Da: pli...@li...
[mailto:pli...@li...] Per conto di Fay John =
F Dr
CTR USAF AFSEO/SK
Inviato: marted=EC 28 novembre 2006 15.16
A: 'PLIB Developers'
Oggetto: Re: [Plib-devel] R: Texture loading problems (bmp/rgb)



Paolo,=20

        It appears that nobody else has stepped forward so I will =
volunteer
to be the "good will man."  Bring on the patches!

John F. Fay=20
Technical Fellow=20
Jacobs/Sverdrup TEAS Group=20
850-883-1294=20

-----Original Message-----=20
From: pli...@li...
[mailto:pli...@li...] On Behalf Of Paolo
Leoncini

Sent: Wednesday, November 22, 2006 2:21 AM=20
To: 'PLIB Developers'=20
Subject: [Plib-devel] R: Texture loading problems (bmp/rgb)=20

> -----Messaggio originale-----=20
> Da: pli...@li...=20
> [mailto:pli...@li...] Per conto=20
> di Jan Reucker=20
> Inviato: marted=EC 21 novembre 2006 17.49=20
> A: pli...@li...=20
> Oggetto: Re: [Plib-devel] Texture loading problems (bmp/rgb)=20
>=20
[snip]=20
> I think I'll prepare a patch, but I guess this will breakt 3ds=20
> loading until we also remove the forced bmp texture flipping there...=20

I can supply the updated ssgload3ds.cxx also including other patches =
that=20
were tested time ago by someone in the FlightGear dev team but never put =
in=20
cvs since I'm not an official Plib developer. If agreed I'll send it to =
the=20
good will man...=20

> Kind regards,=20
> Jan R.=20

Greetings -=20

Paolo Leoncini=20


-------------------------------------------------------------------------=
=20
Take Surveys. Earn Cash. Influence the Future of IT=20
Join SourceForge.net's Techsay panel and you'll get the chance to share =
your

opinions on IT & business topics through brief surveys - and earn cash=20
http://www.techsay.com/default.php?page=3Djoin.php
<http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDEV>
&p=3Dsourceforge&CID=3DDEVDEV=20
_______________________________________________=20
plib-devel mailing list=20
pli...@li...=20
https://lists.sourceforge.net/lists/listinfo/plib-devel=20

Re: [Plib-devel] R: Texture loading problems (bmp/rgb)

[Fay J. F Dr C. U. AFSEO/SK <joh...@eg...>]

Paolo,

	It appears that nobody else has stepped forward so I will volunteer
to be the "good will man."  Bring on the patches!

John F. Fay
Technical Fellow
Jacobs/Sverdrup TEAS Group
850-883-1294=20

-----Original Message-----
From: pli...@li...
[mailto:pli...@li...] On Behalf Of Paolo
Leoncini
Sent: Wednesday, November 22, 2006 2:21 AM
To: 'PLIB Developers'
Subject: [Plib-devel] R: Texture loading problems (bmp/rgb)

> -----Messaggio originale-----
> Da: pli...@li...=20
> [mailto:pli...@li...] Per conto=20
> di Jan Reucker
> Inviato: marted=EC 21 novembre 2006 17.49
> A: pli...@li...
> Oggetto: Re: [Plib-devel] Texture loading problems (bmp/rgb)
>=20
[snip]
> I think I'll prepare a patch, but I guess this will breakt 3ds=20
> loading until we also remove the forced bmp texture flipping there...

I can supply the updated ssgload3ds.cxx also including other patches =
that
were tested time ago by someone in the FlightGear dev team but never =
put in
cvs since I'm not an official Plib developer. If agreed I'll send it to =
the
good will man...

> Kind regards,
> Jan R.

Greetings -

Paolo Leoncini


------------------------------------------------------------------------=
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share =
your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDEV
_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel