Re: [osg-users] Mac OSX code signing and osgPlugins dir

[Alistair Baxter]

Initial experiments suggest renaming the original plugin dir and creating a 
symlink with the name with periods in may work.

From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf 
Of Alistair Baxter
Sent: 07 April 2016 16:46
To: osg-users@lists.openscenegraph.org
Subject: [osg-users] Mac OSX code signing and osgPlugins dir

When building our application for mac, and trying to run the code signing tool, 
it is currently choking on the name of the plugin directory within the app 
bundle.

It would seem that it objects to the period characters (i.e. full stops)  in 
Contents/Plugins/osgPlugins-3.4.0 . If I change it to osgPlugins-340, it signs 
happily. I'm not sure why it's complaining now, since it was OK before. I think 
it may be because we have moved to OSX 10.9 as a minimum build environment, 
since signing appears to have changed a bit with that release, according to the 
Mac developer website.

Looking through the code, it seems like this directory name is hard-wired into 
quite a few places, so it would be a pain to unpick. Does anybody have 
experience of this issue or a suggestion of how to get past it?
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Mac OSX code signing and osgPlugins dir

[Alistair Baxter]

When building our application for mac, and trying to run the code signing tool, 
it is currently choking on the name of the plugin directory within the app 
bundle.

It would seem that it objects to the period characters (i.e. full stops)  in 
Contents/Plugins/osgPlugins-3.4.0 . If I change it to osgPlugins-340, it signs 
happily. I'm not sure why it's complaining now, since it was OK before. I think 
it may be because we have moved to OSX 10.9 as a minimum build environment, 
since signing appears to have changed a bit with that release, according to the 
Mac developer website.

Looking through the code, it seems like this directory name is hard-wired into 
quite a few places, so it would be a pain to unpick. Does anybody have 
experience of this issue or a suggestion of how to get past it?
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Mac compilation error

[michael kapelko]

I think
http://www.openscenegraph.com/index.php/download-section/code-repositories
should be updated to reflect that Git is the main repo.

2015-11-27 0:06 GMT+07:00 Robert Osfield :

> Hi Andrew,
>
> On 26 November 2015 at 01:53, Andrew Janke  wrote:
>
>> > [...snip...]
>> >
>> > I haven't had chance to update the OSG website with links to this yet -
>> still early days for moving to github, this morning checkin to github is my
>> first :-)
>> >
>> >
>> > Robert.
>> >
>> >
>>
>> Does this mean users should now switch to using the GitHub repo as the
>> main source code source, instead of the old SVN repo?
>>
>> If so, we'll update the Homebrew open-scene-graph formula  to reflect
>> this.
>>
>
> github is now the master so if you have links to the old svn repository
> then it would be appropriate to update these.
>
> It's a bit unfortunate that I left the svn repository in a state that
> didn't build across all platforms - I didn't find out the build errors till
> after I moved across.
>
> Robert.
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Mac compilation error

[Andrew Janke]

> 
> 
> github is no longer connected to the old svn repository.
> 
>  
> 
> > So if you do a commit in github it is not updated in the svn. 
> > So now it is not syncrhonized.
> > 
> > 
> 
> 
> [...snip...]
> 
> I haven't had chance to update the OSG website with links to this yet - still 
> early days for moving to github, this morning checkin to github is my first 
> :-)
> 
> 
> Robert.
> 
> 


Does this mean users should now switch to using the GitHub repo as the main 
source code source, instead of the old SVN repo?

If so, we'll update the Homebrew open-scene-graph formula  to reflect this.

Andrew

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=65768#65768





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Mac compilation error

[Robert Osfield]

Hi Andrew,

On 26 November 2015 at 01:53, Andrew Janke  wrote:

> > [...snip...]
> >
> > I haven't had chance to update the OSG website with links to this yet -
> still early days for moving to github, this morning checkin to github is my
> first :-)
> >
> >
> > Robert.
> >
> >
>
> Does this mean users should now switch to using the GitHub repo as the
> main source code source, instead of the old SVN repo?
>
> If so, we'll update the Homebrew open-scene-graph formula  to reflect this.
>

github is now the master so if you have links to the old svn repository
then it would be appropriate to update these.

It's a bit unfortunate that I left the svn repository in a state that
didn't build across all platforms - I didn't find out the build errors till
after I moved across.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Mac compilation error

[philippe renon]

Hi Robert,
That's what I figured :)
Are you going to fix it directly or should I submit the fix ?
Philippe.
 


Le Lundi 23 novembre 2015 9h45, Robert Osfield  a 
écrit :
 
 

 Hi Philippe,

This is a bug, it should be a reference - I must have made a copy and paste 
error when adapting the line to use the template ref_ptr interface.

Robert.

On 22 November 2015 at 10:02, philippe renon  wrote:

Hi,
The include/osgViewer/View include has that suspicious line:

template void setImagePager(const osg::ref_ptr* ip) { 
setImagePager(ip.get()); }
which fails to compile on mac with :member reference base type 'const 
osg::ref_ptr *' is not a structure or union
This pattern using osg::ref_ptr is used in many places but that suspicious line 
is only one with pointer instead of reference.
Philippe.


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org





 
  ___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Mac compilation error

[Jordi Torres]

Hi Robert,

The svn is connected to github but not the opposite. So if you do a commit
in github it is not updated in the svn.
So now it is not syncrhonized.

Cheers.



2015-11-23 9:59 GMT+01:00 Robert Osfield :

>
>
> On 23 November 2015 at 08:45, Robert Osfield 
> wrote:
>
>> This is a bug, it should be a reference - I must have made a copy and
>> paste error when adapting the line to use the template ref_ptr interface.
>>
>
> Fix is now checked into github's openscenegraph repository.
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>


-- 
Jordi Torres
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Mac compilation error

[Robert Osfield]

On 23 November 2015 at 09:08, Jordi Torres  wrote:

> Hi Robert,
>
> The svn is connected to github but not the opposite.
>

github is no longer connected to the old svn repository.


> So if you do a commit in github it is not updated in the svn.
> So now it is not syncrhonized.
>

github provide a link for subversion users. i.e. to check out trunk:

svn co  https://github.com/openscenegraph/osg/trunk OpenSceneGraph

I haven't had chance to update the OSG website with links to this yet -
still early days for moving to github, this morning checkin to github is my
first :-)

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Mac compilation error

[Robert Osfield]

Hi Philippe,

This is a bug, it should be a reference - I must have made a copy and paste
error when adapting the line to use the template ref_ptr interface.

Robert.

On 22 November 2015 at 10:02, philippe renon 
wrote:

> Hi,
>
> The include/osgViewer/View include has that suspicious line:
>
> template void setImagePager(const osg::ref_ptr* ip) {
> setImagePager(ip.get()); }
>
> which fails to compile on mac with :
>
> member reference base type 'const osg::ref_ptr *' is not a structure 
> or union
>
>
> This pattern using osg::ref_ptr is used in many places but that suspicious
> line is only one with pointer instead of reference.
>
> Philippe.
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Mac compilation error

[philippe renon]

Just saw that a fix was pushed. Thanks !
 


Le Lundi 23 novembre 2015 11h03, philippe renon  a 
écrit :
 
 

 Hi Robert,
That's what I figured :)
Are you going to fix it directly or should I submit the fix ?
Philippe.
 


Le Lundi 23 novembre 2015 9h45, Robert Osfield  a 
écrit :
 
 

 Hi Philippe,

This is a bug, it should be a reference - I must have made a copy and paste 
error when adapting the line to use the template ref_ptr interface.

Robert.

On 22 November 2015 at 10:02, philippe renon  wrote:

Hi,
The include/osgViewer/View include has that suspicious line:

template void setImagePager(const osg::ref_ptr* ip) { 
setImagePager(ip.get()); }
which fails to compile on mac with :member reference base type 'const 
osg::ref_ptr *' is not a structure or union
This pattern using osg::ref_ptr is used in many places but that suspicious line 
is only one with pointer instead of reference.
Philippe.


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org





 
   

 
  ___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Mac compilation error

[Robert Osfield]

On 23 November 2015 at 08:45, Robert Osfield 
wrote:

> This is a bug, it should be a reference - I must have made a copy and
> paste error when adapting the line to use the template ref_ptr interface.
>

Fix is now checked into github's openscenegraph repository.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Mac compilation error

[Jannik Heller]

Hi,

There is already a submission addressing this, but it wasn't merged yet.

http://forum.openscenegraph.org/viewtopic.php?t=15401


Cheers,
Jannik

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=65731#65731





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Mac compilation error

[philippe renon]

Hi,
The include/osgViewer/View include has that suspicious line:

template void setImagePager(const osg::ref_ptr* ip) { 
setImagePager(ip.get()); }
which fails to compile on mac with :member reference base type 'const 
osg::ref_ptr *' is not a structure or union
This pattern using osg::ref_ptr is used in many places but that suspicious line 
is only one with pointer instead of reference.
Philippe.

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Mac compilation error

[michael kapelko]

Hi.
What SVN revision is it? I can't find such a line in my r14769.

2015-11-22 17:02 GMT+07:00 philippe renon :

> Hi,
>
> The include/osgViewer/View include has that suspicious line:
>
> template void setImagePager(const osg::ref_ptr* ip) {
> setImagePager(ip.get()); }
>
> which fails to compile on mac with :
>
> member reference base type 'const osg::ref_ptr *' is not a structure 
> or union
>
>
> This pattern using osg::ref_ptr is used in many places but that suspicious
> line is only one with pointer instead of reference.
>
> Philippe.
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Mac compilation error

[philippe renon]

Hi,
It is in 3.4.0 and in head : 
https://github.com/openscenegraph/osg/blob/master/include/osgViewer/View
Philippe.

 


Le Dimanche 22 novembre 2015 13h28, michael kapelko  a 
écrit :
 
 

 Hi.
What SVN revision is it? I can't find such a line in my r14769.

2015-11-22 17:02 GMT+07:00 philippe renon :

Hi,
The include/osgViewer/View include has that suspicious line:

template void setImagePager(const osg::ref_ptr* ip) { 
setImagePager(ip.get()); }
which fails to compile on mac with :member reference base type 'const 
osg::ref_ptr *' is not a structure or union
This pattern using osg::ref_ptr is used in many places but that suspicious line 
is only one with pointer instead of reference.
Philippe.


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org





 
  ___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Mac OS runtime problem

[Tobias Duckworth]

Hi,

This problem is still present.

It seems that under MacOS OpenSceneGraph can only be built with the llvm 
compilers due to the Objective C portions of code.  I tried configuring gcc to 
compile Objective C but there appear to be some differences between the Apple 
compiler and gcc with respect to Objective C.

What I would like to do is be able to compile my application using gcc and then 
link to OpenSceneGraph - I don't really care whether OpenSceneGraph is built 
with gcc or llvm.

However, if I do build my application using gcc then it crashes.  The code 
segment can be boiled down to the following:


Code:

int main( int argc, char **argv )
{

fprintf(stderr, Creating\n);
osg::ref_ptrosg::DrawElementsUShort p = new osg::DrawElementsUShort();
fprintf(stderr, Created\n);
}




Compiled as follows:


Code:

 /opt/local/bin/gcc-mp-4.8 -o osgtest osgtest.cpp -L /usr/local/lib -losg 
-lOpenThreads -lstdc++ -I /usr/local/include/




And the crash is as follows:


Code:

Tobiass-retina-MacBook:trunk tobiasduckworth$ ./osgtest 
Creating
Created
osgtest(52671) malloc: *** error for object 0x10c7b87e0: pointer being freed 
was not allocated
*** set a breakpoint in malloc_error_break to debug
Abort trap: 6
Tobiass-retina-MacBook:trunk tobiasduckworth$ 





This problem has been present for an age, and is forcing me to use the Apple 
compilers to build my application, whereas I wish to use gcc.

Has anyone else out there experienced this problem? or have a solution to it 
please?

I would really like to be able to build my application with gcc, but due to 
this problem cannot.

... 

Thank you!

Cheers,
Tobias[/code]

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=48768#48768





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Mac OS runtime problem

[Tobias Duckworth]

Hi Stephan,

I tried building both release and debug versions of OSG with the llvm compiler 
- The debug build had the same problem (presumably built without optimisation).

... 

Thank you!

Cheers,
Tobias

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=47353#47353





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Mac OS runtime problem

[Tobias Duckworth]

Hi,

I'm building OpenSceneGraph from the head of the trunk on Mac OS 10.7 Lion 
using CMake.  The build works straight out of the box defaulting to the llvm 
compilers.

I'm using OpenSceneGraph in a project built using gcc-mp-4.7, and so linking to 
the libraries built in the above step from my project.

I'm experiencing a problem with primitive sets at runtime - Namely, a primitive 
set I create causes a crash when it goes out of scope.

I've managed to boil my problem down to a very simple implementation:


Code:

int main(int argc, char *argv[])
{
osg::ref_ptrosg::PrimitiveSet p = new osg::DrawElementsUByte();
return 0;
}





When executed, with the OSG libraries built using llvm, and the program built 
using gcc-mp-4.7, the following happens:


Code:

Tobys-MacBook-Pro:xxx tobiasduckworth$ ./3DRecon.app/Contents/MacOS/3DRecon 
3DRecon(23649,0x7fff7612f960) malloc: *** error for object 0x10e163ec0: pointer 
being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
Abort trap: 6




However, if I build the program using the same compiler (llvm) as OSG, then it 
runs fine.

My program uses OpenMP, so I need to use gcc to get this to compile, otherwise 
I could move to llvm.

I also tried to build OSG using gcc, but this failed due to osgViewer using 
Objective C.

Does anyone have any idea what might be going wrong here?
Should I be able to build OSG using llvm and my application using gcc?

Hoping someone can shed some light,
... 

Thank you!

Cheers,
Tobias

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=47314#47314





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Mac OS runtime problem

[Stephan Maximilian Huber]

HI,

have you tried to compile your own code and osg with the llvm-gcc4.2
compiler? llvm-gcc 4.2 should include openMP. (Haven't tested that by
myself)

HTH,
Stephan


Am 26.04.12 11:09, schrieb Tobias Duckworth:
 Hi,
 
 I'm building OpenSceneGraph from the head of the trunk on Mac OS 10.7 Lion 
 using CMake.  The build works straight out of the box defaulting to the llvm 
 compilers.
 
 I'm using OpenSceneGraph in a project built using gcc-mp-4.7, and so linking 
 to the libraries built in the above step from my project.
 
 I'm experiencing a problem with primitive sets at runtime - Namely, a 
 primitive set I create causes a crash when it goes out of scope.
 
 I've managed to boil my problem down to a very simple implementation:
 
 
 Code:
 
 int main(int argc, char *argv[])
 {
 osg::ref_ptrosg::PrimitiveSet p = new osg::DrawElementsUByte();
 return 0;
 }
 
 
 
 
 
 When executed, with the OSG libraries built using llvm, and the program built 
 using gcc-mp-4.7, the following happens:
 
 
 Code:
 
 Tobys-MacBook-Pro:xxx tobiasduckworth$ ./3DRecon.app/Contents/MacOS/3DRecon 
 3DRecon(23649,0x7fff7612f960) malloc: *** error for object 0x10e163ec0: 
 pointer being freed was not allocated
 *** set a breakpoint in malloc_error_break to debug
 Abort trap: 6
 
 
 
 
 However, if I build the program using the same compiler (llvm) as OSG, then 
 it runs fine.
 
 My program uses OpenMP, so I need to use gcc to get this to compile, 
 otherwise I could move to llvm.
 
 I also tried to build OSG using gcc, but this failed due to osgViewer using 
 Objective C.
 
 Does anyone have any idea what might be going wrong here?
 Should I be able to build OSG using llvm and my application using gcc?
 
 Hoping someone can shed some light,
 ... 
 
 Thank you!
 
 Cheers,
 Tobias
 
 --
 Read this topic online here:
 http://forum.openscenegraph.org/viewtopic.php?p=47314#47314
 
 
 
 
 
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Mac OS runtime problem

[Tobias Duckworth]

Hi Stephen,

Thanks for your response.

Yes I tried using llvm-gcc42 (from Macports) to build OSG yesterday - 
Unfortunately with the same end result.

I didn't know that llvm-gcc42 includes OpenMP, this may be a solution to my 
problem.  Thanks for the hint, I will look into it.

That aside, I'd still like to understand why compiling OSG with llvm and my 
program with gcc causes the observed problem.  Surely I shouldn't have to care 
which compiler the libraries I'm linking against are built with?



... 

Thank you!

Cheers,
Tobias

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=47316#47316





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Mac OS runtime problem

[Tobias Duckworth]

Hi,

Further to Stephan's suggestion, since llvm-gcc-4.2 supports OpenMP, I was able 
to get everything running using llvm-gcc-4.2. (Thanks Stephan for the info that 
llvm-gcc-42 now supports OpenMP)

However, it still strikes me as odd that failure occurs when compiling my 
program with gcc and linking to OSG built with llvm.


... 

Thank you!

Cheers,
Tobias

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=47319#47319





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Mac OS runtime problem

[Stephan Huber]

Hi Tobias,

Am 26.04.12 12:15, schrieb Tobias Duckworth:
 Further to Stephan's suggestion, since llvm-gcc-4.2 supports OpenMP, I was 
 able to get everything running using llvm-gcc-4.2. 
 (Thanks Stephan for the info that llvm-gcc-42 now supports OpenMP)
 
 However, it still strikes me as odd that failure occurs when compiling my 
 program with gcc and linking to OSG built with llvm.


I have no idea. I have the suspicion, that the optimization of llvm is
too aggressive (osg is compiled with -O3), but I'll have to do some more
tests.


cheers,

Stephan
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Mac: GLSL 120?

[Chris Hanson]

http://lwjgl.org/forum/index.php?topic=4071.0

  Apparently it's possible under Lion to get support for GLSL beyond 1.20
(#version 120). I'm not a Mac guy, so I figured I'd ask, is it possible to
trigger this support from within OSG at this point?

-- 
Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com
http://www.alphapixel.com/
Training • Consulting • Contracting
3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4 •
GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL
Digital Imaging • GIS • GPS • Telemetry • Cryptography • Digital Audio •
LIDAR • Kinect • Embedded • Mobile • iPhone/iPad/iOS • Android
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Mac: GLSL 120?

[Stephan Huber]

Hi Chris,

AFAIK it's not possible (yet) to use open gl 3 with osg on mac/lion.
There's a submission at osg-submission to add GL 3 support, but it's not
committed yet.

cheers,
Stephan

Am 13.03.12 17:07, schrieb Chris Hanson:
 http://lwjgl.org/forum/index.php?topic=4071.0
 
   Apparently it's possible under Lion to get support for GLSL beyond 1.20
 (#version 120). I'm not a Mac guy, so I figured I'd ask, is it possible to
 trigger this support from within OSG at this point?
 
 
 
 
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Mac OSX Lion Installation

[Stephan Maximilian Huber]

Hi,
Am 14.01.12 23:31, schrieb Erick Bazan:

 I'm really really new to OSG, I need to use it for my Virtual Environments 
 class. I have some experience with OpenGL in Mac with Xcode. I've been 
 searching all over the internet how to install OpenSceneGraph in Mac OSX Lion 
 and use it with Xcode (4). All I found was tutorials explaining how to 
 install it from the 2.8 dmg and I tried installing the binaries to the Lion 
 and Leopard SDK with no results. 
 
 Anyone know how to install or compile OSG projects from scratch in Lion with 
 Xcode, as I said, I'm new to the whole OSG. 

checkout/download the osg-source, download a recent cmake version, open
it, select the osg-source-tree, select a build-directory, select the
xcode-generator, make sure you set

OSG_WINDOWING_SYSTEM to Cocoa
CMAKE_INSTALL_PREFIX to your needs

If you want embeddable frameworks, set
OSG_COMPILE_FRAMEWORKS to 1 (otherwise you'll get dylibs)

generate the xcode-project files, open them in xcode, compile the
INSTALL-target, you should now find the frameworks/dylibs/plugins in
your folder given to the CMAKE_INSTALL_PREFIX

Probably the quicktime-plugin will not compile, there's a fix in
osg-submission waiting for review.

It's time to update the readme.txt as most of it's info regarding os x
is outdated.

HTH,

Stephan
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Mac OSX Lion Installation

[Erick Bazan]

Hi,

I'm really really new to OSG, I need to use it for my Virtual Environments 
class. I have some experience with OpenGL in Mac with Xcode. I've been 
searching all over the internet how to install OpenSceneGraph in Mac OSX Lion 
and use it with Xcode (4). All I found was tutorials explaining how to install 
it from the 2.8 dmg and I tried installing the binaries to the Lion and Leopard 
SDK with no results. 

Anyone know how to install or compile OSG projects from scratch in Lion with 
Xcode, as I said, I'm new to the whole OSG. 

Thank you!

Cheers,
Erick

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=44837#44837





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Mac OSX - CGL graphic context and OpenSceneGraph 3.0.0

[Robert Osfield]

Hi Guido,

From what you've written it's next to impossible to know what is amiss
- there is simply too many unkowns about what you are doing for us to
guess.

The best I can do is highlight a couple of oddities.  First up the
warning about NaN from CullVisitor suggests that that the cull
traversal has an invalid matrix being passed to it, or perhaps an
invalid matrix in the scene graph - can't pin point what, guess guess
would be something amiss at the top level i.e. viewer's camera.

Second odd thing is about adding Camera's to the GraphicsContext, in
normal OSG usage I wouldn't expect users to be doing this as when you
using osgViewer normally it'll set up all the contexts and cameras
correctly for you.  The only time I'd expect users to add a Camera to
GraphicsContext directly is when doing a custom hud style overlay such
as done by the osgViewer StatsHandler.  However, most users will do
HUD's via a Viewer level Camera or a Camera in the scene graph, it's
only in very specific cases would you ever add a Camera directly.

Third thing that seems odd is C style case of graficcontext to
osg::GraphicsContext.  I hav no clue what type graficontext is but it
it's a an actual subclass from osg::GraphicsContext then you'll never
need to cast it, and if it isn't then casting an object of a totally
different type ain't going to work - it's a basic C++ error.

Robert.

On Sat, Aug 20, 2011 at 11:02 PM, Guido Lucci Baldassari
g...@glbworkbench.com wrote:
 Good evening to everyone
 I'm not very skilled using osg itself, so maybe everything I'm going to say 
 below is wrong.

 Anyway:
 I have a problem displaying osg content with my plugin, since I updated to 
 OSG 3.
 Inside my extension, I create a CGLContextObj, then I pass it to osgviewer.
 From the debugging messages (ativated at defcon 5 - DEBUG :) ) appears that 
 the viewer is up and running, the model is loaded, but not displayed.
 The problem apparently lies here (but maybe I'm wrong... anyway I'd like to 
 fix this point)

 ...
 _MainCamera(new osg::Camera),
 ...
 ...
 ...
 osg::ref_ptrosg::GraphicsContext gc = (osg::GraphicsContext*) graficcontext;
 _MainCamera-setGraphicsContext(gc.get());
 ...

 The output that I got in the Console is:

 ...
 20.08.11 16:53:21       [0x0-0xf60f6].com.google.Chrome[7790]   
 CullVisitor::apply(Geode) detected NaN,
 20.08.11 16:53:21       [0x0-0xf60f6].com.google.Chrome[7790]       
 depth=nan, center=(11412 18917 300),
 20.08.11 16:53:21       [0x0-0xf60f6].com.google.Chrome[7790]       matrix={
 20.08.11 16:53:21       [0x0-0xf60f6].com.google.Chrome[7790]           nan 
 nan nan nan
 20.08.11 16:53:21       [0x0-0xf60f6].com.google.Chrome[7790]           nan 
 nan nan nan
 20.08.11 16:53:21       [0x0-0xf60f6].com.google.Chrome[7790]           nan 
 nan nan nan
 20.08.11 16:53:21       [0x0-0xf60f6].com.google.Chrome[7790]           nan 
 nan nan nan
 20.08.11 16:53:21       [0x0-0xf60f6].com.google.Chrome[7790]   }
 ...


 Apparently, without this last line, before the update to v3.0.0, everything 
 worked well on Mac OSX (was commented).
 Now probably the lack of this line is the one that creates the problem ... it 
 is the only big difference between osx and windows implementation (that works 
 correctly!).
 Am I right?

 So I tried to set the line
 _MainCamera-setGraphicsContext(gc.get());
 but it crashes...
 I tried also with
 gc-osg::GraphicsContext::addCamera(_MainCamera);
 gc-_cameras.push_back(_MainCamera);
 but obviously the compiler complains about protections. ;)
 Any suggestion?
 Thanks in advance.
 G.
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Mac OSX - CGL graphic context and OpenSceneGraph 3.0.0

[Guido Lucci Baldassari]

Good evening to everyone
I'm not very skilled using osg itself, so maybe everything I'm going to say 
below is wrong.

Anyway:
I have a problem displaying osg content with my plugin, since I updated to OSG 
3.
Inside my extension, I create a CGLContextObj, then I pass it to osgviewer.
From the debugging messages (ativated at defcon 5 - DEBUG :) ) appears that 
the viewer is up and running, the model is loaded, but not displayed.
The problem apparently lies here (but maybe I'm wrong... anyway I'd like to fix 
this point)

...
_MainCamera(new osg::Camera),
...
...
...
osg::ref_ptrosg::GraphicsContext gc = (osg::GraphicsContext*) graficcontext;
_MainCamera-setGraphicsContext(gc.get());
...

The output that I got in the Console is:

...
20.08.11 16:53:21   [0x0-0xf60f6].com.google.Chrome[7790]   
CullVisitor::apply(Geode) detected NaN,
20.08.11 16:53:21   [0x0-0xf60f6].com.google.Chrome[7790]   depth=nan, 
center=(11412 18917 300),
20.08.11 16:53:21   [0x0-0xf60f6].com.google.Chrome[7790]   matrix={
20.08.11 16:53:21   [0x0-0xf60f6].com.google.Chrome[7790]   nan nan 
nan nan 
20.08.11 16:53:21   [0x0-0xf60f6].com.google.Chrome[7790]   nan nan 
nan nan 
20.08.11 16:53:21   [0x0-0xf60f6].com.google.Chrome[7790]   nan nan 
nan nan 
20.08.11 16:53:21   [0x0-0xf60f6].com.google.Chrome[7790]   nan nan 
nan nan 
20.08.11 16:53:21   [0x0-0xf60f6].com.google.Chrome[7790]   }
...


Apparently, without this last line, before the update to v3.0.0, everything 
worked well on Mac OSX (was commented).
Now probably the lack of this line is the one that creates the problem ... it 
is the only big difference between osx and windows implementation (that works 
correctly!).
Am I right?

So I tried to set the line
_MainCamera-setGraphicsContext(gc.get());
but it crashes...
I tried also with
gc-osg::GraphicsContext::addCamera(_MainCamera);
gc-_cameras.push_back(_MainCamera);
but obviously the compiler complains about protections. ;)
Any suggestion?
Thanks in advance.
G.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Mac OSX - CGL graphic context and OpenSceneGraph 3.0.0

[Guido Lucci Baldassari]

Good evening to everyone
I'm not very skilled using osg itself, so maybe everything I'm going to say 
below is wrong.

Anyway:
I have a problem displaying osg content with my plugin, since I updated to OSG 
3.
Inside my extension, I create a CGLContextObj, then I pass it to osgviewer.
From the debugging messages (ativated at defcon 5 - DEBUG :) ) appears that 
the viewer is up and running, the model is loaded, but not displayed.
The problem apparently lies here (but maybe I'm wrong... anyway I'd like to fix 
this point)

...
_MainCamera(new osg::Camera),
...
...
...
osg::ref_ptrosg::GraphicsContext gc = (osg::GraphicsContext*) graficcontext;
_MainCamera-setGraphicsContext(gc.get());
...

The output that I got in the Console is:

...
20.08.11 16:53:21   [0x0-0xf60f6].com.google.Chrome[7790]   
CullVisitor::apply(Geode) detected NaN,
20.08.11 16:53:21   [0x0-0xf60f6].com.google.Chrome[7790]   depth=nan, 
center=(11412 18917 300),
20.08.11 16:53:21   [0x0-0xf60f6].com.google.Chrome[7790]   matrix={
20.08.11 16:53:21   [0x0-0xf60f6].com.google.Chrome[7790]   nan nan 
nan nan 
20.08.11 16:53:21   [0x0-0xf60f6].com.google.Chrome[7790]   nan nan 
nan nan 
20.08.11 16:53:21   [0x0-0xf60f6].com.google.Chrome[7790]   nan nan 
nan nan 
20.08.11 16:53:21   [0x0-0xf60f6].com.google.Chrome[7790]   nan nan 
nan nan 
20.08.11 16:53:21   [0x0-0xf60f6].com.google.Chrome[7790]   }
...


Apparently, without this last line, before the update to v3.0.0, everything 
worked well on Mac OSX (was commented).
Now probably the lack of this line is the one that creates the problem ... it 
is the only big difference between osx and windows implementation (that works 
correctly!).
Am I right?

So I tried to set the line
_MainCamera-setGraphicsContext(gc.get());
but it crashes...
I tried also with
gc-osg::GraphicsContext::addCamera(_MainCamera);
gc-_cameras.push_back(_MainCamera);
but obviously the compiler complains about protections. ;)
Any suggestion?
Thanks in advance.
G.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Mac OSX | Problem loading curl-plugin inside OSG-web-plugin

[Guido Lucci Baldassari]

Thank you very much :)
Regards
G.
Il giorno 09.ago.2011, alle ore 11:56, Stephan Maximilian Huber ha scritto:

 Hi,
 
 Am 08.08.11 18:22, schrieb Guido Lucci Baldassari:
 Does anyone know how I can obtain the path of @loader_path at runtime
 (a better solution than getenv(PWD))? Thanks in advance
 
 you can try one of the NSBundle-methods:
 
   NSBundle* bundle = [NSBundle bundleForClass: [self class]];
   std::string plugin_path( [ [bundle builtInPlugInsPath] cString]);
 
 This will give you the path to the PlugIns-folder inside your bundle.
 
 cheers,
 Stephan
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Mac OSX | Problem loading curl-plugin inside OSG-web-plugin

[Stephan Maximilian Huber]

Hi,

Am 08.08.11 18:22, schrieb Guido Lucci Baldassari:
 Does anyone know how I can obtain the path of @loader_path at runtime
 (a better solution than getenv(PWD))? Thanks in advance

you can try one of the NSBundle-methods:

NSBundle* bundle = [NSBundle bundleForClass: [self class]];
std::string plugin_path( [ [bundle builtInPlugInsPath] cString]);

This will give you the path to the PlugIns-folder inside your bundle.

cheers,
Stephan
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Mac OSX | Problem loading curl-plugin inside OSG-web-plugin

[Guido Lucci Baldassari]

Hi
Solved!
I set manually osgDB::Registry::instance()-setLibraryFilePathList to the 
(absolute) path where plugins reside.
I don't know why, but seems that OSG_LIBRARY_PATH setted manually in terminal 
and also at runtime with putenv is overwritten somewhere (maybe in 
appendPlatformSpecificResourceFilePAths ?).
Thanks everyone for help :)

Another question:
Does anyone know how I can obtain the path of @loader_path at runtime (a better 
solution than getenv(PWD))?
Thanks in advance
Regards
G.

Il giorno 08.ago.2011, alle ore 01:08, Guido Lucci Baldassari ha scritto:

 Hi! Thank you for your prompt replay.
 
 I tried two different situations that return different error messages.
 
 The first one is when I keep the OpenSceneGraph original installation 
 directory in its correct place.
 In this case I get warning and errors about OpenThreads, which is the first 
 dynamic library that the plugin uses; this seems quite a normal error. The 
 OpenThreads library is the first that the plugin tries to use, referenced 
 from the plugin osgdb_osg.so, that belongs to the original installation 
 directory; I compiled frameworks with the @loader_path/../../../.. 
 installation path, so the system cannot find the correct library for the 
 plugin that is in this (wrong) location.
 
 Obviously I'm not interested in such behavior, therefore I renamed the 
 OpenSceneGraph original installation directory (after that the plugin bundle 
 was built), in order to hide other unwanted libraries to the system. In this 
 way the plugin looks for the requested libraries in the correct path, and 
 seems to load correctly, until it needs the curl plugin (the viewer is 
 loaded, but the main node is not retrieved). 
 
 The error message I get in console is: Warning: Could not find the .curl 
 plugin to read from server..
 
 The structure of my plugin is
 ...Plugin bundle
 ---   Contents
 ---   ---MacOS
 ---   ---lib
 ---   --- ---one-example-framework-dir-for-all
 ---   --- --- ---Version
 ---   --- --- --- ---80
 ---   --- --- --- --- ---the-framework-lib
 ---   --- ---osgPlugins-3.0.0
 ---   --- --- ---Version
 ---   --- --- --- ---80
 ---   --- --- --- --- ---allplugins (also osgdb_curl.so)
 
 As you can see I tried also adding two intermediate directories, in order to 
 make the length of the path compliant with the one of the frameworks
 
 the output I get from
 
 otool -L osgdb_curl.so
 
 is like
 
 @loader_path/../../../../lib/OpenThreads.framework/Versions/12/OpenThreads
 
 for every listed osg-lib.
 So I think that everything should be ok. But it isn't.
 
 Thanks in advance (again :) ) for any further suggestion.
 G.
 
 
 Il giorno 07.ago.2011, alle ore 18:50, Stephan Huber ha scritto:
 
 Hi,
 
 what error messages do you get? does osg find the plugin and fails when
 trying to open it? (you'll get some error-messages in the console.log,
 or if you run the plugin from inside xcode with safari as
 helper-application in the debug console.)
 
 Have you adjusted the @loader_paths for the osg-libs and for the
 curl-plugin too? It's not sufficient to do this for the bin only.
 
 What is the output of otool -L osgdb_curl.so ? All references to the
 osg-libs should begin with @loader_path.
 
 
 cheers,
 Stephan
 
 
 Am 07.08.11 17:53, schrieb Guido Lucci Baldassari:
 Good afternoon to everyone.
 I'm on the early deployment phase of our OSG-based web plugin. I'm trying 
 to embed all the needed libraries inside the package bundle, in order to 
 ease the distribution and the installation for the final user. 
 Unfortunately I encountered some problems with the curl plugin, that cannot 
 be found at runtime. I did many tries and looked through the web, searching 
 a solution, before posting here.
 
 My procedure is:
 
 -build osg with the correct @loader_path for the plugin to work
 -build the plugin
 -copy inside the plugin bundle all the needed libraries
 -fix the bin inside the plugn bundle with install_name_tool
 
 in this way everything loads correctly, except the curl plugin.
 
 My env is:
 
 OSG 3.0.0 (I use frameworks - I tried both: with  and without the 
 osg_plugin_search_install_dir_for_plugins)
 CMake 2.8.5
 Safari 5.1 (or Chrome Canary Build)
 Mac OSX 10.6.8
 
 Trying to understand where lies the problem:
 
 I used otool to check that everything was correct
 
 I tried setting explicitly OSG_LIBRARY_PATH to the absolute path, inside 
 the plugin source code.
 
 I tried finally with this method:
 
 I built OSG with INSTALL_PREFIX=the real path of the future plugin
 then I copied all libraries from a previous build on another machine with 
 the same specifications, except the plugins directory
 and everything worked, so I presume it's something hardcoded into the 
 plugin.
 
 This last method, maybe can be used (not sure if it will work when moving 
 or coping the whole final package on other machines - I'll check later), 
 but seems to be just a 

[osg-users] Mac OSX | Problem loading curl-plugin inside OSG-web-plugin

[Guido Lucci Baldassari]

Good afternoon to everyone.
I'm on the early deployment phase of our OSG-based web plugin. I'm trying to 
embed all the needed libraries inside the package bundle, in order to ease the 
distribution and the installation for the final user. Unfortunately I 
encountered some problems with the curl plugin, that cannot be found at 
runtime. I did many tries and looked through the web, searching a solution, 
before posting here.

My procedure is:

-build osg with the correct @loader_path for the plugin to work
-build the plugin
-copy inside the plugin bundle all the needed libraries
-fix the bin inside the plugn bundle with install_name_tool

in this way everything loads correctly, except the curl plugin.

My env is:

OSG 3.0.0 (I use frameworks - I tried both: with  and without the 
osg_plugin_search_install_dir_for_plugins)
CMake 2.8.5
Safari 5.1 (or Chrome Canary Build)
Mac OSX 10.6.8

Trying to understand where lies the problem:

I used otool to check that everything was correct

I tried setting explicitly OSG_LIBRARY_PATH to the absolute path, inside the 
plugin source code.

I tried finally with this method:

I built OSG with INSTALL_PREFIX=the real path of the future plugin
then I copied all libraries from a previous build on another machine with the 
same specifications, except the plugins directory
and everything worked, so I presume it's something hardcoded into the plugin.

This last method, maybe can be used (not sure if it will work when moving or 
coping the whole final package on other machines - I'll check later), but seems 
to be just a workaround. Before to proceed with the job, I'd like to ask here 
if anyone knows a better and clearer solution.
Thanks in advance
G.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Mac OSX | Problem loading curl-plugin inside OSG-web-plugin

[Stephan Huber]

Hi,

what error messages do you get? does osg find the plugin and fails when
trying to open it? (you'll get some error-messages in the console.log,
or if you run the plugin from inside xcode with safari as
helper-application in the debug console.)

Have you adjusted the @loader_paths for the osg-libs and for the
curl-plugin too? It's not sufficient to do this for the bin only.

What is the output of otool -L osgdb_curl.so ? All references to the
osg-libs should begin with @loader_path.


cheers,
Stephan


Am 07.08.11 17:53, schrieb Guido Lucci Baldassari:
 Good afternoon to everyone.
 I'm on the early deployment phase of our OSG-based web plugin. I'm trying to 
 embed all the needed libraries inside the package bundle, in order to ease 
 the distribution and the installation for the final user. Unfortunately I 
 encountered some problems with the curl plugin, that cannot be found at 
 runtime. I did many tries and looked through the web, searching a solution, 
 before posting here.
 
 My procedure is:
 
 -build osg with the correct @loader_path for the plugin to work
 -build the plugin
 -copy inside the plugin bundle all the needed libraries
 -fix the bin inside the plugn bundle with install_name_tool
 
 in this way everything loads correctly, except the curl plugin.
 
 My env is:
 
 OSG 3.0.0 (I use frameworks - I tried both: with  and without the 
 osg_plugin_search_install_dir_for_plugins)
 CMake 2.8.5
 Safari 5.1 (or Chrome Canary Build)
 Mac OSX 10.6.8
 
 Trying to understand where lies the problem:
 
 I used otool to check that everything was correct
 
 I tried setting explicitly OSG_LIBRARY_PATH to the absolute path, inside the 
 plugin source code.
 
 I tried finally with this method:
 
 I built OSG with INSTALL_PREFIX=the real path of the future plugin
 then I copied all libraries from a previous build on another machine with the 
 same specifications, except the plugins directory
 and everything worked, so I presume it's something hardcoded into the plugin.
 
 This last method, maybe can be used (not sure if it will work when moving or 
 coping the whole final package on other machines - I'll check later), but 
 seems to be just a workaround. Before to proceed with the job, I'd like to 
 ask here if anyone knows a better and clearer solution.
 Thanks in advance
 G.
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Mac OSX | Problem loading curl-plugin inside OSG-web-plugin

[Guido Lucci Baldassari]

Hi! Thank you for your prompt replay.

I tried two different situations that return different error messages.

The first one is when I keep the OpenSceneGraph original installation directory 
in its correct place.
In this case I get warning and errors about OpenThreads, which is the first 
dynamic library that the plugin uses; this seems quite a normal error. The 
OpenThreads library is the first that the plugin tries to use, referenced from 
the plugin osgdb_osg.so, that belongs to the original installation directory; I 
compiled frameworks with the @loader_path/../../../.. installation path, so the 
system cannot find the correct library for the plugin that is in this (wrong) 
location.

Obviously I'm not interested in such behavior, therefore I renamed the 
OpenSceneGraph original installation directory (after that the plugin bundle 
was built), in order to hide other unwanted libraries to the system. In this 
way the plugin looks for the requested libraries in the correct path, and seems 
to load correctly, until it needs the curl plugin (the viewer is loaded, but 
the main node is not retrieved). 

The error message I get in console is: Warning: Could not find the .curl 
plugin to read from server..

The structure of my plugin is
...Plugin bundle
--- Contents
--- ---MacOS
--- ---lib
--- --- ---one-example-framework-dir-for-all
--- --- --- ---Version
--- --- --- --- ---80
--- --- --- --- --- ---the-framework-lib
--- --- ---osgPlugins-3.0.0
--- --- --- ---Version
--- --- --- --- ---80
--- --- --- --- --- ---allplugins (also osgdb_curl.so)

As you can see I tried also adding two intermediate directories, in order to 
make the length of the path compliant with the one of the frameworks

the output I get from

otool -L osgdb_curl.so

is like

@loader_path/../../../../lib/OpenThreads.framework/Versions/12/OpenThreads

for every listed osg-lib.
So I think that everything should be ok. But it isn't.

Thanks in advance (again :) ) for any further suggestion.
G.


Il giorno 07.ago.2011, alle ore 18:50, Stephan Huber ha scritto:

 Hi,
 
 what error messages do you get? does osg find the plugin and fails when
 trying to open it? (you'll get some error-messages in the console.log,
 or if you run the plugin from inside xcode with safari as
 helper-application in the debug console.)
 
 Have you adjusted the @loader_paths for the osg-libs and for the
 curl-plugin too? It's not sufficient to do this for the bin only.
 
 What is the output of otool -L osgdb_curl.so ? All references to the
 osg-libs should begin with @loader_path.
 
 
 cheers,
 Stephan
 
 
 Am 07.08.11 17:53, schrieb Guido Lucci Baldassari:
 Good afternoon to everyone.
 I'm on the early deployment phase of our OSG-based web plugin. I'm trying to 
 embed all the needed libraries inside the package bundle, in order to ease 
 the distribution and the installation for the final user. Unfortunately I 
 encountered some problems with the curl plugin, that cannot be found at 
 runtime. I did many tries and looked through the web, searching a solution, 
 before posting here.
 
 My procedure is:
 
 -build osg with the correct @loader_path for the plugin to work
 -build the plugin
 -copy inside the plugin bundle all the needed libraries
 -fix the bin inside the plugn bundle with install_name_tool
 
 in this way everything loads correctly, except the curl plugin.
 
 My env is:
 
 OSG 3.0.0 (I use frameworks - I tried both: with  and without the 
 osg_plugin_search_install_dir_for_plugins)
 CMake 2.8.5
 Safari 5.1 (or Chrome Canary Build)
 Mac OSX 10.6.8
 
 Trying to understand where lies the problem:
 
 I used otool to check that everything was correct
 
 I tried setting explicitly OSG_LIBRARY_PATH to the absolute path, inside the 
 plugin source code.
 
 I tried finally with this method:
 
 I built OSG with INSTALL_PREFIX=the real path of the future plugin
 then I copied all libraries from a previous build on another machine with 
 the same specifications, except the plugins directory
 and everything worked, so I presume it's something hardcoded into the plugin.
 
 This last method, maybe can be used (not sure if it will work when moving or 
 coping the whole final package on other machines - I'll check later), but 
 seems to be just a workaround. Before to proceed with the job, I'd like to 
 ask here if anyone knows a better and clearer solution.
 Thanks in advance
 G.
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 

___
osg-users mailing list
osg-users@lists.openscenegraph.org

Re: [osg-users] Mac OS X windowing system related issue (maybe)

[Alessandro Terenzi]

Thank you Stephan,
I've tried by executing getWindowingSystemInterface() before opening
the settings window but unfortunately it didn't help.

On the other hand, I tried to call the viewer's realize() method
BEFORE opening the settings window and now it has focus, can be moved
and it works as expected...BUT, when the settings window is shown, I
also see the viewer's window (fullscreen and filled with white color)
just behind the settings window...when I close the latter, the viewer
shows my scene normally. This is close to the expected behavior except
for the viewer's window 'already' showing behind the settings window
(it should be shown only after the user closes the settings windows).

I guess that the camera settings window is created as a child of the
OSG application window, so it behaves normally only when the
application window's creation has completed...don't know.

Maybe I should perform only a part of what happens in the realize() method?

Regards.
Alessandro



On Tue, Jun 21, 2011 at 11:40 PM, Stephan Huber ratzf...@digitalmind.de wrote:
 Hi Alessandro,

 Am 21.06.11 22:35, schrieb Alessandro Terenzi:
 If this can help, when I built OSG I chose 'Carbon' as windowing system, I 
 built OSG as frameworks and I'm building my OSG application as a console 
 application. If I build my application as an app bundle (instead of a

 try creating the WindowSystemInterface via

 osg::GraphicsContext::getWindowingSystemInterface()

 before opening the settings-dialog. the WindowingSystemInterface does
 some fancy things, so that windows opened by a console-app work correctly.

 Perhaps that helps.

 cheers,
 Stephan
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Mac OS X windowing system related issue (maybe)

[Alessandro Terenzi]

Thank you Stephan,
I've tried by executing getWindowingSystemInterface() before opening
the settings window but unfortunately it didn't help.

On the other hand, I tried to call the viewer's realize() method
BEFORE opening the settings window and now it has focus, can be moved
and it works as expected...BUT, when the settings window is shown, I
also see the viewer's window (fullscreen and filled with white color)
just behind the settings window...when I close the latter, the viewer
shows my scene normally. This is close to the expected behavior except
for the viewer's window 'already' showing behind the settings window
(it should be shown only after the user closes the settings windows).

I guess that the camera settings window is created as a child of the
OSG application window, so it behaves normally only when the
application window's creation has completed...don't know.

Maybe I should perform only a part of what happens in the realize() method?

Regards.
Alessandro

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=40730#40730





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Mac OS X windowing system related issue (maybe)

[Alessandro Terenzi]

I finally managed to solve the issue: I called setUpViewAcrossAllScreens() 
before opening the settings window.

What does setUpViewAcrossAllScreens do?

Cheers.
Alessandro

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=40735#40735





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Mac OS X windowing system related issue (maybe)

[Alessandro Terenzi]

Hi,
it is not easy to explain the nature of the issue I'm experiencing anyway
I'll try.

I have an OSG application (on Mac OS X) that, on startup (no viewer realized
and not in the application loop yet), opens a video device in order to
display a webcam stream inside the application itself (the interface to the
video device is provided by a 3rd party lib)...everything is fine unless I
ask to display the camera settings window before actually starting the video
stream: in that case the correct behavior is that the OSG application waits
until the user makes his choices and close the settings window, when the
window is closed the OSG application continues setting up the scene and
finally enters the application loop and shows the viewer window.

When I used OSG 2.9.6 everything worked as described in both cases (with and
without showing the settings window), but when I switched to OSG 2.9.14,
2.9.16 or 3.0.0 if I choose to show the camera settings window then I cannot
move or grab focus on that window in any way (even though I still can click
its controls/buttons - for instance if I move another window on top of that
settings window, then I cannot bring to the foreground it anymore).

Unfortunately I cannot have too much control and information about that
camera settings window, I can just choose to show it or not when I open the
video stream..that window is not managed by my code and, as far as I know,
it is related to QUICKTIME in some way, I do not know much more and cannot
provide further details about this. Since my OSG application code didn't
change in any way and since it worked with OSG 2.9.6, I wonder if something
changed from the windowing system point of view on Mac OS X (I have no
problems on Windows by the way). By the way in the console I also get this
message:

GraphicsWindowCarbon::grabFocusIfPointerInWindow: not implemented

Don't know if this may be related to my issue...

If this can help, when I built OSG I chose 'Carbon' as windowing system, I
built OSG as frameworks and I'm building my OSG application as a console
application. If I build my application as an app bundle (instead of as a
console application) then it works even if I choose to show the settings
window.

I know that there is very little information about this issue, but I wonder
if any Mac OS X expert has a suggestion or can tell me what I should look
for in order to overcome this problem?

Thanks.
Alessandro
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Mac OS X windowing system related issue (maybe)

[Alessandro Terenzi]

Hi,
first of all I apologize if this is a duplicate post, I first tried to send a 
mail to the mailing list, but then I could not find it in this forum, so I'm 
trying again here by creating a new topic.

It is not easy to explain the nature of the issue I'm experiencing anyway I'll 
try.

I have an OSG application (on Mac OS X) that, on startup (no viewer realized 
and not in the application loop yet), opens a video device in order to display 
a webcam stream inside the application itself (the interface to the video 
device is provided by a 3rd party lib)...everything is fine unless I ask to 
display the camera settings window before actually starting the video stream: 
in that case the correct behavior is that the OSG application waits until the 
user makes his choices and close the settings window, when the window is closed 
the OSG application continues setting up the scene and finally enters the 
application loop and shows the viewer window. 

When I used OSG 2.9.6 everything worked as described in both cases (with and 
without showing the settings window), but when I switched to OSG 2.9.14, 2.9.16 
or 3.0.0 if I choose to show the camera settings window then I cannot move or 
grab focus on that window in any way (even though I still can click its 
controls/buttons - for instance if I move another window on top of that 
settings window, then I cannot bring to the foreground it anymore).

Unfortunately I cannot have too much control and information about that camera 
settings window, I can just choose to show it or not when I open the video 
stream..that window is not managed by my code and, as far as I know, it is 
related to QUICKTIME in some way, I do not know much more and cannot provide 
further details about this. Since my OSG application code didn't change in any 
way and since it worked with OSG 2.9.6, I wonder if something changed from the 
windowing system point of view on Mac OS X (I have no problems on Windows by 
the way). By the way in the console I also get this message: 

GraphicsWindowCarbon::grabFocusIfPointerInWindow: not implemented

Don't know if this may be related to my issue...

If this can help, when I built OSG I chose 'Carbon' as windowing system, I 
built OSG as frameworks and I'm building my OSG application as a console 
application. If I build my application as an app bundle (instead of as a 
console application) then it works even if I choose to show the settings window.

I know that there is very little information about this issue, but I wonder if 
any Mac OS X expert has a suggestion or can tell me what I should look for in 
order to overcome this problem?

Thanks.
Alessandro

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=40725#40725





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Mac OS X windowing system related issue (maybe)

[Stephan Huber]

Hi Alessandro,

Am 21.06.11 22:35, schrieb Alessandro Terenzi:
 If this can help, when I built OSG I chose 'Carbon' as windowing system, I 
 built OSG as frameworks and I'm building my OSG application as a console 
 application. If I build my application as an app bundle (instead of a

try creating the WindowSystemInterface via

osg::GraphicsContext::getWindowingSystemInterface()

before opening the settings-dialog. the WindowingSystemInterface does
some fancy things, so that windows opened by a console-app work correctly.

Perhaps that helps.

cheers,
Stephan
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Mac NVidia Point / clipping issue?

[Andy Skinner]

This will sound like a reach, and I can't easily make a simple case to show it. 
 But I'd like to know if this rings a bell with anyone.

We've seen geometry disappear when in the same scene as a point, on NVidia 7300 
on a Mac.

If I comment out the part of our code where we set the Point StateAttribute 
onto the StateSet, the geometry does not disappear.

If I remove the ClipNode from the scene, the geometry does not disappear.

Is there a way, either in OpenSceneGraph or in the NVidia driver, that 
specifying some of the things that the Point does (point size, attenutation, 
fade threshold) might affect clipping for other geometry?  Might point 
attenuation occupy some slot on the card for points that is used for a clip 
plane for other geometry?  (That's a wild guess.)  I don't know that it is the 
attenuation--just something specified by Point.  I've tried turning off the 
extensions related to points, but it didn't have an effect.

This seems like a long shot, but changing either of those situations does make 
the geometry appear again.

We are using OSG 2.8.3.  I've not yet been able to run one of the examples, or 
we'd try to show it in osgpoints.

thanks
andy

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] MAC OS-X advise with OSG

[Stephan Huber]

Hi,

Am 08.12.10 03:28, schrieb Ted Morris:
 Hi,
 
 I'm a complete newbie with Macs, but I am charged with the task of porting 
 some apps that ran on Win32/64 on the Mac.  In addition, the application lets 
 students create their own dlls that are then opened interactively to test 
 simulation solutions and visualize results. 
 
 I looked at some tutorials for bundling OSG apps with Xcode. My issue is that 
 after I downloaded Xcode it wants MAC OS X 10.6.4 (Snow Leopard) which this 
 (new! MacBook Pro i5) laptop even after the update is still 10.5!. I am 
 beginning to wonder if I am better off going with gnu tools instead?  Should 
 I worry about OSG apps and dylibs compiled/linked on the later OS not running 
 on earlier MAC OS -X versions?

Not sure why your laptop is still on 10.5. After Snow Leopard debuted,
all new laptops were delivered with Snow Leopard aka 10.6.

There should be a xcode-installer on your system-cd. You can download
Xcode 3.1 (which is compatible with Leopard) from
http://connect.apple.com/cgi-bin/WebObjects/MemberSite.woa/wo/7.1.17.2.1.3.3.1.0.1.1.0.3.3.3.3.1
(you'll need a developer account on developer.apple.com)

There's no problem to built apps on Snow Leopard for older systems, just
change the settings in your project-settings file. osg doesn't support
10.4 or older systems.

HTH,
Stephan
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] MAC OS-X advise with OSG

[Robert Osfield]

Hi Ted,

When I use OSX I use standard gnu tools - make and it works great, and
is friendly to working in an ssh shell for remote dev work.  I have
dabbled in XCode a few years ago but found myself far less productive,
but then it's been well over a decade since I was a fan of IDE's on
any platform.

If you are familiar with gnu tools or have a need to automate the tool
chain then, then I would recommend using the combination of cmake for
generating Makefile/project files and use make under unices.  Under
Windows you can still use the same cmake scripts to generate project
files that you'll need.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] MAC OS-X advise with OSG

[Ted Morris]

Hi,

I'm a complete newbie with Macs, but I am charged with the task of porting some 
apps that ran on Win32/64 on the Mac.  In addition, the application lets 
students create their own dlls that are then opened interactively to test 
simulation solutions and visualize results. 

I looked at some tutorials for bundling OSG apps with Xcode. My issue is that 
after I downloaded Xcode it wants MAC OS X 10.6.4 (Snow Leopard) which this 
(new! MacBook Pro i5) laptop even after the update is still 10.5!. I am 
beginning to wonder if I am better off going with gnu tools instead?  Should I 
worry about OSG apps and dylibs compiled/linked on the later OS not running on 
earlier MAC OS -X versions?


Thanks for any advice in advance.


Ted

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=34598#34598





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Mac OSX and osgversion

[Daryl Lee]

Thanks for the feedback.  I think I'll go ahead with the latest and do a full 
build from source.  I like XCode, but I feel more in control with a traditional 
makefile approach to developing.  I'm sure I'll be back with more questions as 
I stumble through this learning experience!

Cheers,
Daryl

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=31834#31834





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Mac OSX and osgversion

[Daryl Lee]

Hi,

I just began familiarizing myself with OSG, and immediately ran into an 
installation problem.  I downloaded the OSG version 2.8.0 Mac OSX installer, 
since it was the most recent version with a Mac installer.  It seemed to 
install okay, and the two-pyramid starter project worked perfectly in XCode.  
But at the command line the programs osgversion, osglogo, and osgviewer 
(sections 1.2.5 and 1.3 of the Quick Start Guide) were all reported as not 
found.   I also ran find / -name osgversion and they failed to show up there, 
as well.  So are these three commands not implemented for the Mac?  If I 
rebuild a current version from source, will they be there?  (I'm not afraid to 
do that if it offers promise for benefit.)

Thank you!

Cheers,
Daryl

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=31797#31797





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Mac Serializer Compile Error

[Martins Innus]

I have attempted to add a ADD_GLINT_SERIALIZER for the cases where I got 
errors.  I did as Robert suggested and just blindly cast to int.  
Figured I'd post here first instead of to submissions since I have no 
idea if this will break other builds, but it allows the serializers to 
compile for me under the 10.4 SDK.


Martins

On 3/18/10 4:28 AM, Robert Osfield wrote:

HI Matrin  Wang Rui

On Thu, Mar 18, 2010 at 3:15 AM, Wang Ruiwangra...@gmail.com  wrote:
   

Hi Martins,

I have no experience in Mac. But it seems that type definition of
GLint changes to some other types in your system. In most other cases,
we have:

typedef int GLint;

in the gl.h header. And an ADD_INT_SERIALIZER is workable with it.

Maybe we should have more tests on 64bit systems and try to find out
if an independent ADD_GLINT_SERIALIZER was required to keep compatible
on different platforms.
 

An ADD_GLINT_SERIALIZER may well be required.  We'd need to
static_cast the GLint to int for portability of the data format.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
   


#include osg/LineStipple
#include osgDB/ObjectWrapper
#include osgDB/InputStream
#include osgDB/OutputStream

REGISTER_OBJECT_WRAPPER( LineStipple,
 new osg::LineStipple,
 osg::LineStipple,
 osg::Object osg::StateAttribute osg::LineStipple )
{
ADD_GLINT_SERIALIZER( Factor, 1 );  // _factor
ADD_HEXSHORT_SERIALIZER( Pattern, 0x );  // _pattern
}
/* -*-c++-*- OpenSceneGraph - Copyright (C) 1998-2010 Robert Osfield
 *
 * This library is open source and may be redistributed and/or modified under
 * the terms of the OpenSceneGraph Public License (OSGPL) version 0.0 or
 * (at your option) any later version.  The full license is in LICENSE file
 * included with this distribution, and on the openscenegraph.org website.
 *
 * This library is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * OpenSceneGraph Public License for more details.
*/
// Written by Wang Rui, (C) 2010

#ifndef OSGDB__SERIALIZER
#define OSGDB__SERIALIZER

#include osg/ref_ptr
#include osg/Notify
#include osg/Object
#include osgDB/InputStream
#include osgDB/OutputStream
#include string
#include sstream


namespace osgDB
{

#ifndef OBJECT_CAST
#define OBJECT_CAST static_cast
#endif

class IntLookup
{
public:
typedef int Value;
typedef std::mapstd::string, Value StringToValue;
typedef std::mapValue, std::string ValueToString;

IntLookup() {}
unsigned int size() const { return _stringToValue.size(); }

void add( const char* str, Value value )
{
if ( _valueToString.find(value)!=_valueToString.end() )
{
osg::notify(osg::WARN)  Duplicate enum value   value
 with old string:   
_valueToString[value]
 and new string:   str  std::endl;
}
_valueToString[value] = str;
_stringToValue[str] = value;
}

Value getValue( const char* str )
{
StringToValue::iterator itr = _stringToValue.find(str);
if ( itr==_stringToValue.end() )
{
Value value;
std::stringstream stream;
stream  str; stream  value;
_stringToValue[str] = value;
return value;
}
return itr-second;
}

const std::string getString( Value value )
{
ValueToString::iterator itr = _valueToString.find(value);
if ( itr==_valueToString.end() )
{
std::string str;
std::stringstream stream;
stream  value; stream  str;
_valueToString[value] = str;
return _valueToString[value];
}
return itr-second;
}

protected:
StringToValue _stringToValue;
ValueToString _valueToString;
};

class UserLookupTableProxy
{
public:
typedef void (*AddValueFunc)( IntLookup* lookup );
UserLookupTableProxy( AddValueFunc func ) { if ( func ) (*func)(_lookup); }

IntLookup _lookup;
};

#define BEGIN_USER_TABLE(NAME, CLASS) \
static void add_user_value_func_##NAME(osgDB::IntLookup*); \
static osgDB::UserLookupTableProxy 
s_user_lookup_table_##NAME(add_user_value_func_##NAME); \
static void add_user_value_func_##NAME(osgDB::IntLookup* lookup) { typedef 
CLASS MyClass
#define ADD_USER_VALUE(VALUE) lookup-add(#VALUE, MyClass::VALUE)
#define END_USER_TABLE() }

#define USER_READ_FUNC(NAME, FUNCNAME) \
static int FUNCNAME(osgDB::InputStream is) { \
int value; if (is.isBinary()) is  value; \
else { std::string str; is  str; \
value = (s_user_lookup_table_##NAME)._lookup.getValue(str.c_str()); } 

Re: [osg-users] Mac Serializer Compile Error

[Robert Osfield]

HI Matrin  Wang Rui

On Thu, Mar 18, 2010 at 3:15 AM, Wang Rui wangra...@gmail.com wrote:
 Hi Martins,

 I have no experience in Mac. But it seems that type definition of
 GLint changes to some other types in your system. In most other cases,
 we have:

 typedef int GLint;

 in the gl.h header. And an ADD_INT_SERIALIZER is workable with it.

 Maybe we should have more tests on 64bit systems and try to find out
 if an independent ADD_GLINT_SERIALIZER was required to keep compatible
 on different platforms.

An ADD_GLINT_SERIALIZER may well be required.  We'd need to
static_cast the GLint to int for portability of the data format.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Mac Serializer Compile Error

[Martins Innus]

Wang Rui,

Looking at gl.h under the different SDK's here are the typedefs:

10.4 : long
10.5 : int
10.6 : int

So I'm not sure what that means in terms of being able to support 
different types with the serializer.


Martins

On 3/17/2010 11:15 PM, Wang Rui wrote:

Hi Martins,

I have no experience in Mac. But it seems that type definition of
GLint changes to some other types in your system. In most other cases,
we have:

typedef int GLint;

in the gl.h header. And an ADD_INT_SERIALIZER is workable with it.

Maybe we should have more tests on 64bit systems and try to find out
if an independent ADD_GLINT_SERIALIZER was required to keep compatible
on different platforms.

Wang Rui


2010/3/18 Martins Innusmin...@ccr.buffalo.edu:

Hello,

I get the following 2 errors when trying to compile the latest svn on a Mac
running 10.6 but using the 10.4 SDK.  This compiles fine using the 10.6 SDK
with gcc-4.2, but since the 10.4 SDK requires gcc-4.0, I assume its a
compiler quirk.  Any suggestions on how to get around it?

/util/src/osgsvn/src/osgWrappers/serializers/osg/LineStipple.cpp: In
function 'void wrapper_propfunc_LineStipple(osgDB::ObjectWrapper*)':
/util/src/osgsvn/src/osgWrappers/serializers/osg/LineStipple.cpp:11: error:
no matching function for call to 'osgDB::PropByValSerializerMyClass,
int::PropByValSerializer(const char [7], int, GLint
(osg::LineStipple::*)()const, void (osg::LineStipple::*)(GLint))'
/util/src/osgsvn/include/osgDB/Serializer:205: note: candidates are:
osgDB::PropByValSerializerC, P::PropByValSerializer(const char*, P, P
(C::*)()const, void (C::*)(P), bool) [with C = MyClass, P = int]
/util/src/osgsvn/include/osgDB/Serializer:199: note:
osgDB::PropByValSerializerMyClass, int::PropByValSerializer(const
osgDB::PropByValSerializerMyClass, int)

/util/src/osgsvn/src/osgWrappers/serializers/osg/Texture.cpp: In function
'void wrapper_propfunc_Texture(osgDB::ObjectWrapper*)':
/util/src/osgsvn/src/osgWrappers/serializers/osg/Texture.cpp:89: error: no
matching function for call to 'osgDB::PropByValSerializerMyClass,
int::PropByValSerializer(const char [12], int, GLint
(osg::Texture::*)()const, void (osg::Texture::*)(GLint))'
/util/src/osgsvn/include/osgDB/Serializer:205: note: candidates are:
osgDB::PropByValSerializerC, P::PropByValSerializer(const char*, P, P
(C::*)()const, void (C::*)(P), bool) [with C = MyClass, P = int]
/util/src/osgsvn/include/osgDB/Serializer:199: note:
osgDB::PropByValSerializerMyClass, int::PropByValSerializer(const
osgDB::PropByValSerializerMyClass, int)


Thanks

Martins
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Mac Serializer Compile Error

[Martins Innus]

Hello,

I get the following 2 errors when trying to compile the latest svn on a 
Mac running 10.6 but using the 10.4 SDK.  This compiles fine using the 
10.6 SDK with gcc-4.2, but since the 10.4 SDK requires gcc-4.0, I assume 
its a compiler quirk.  Any suggestions on how to get around it?


/util/src/osgsvn/src/osgWrappers/serializers/osg/LineStipple.cpp: In 
function 'void wrapper_propfunc_LineStipple(osgDB::ObjectWrapper*)':
/util/src/osgsvn/src/osgWrappers/serializers/osg/LineStipple.cpp:11: 
error: no matching function for call to 
'osgDB::PropByValSerializerMyClass, int::PropByValSerializer(const 
char [7], int, GLint (osg::LineStipple::*)()const, void 
(osg::LineStipple::*)(GLint))'
/util/src/osgsvn/include/osgDB/Serializer:205: note: candidates are: 
osgDB::PropByValSerializerC, P::PropByValSerializer(const char*, P, P 
(C::*)()const, void (C::*)(P), bool) [with C = MyClass, P = int]
/util/src/osgsvn/include/osgDB/Serializer:199: note: 
osgDB::PropByValSerializerMyClass, int::PropByValSerializer(const 
osgDB::PropByValSerializerMyClass, int)


/util/src/osgsvn/src/osgWrappers/serializers/osg/Texture.cpp: In 
function 'void wrapper_propfunc_Texture(osgDB::ObjectWrapper*)':
/util/src/osgsvn/src/osgWrappers/serializers/osg/Texture.cpp:89: error: 
no matching function for call to 'osgDB::PropByValSerializerMyClass, 
int::PropByValSerializer(const char [12], int, GLint 
(osg::Texture::*)()const, void (osg::Texture::*)(GLint))'
/util/src/osgsvn/include/osgDB/Serializer:205: note: candidates are: 
osgDB::PropByValSerializerC, P::PropByValSerializer(const char*, P, P 
(C::*)()const, void (C::*)(P), bool) [with C = MyClass, P = int]
/util/src/osgsvn/include/osgDB/Serializer:199: note: 
osgDB::PropByValSerializerMyClass, int::PropByValSerializer(const 
osgDB::PropByValSerializerMyClass, int)



Thanks

Martins
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Mac Serializer Compile Error

[Wang Rui]

Hi Martins,

I have no experience in Mac. But it seems that type definition of
GLint changes to some other types in your system. In most other cases,
we have:

typedef int GLint;

in the gl.h header. And an ADD_INT_SERIALIZER is workable with it.

Maybe we should have more tests on 64bit systems and try to find out
if an independent ADD_GLINT_SERIALIZER was required to keep compatible
on different platforms.

Wang Rui


2010/3/18 Martins Innus min...@ccr.buffalo.edu:
 Hello,

 I get the following 2 errors when trying to compile the latest svn on a Mac
 running 10.6 but using the 10.4 SDK.  This compiles fine using the 10.6 SDK
 with gcc-4.2, but since the 10.4 SDK requires gcc-4.0, I assume its a
 compiler quirk.  Any suggestions on how to get around it?

 /util/src/osgsvn/src/osgWrappers/serializers/osg/LineStipple.cpp: In
 function 'void wrapper_propfunc_LineStipple(osgDB::ObjectWrapper*)':
 /util/src/osgsvn/src/osgWrappers/serializers/osg/LineStipple.cpp:11: error:
 no matching function for call to 'osgDB::PropByValSerializerMyClass,
 int::PropByValSerializer(const char [7], int, GLint
 (osg::LineStipple::*)()const, void (osg::LineStipple::*)(GLint))'
 /util/src/osgsvn/include/osgDB/Serializer:205: note: candidates are:
 osgDB::PropByValSerializerC, P::PropByValSerializer(const char*, P, P
 (C::*)()const, void (C::*)(P), bool) [with C = MyClass, P = int]
 /util/src/osgsvn/include/osgDB/Serializer:199: note:
 osgDB::PropByValSerializerMyClass, int::PropByValSerializer(const
 osgDB::PropByValSerializerMyClass, int)

 /util/src/osgsvn/src/osgWrappers/serializers/osg/Texture.cpp: In function
 'void wrapper_propfunc_Texture(osgDB::ObjectWrapper*)':
 /util/src/osgsvn/src/osgWrappers/serializers/osg/Texture.cpp:89: error: no
 matching function for call to 'osgDB::PropByValSerializerMyClass,
 int::PropByValSerializer(const char [12], int, GLint
 (osg::Texture::*)()const, void (osg::Texture::*)(GLint))'
 /util/src/osgsvn/include/osgDB/Serializer:205: note: candidates are:
 osgDB::PropByValSerializerC, P::PropByValSerializer(const char*, P, P
 (C::*)()const, void (C::*)(P), bool) [with C = MyClass, P = int]
 /util/src/osgsvn/include/osgDB/Serializer:199: note:
 osgDB::PropByValSerializerMyClass, int::PropByValSerializer(const
 osgDB::PropByValSerializerMyClass, int)


 Thanks

 Martins
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Mac OS X Snow Leopard

[Stephan Huber]

Massimo Di Stefano schrieb:
 Hi 
 
 i'm tring to build osg trunk on mac osx snow leopard.
 
 i tried to apply the change to the file :

What version of Cmake did you use to generate the makefiles / xcode
projects? I am getting the same error when using CMake 2.8, switching
back to 2.6.4 (be sure to clear the cmake cache) everything compiles
fine without any local patches.

cheers,
Stephan


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Mac OS X Snow Leopard

[Massimo Di Stefano]

I used cmake 2.8 to try the build.

then i also tried the Xcode that comes with the osg source code, but it fails 
too.

i'll try to install cmake 2.6.4 and see if it works.

- have you any hintsabout the provedure to generate xcode project using cmake ?

thanks!

Massimo.

Il giorno 08/dic/2009, alle ore 09.17, Stephan Huber ha scritto:

 Massimo Di Stefano schrieb:
 Hi 
 
 i'm tring to build osg trunk on mac osx snow leopard.
 
 i tried to apply the change to the file :
 
 What version of Cmake did you use to generate the makefiles / xcode
 projects? I am getting the same error when using CMake 2.8, switching
 back to 2.6.4 (be sure to clear the cmake cache) everything compiles
 fine without any local patches.
 
 cheers,
 Stephan
 
 
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Mac OS X Snow Leopard

[Stephan Maximilian Huber]

Hi Massimo,

Massimo Di Stefano schrieb:

 then i also tried the Xcode that comes with the osg source code, but it fails 
 too

can you provide the build log? So we can fix the xcode-projects. Btw
they work for me.

 i'll try to install cmake 2.6.4 and see if it works.
 
 - have you any hintsabout the provedure to generate xcode project using cmake 
 ?

ccmake -G Xcode or use the provided gui.

cheers,
Stephan
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Mac OS X Snow Leopard

[Massimo Di Stefano]

Hi,

tring using cmake-2.6.4 (last osg trunk - revision : 10859)

i restored the opentrhead files and used :

cd trunk/
mkdir build
cd build
ccmake ..

the build now goes ahead but fails at quicktime plug-in this the log :

http://www.geofemengineering.it/data/osg-r10859_osx10-6_cmake.txt


i'll try now the xcode project that comes with the source code, so i can save 
and post its log.

thanks to help me!

Massimo.

Il giorno 08/dic/2009, alle ore 11.11, Stephan Maximilian Huber ha scritto:

 Hi Massimo,
 
 Massimo Di Stefano schrieb:
 
 then i also tried the Xcode that comes with the osg source code, but it 
 fails too
 
 can you provide the build log? So we can fix the xcode-projects. Btw
 they work for me.
 
 i'll try to install cmake 2.6.4 and see if it works.
 
 - have you any hintsabout the provedure to generate xcode project using 
 cmake ?
 
 ccmake -G Xcode or use the provided gui.
 
 cheers,
 Stephan
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Mac OS X Snow Leopard

[Massimo Di Stefano]

Tried using Xcode with this configuration :

base sdk : Current Mac Os
build active architecture only X (checked)

use base sdk
Development 64bit cocoa

Log :

http://www.geofemengineering.it/data/osg-r10859_osx10-6_Xcode.txt



Il giorno 08/dic/2009, alle ore 11.28, Massimo Di Stefano ha scritto:

 Hi,
 
 tring using cmake-2.6.4 (last osg trunk - revision : 10859)
 
 i restored the opentrhead files and used :
 
 cd trunk/
 mkdir build
 cd build
 ccmake ..
 
 the build now goes ahead but fails at quicktime plug-in this the log :
 
 http://www.geofemengineering.it/data/osg-r10859_osx10-6_cmake.txt
 
 
 i'll try now the xcode project that comes with the source code, so i can save 
 and post its log.
 
 thanks to help me!
 
 Massimo.
 
 Il giorno 08/dic/2009, alle ore 11.11, Stephan Maximilian Huber ha scritto:
 
 Hi Massimo,
 
 Massimo Di Stefano schrieb:
 
 then i also tried the Xcode that comes with the osg source code, but it 
 fails too
 
 can you provide the build log? So we can fix the xcode-projects. Btw
 they work for me.
 
 i'll try to install cmake 2.6.4 and see if it works.
 
 - have you any hintsabout the provedure to generate xcode project using 
 cmake ?
 
 ccmake -G Xcode or use the provided gui.
 
 cheers,
 Stephan
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Mac OS X Snow Leopard

[Stephan Maximilian Huber]

Hi,

Massimo Di Stefano schrieb:
 Hi,
 
 tring using cmake-2.6.4 (last osg trunk - revision : 10859)
 
 i restored the opentrhead files and used :
 
 cd trunk/
 mkdir build
 cd build
 ccmake ..
 
 the build now goes ahead but fails at quicktime plug-in this the log :
 
 http://www.geofemengineering.it/data/osg-r10859_osx10-6_cmake.txt

Any chance that you compile for 64bit? Then you'll have to disable the
quicktime-plugin and use the imageio-plugin, Quicktime is only available
for 32bit.

Set OSG_DEFAULT_IMAGE_PLUGIN_FOR_OSX settings in CMAKE to imageio

cheers,
Stephan


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Mac OS X Snow Leopard

[Massimo Di Stefano]

Hi,

i applied the change to cmake settings :

 OSG_DEFAULT_IMAGE_PLUGIN_FOR_OSX = imageio

but the error persists, so i make a copy of the quicktime directory and i 
removed all the files from the original on :

cp -r trunk/src/osgPlugins/quicktime runk/src/osgPlugins/quicktime_
cd trunk/src/osgPlugins/quicktime
rm -rf *

httpp://www.geofemengineering.it/data/osg_osgQtBrowser_error.txt
httpp://www.geofemengineering.it/data/osg_osgviewerQT_error.txt
httpp://www.geofemengineering.it/data/osg_osgviewerQtWidget_error.txt
httpp://www.geofemengineering.it/data/osg_wx_error.txt


thi gived me a succesfull build.

then, i reconfigured osg enablig the examples, 
here i had errors for Wx and Qt :

httpp://www.geofemengineering.it/data/osg_osgQtBrowser_error.txt
httpp://www.geofemengineering.it/data/osg_osgviewerQT_error.txt
httpp://www.geofemengineering.it/data/osg_osgviewerQtWidget_error.txt
httpp://www.geofemengineering.it/data/osg_wx_error.txt

appling the same hack 

cp -r plug-in_dir plug-in_dir_
cd tplug-in_dir
rm -rf *

i succesful build the other examles

Thanks a lot to helped me!
any suggestion to have Qt example running ?

i'm intersted in the Qt example,
i have a source build for Qt-4.6 -cocoa (so it shoul'd be 64 bit as osg)
my target is to run osg from python + pyqt.
btw if osg-python will not build i'll try to use Qt - c++


tell me if i can provide any sort of logs
(i build osg using Debug enabled and wrapper set to ON)


Ciao,

Massimo.

Il giorno 08/dic/2009, alle ore 13.15, Stephan Maximilian Huber ha scritto:

 Hi,
 
 Massimo Di Stefano schrieb:
 Hi,
 
 tring using cmake-2.6.4 (last osg trunk - revision : 10859)
 
 i restored the opentrhead files and used :
 
 cd trunk/
 mkdir build
 cd build
 ccmake ..
 
 the build now goes ahead but fails at quicktime plug-in this the log :
 
 http://www.geofemengineering.it/data/osg-r10859_osx10-6_cmake.txt
 
 Any chance that you compile for 64bit? Then you'll have to disable the
 quicktime-plugin and use the imageio-plugin, Quicktime is only available
 for 32bit.
 
 Set OSG_DEFAULT_IMAGE_PLUGIN_FOR_OSX settings in CMAKE to imageio
 
 cheers,
 Stephan
 
 
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Mac OS X Snow Leopard

[Robert Osfield]

Hi Massimo,

On Tue, Dec 8, 2009 at 3:38 PM, Massimo Di Stefano
massimodisa...@yahoo.it wrote:
 Hi,

 i applied the change to cmake settings :

 OSG_DEFAULT_IMAGE_PLUGIN_FOR_OSX = imageio

 but the error persists, so i make a copy of the quicktime directory and i 
 removed all the files from the original on :

After setting the variable using ccmake you should then press 'c' and
'g' to configure and then generate the finale makefiles/Xcode
projects.  If you miss these steps out then you'll still see the
quicktime plugin building.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Mac OS X Snow Leopard

[Stephan Maximilian Huber]

Massimo Di Stefano schrieb:
 i applied the change to cmake settings :
 
 OSG_DEFAULT_IMAGE_PLUGIN_FOR_OSX = imageio
 
 but the error persists, so i make a copy of the quicktime directory and i 
 removed all the files from the original on :
 
 cp -r trunk/src/osgPlugins/quicktime runk/src/osgPlugins/quicktime_
 cd trunk/src/osgPlugins/quicktime
 rm -rf *
 
 httpp://www.geofemengineering.it/data/osg_osgQtBrowser_error.txt
 httpp://www.geofemengineering.it/data/osg_osgviewerQT_error.txt
 httpp://www.geofemengineering.it/data/osg_osgviewerQtWidget_error.txt
 httpp://www.geofemengineering.it/data/osg_wx_error.txt
 
 
 thi gived me a succesfull build.
 
 then, i reconfigured osg enablig the examples, 
 here i had errors for Wx and Qt :
 
 httpp://www.geofemengineering.it/data/osg_osgQtBrowser_error.txt
 httpp://www.geofemengineering.it/data/osg_osgviewerQT_error.txt
 httpp://www.geofemengineering.it/data/osg_osgviewerQtWidget_error.txt
 httpp://www.geofemengineering.it/data/osg_wx_error.txt
 
 appling the same hack 
 
 cp -r plug-in_dir plug-in_dir_
 cd tplug-in_dir
 rm -rf *
 
 i succesful build the other examles
 
 Thanks a lot to helped me!
 any suggestion to have Qt example running ?

I have no experience with qt, but looking at the logs it looks like Qt
needs the GraphicsWindowCarbon-implementation, which is not available
for 64bit, you'll have to set OSG_WINDOWING_SYSTEM to Carbon and make
sure you are not building against 64bit (check CMAKE_OSX_ARCHITECTURES)

HTH,
Stephan


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Mac OS X Snow Leopard

[Massimo Di Stefano]

Hi Ronert,

sure i did it

cd trunk
mkdir build
ccmake ..

i changed the configuration 
then pressed c to configure
an g to generate the makefile

in the file CMakeCache.txt i have : 

//standard image plugin for os x, options are quicktime, imageio
OSG_DEFAULT_IMAGE_PLUGIN_FOR_OSX:STRING=imageio

but the make continue to try to buld quicktime.

Massimo.

Il giorno 08/dic/2009, alle ore 16.41, Robert Osfield ha scritto:

 Hi Massimo,
 
 On Tue, Dec 8, 2009 at 3:38 PM, Massimo Di Stefano
 massimodisa...@yahoo.it wrote:
 Hi,
 
 i applied the change to cmake settings :
 
 OSG_DEFAULT_IMAGE_PLUGIN_FOR_OSX = imageio
 
 but the error persists, so i make a copy of the quicktime directory and i 
 removed all the files from the original on :
 
 After setting the variable using ccmake you should then press 'c' and
 'g' to configure and then generate the finale makefiles/Xcode
 projects.  If you miss these steps out then you'll still see the
 quicktime plugin building.
 
 Robert.
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Mac OS X Snow Leopard

[Robert Osfield]

Hi Massimo,

I've now spotted that you problems were no longer about the quicktime
plugin... but Qt and WxWindows.  As Stephan mentions these examples
will be using parts of the OSG/OSX that aren't supported under 64bit
build.

It should be possible to modify the Qt examples to compile under 64bit
by avoiding the use of GraphicsWIndowCarbon.  I don't know if
GrahicsWindowCocoa can be successfully used in it's place but you
could try.  The other route it not use the GraphicsWindow inheritance
functionality, and instead use GraphicsWindow embedded or the full
GraphicsWindow subclass  functionality.

Robert.

On Tue, Dec 8, 2009 at 4:06 PM, Massimo Di Stefano
massimodisa...@yahoo.it wrote:
 Hi Ronert,

 sure i did it

 cd trunk
 mkdir build
 ccmake ..

 i changed the configuration
 then pressed c to configure
 an g to generate the makefile

 in the file CMakeCache.txt i have :

 //standard image plugin for os x, options are quicktime, imageio
 OSG_DEFAULT_IMAGE_PLUGIN_FOR_OSX:STRING=imageio

 but the make continue to try to buld quicktime.

 Massimo.

 Il giorno 08/dic/2009, alle ore 16.41, Robert Osfield ha scritto:

 Hi Massimo,

 On Tue, Dec 8, 2009 at 3:38 PM, Massimo Di Stefano
 massimodisa...@yahoo.it wrote:
 Hi,

 i applied the change to cmake settings :

 OSG_DEFAULT_IMAGE_PLUGIN_FOR_OSX = imageio

 but the error persists, so i make a copy of the quicktime directory and i 
 removed all the files from the original on :

 After setting the variable using ccmake you should then press 'c' and
 'g' to configure and then generate the finale makefiles/Xcode
 projects.  If you miss these steps out then you'll still see the
 quicktime plugin building.

 Robert.
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Mac OS X Snow Leopard

[Massimo Di Stefano]

hi,

tring on QOSGWidget example,

i ried to replace : 

#include osgViewer/api/Carbon/GraphicsWindowCarbon

with :

#include osgViewer/api/Cocoa/GraphicsWindowCocoa



but i get : 


[ 99%] Building CXX object 
examples/osgviewerQtWidget/CMakeFiles/example_osgviewerQtWidget.dir/QOSGWidget.cpp.o
/Users/sasha/source/trunk/examples/osgviewerQtWidget/QOSGWidget.cpp: In member 
function ‘void QOSGWidget::createContext(QWidget*)’:
/Users/sasha/source/trunk/examples/osgviewerQtWidget/QOSGWidget.cpp:156: error: 
‘HIViewRef’ was not declared in this scope
/Users/sasha/source/trunk/examples/osgviewerQtWidget/QOSGWidget.cpp:156: error: 
‘HIViewGetWindow’ was not declared in this scope
make[2]: *** 
[examples/osgviewerQtWidget/CMakeFiles/example_osgviewerQtWidget.dir/QOSGWidget.cpp.o]
 Error 1
make[1]: *** 
[examples/osgviewerQtWidget/CMakeFiles/example_osgviewerQtWidget.dir/all] Error 
2




the original file :

http://www.geofemengineering.it/data/QOSGWidget.cpp

but ... i tried also using a 32 build for osg (architecture i386, carbon)

this the error :

Scanning dependencies of target example_osgviewerQT
[ 98%] Building CXX object 
examples/osgviewerQT/CMakeFiles/example_osgviewerQT.dir/QOSGWidget.cpp.o
/Users/sasha/source/trunk/examples/osgviewerQT/QOSGWidget.cpp:61: error: 
‘WindowRef’ does not name a type
/Users/sasha/source/trunk/examples/osgviewerQT/QOSGWidget.cpp:62: error: 
‘osgViewer::GraphicsWindowCarbon’ has not been declared
/Users/sasha/source/trunk/examples/osgviewerQT/QOSGWidget.cpp:62: error: 
expected initializer before ‘WindowData’
/Users/sasha/source/trunk/examples/osgviewerQT/QOSGWidget.cpp: In member 
function ‘void QOSGWidget::createContext()’:
/Users/sasha/source/trunk/examples/osgviewerQT/QOSGWidget.cpp:163: error: 
expected type-specifier before ‘WindowData’
/Users/sasha/source/trunk/examples/osgviewerQT/QOSGWidget.cpp:163: error: no 
match for ‘operator=’ in ‘traits. osg::ref_ptrT::operator- [with T = 
osg::GraphicsContext::Traits]()-osg::GraphicsContext::Traits::inheritedWindowData
 = (int*)operator new(4u)’
/Users/sasha/source/trunk/include/osg/ref_ptr:35: note: candidates are: 
osg::ref_ptrT osg::ref_ptrT::operator=(const osg::ref_ptrT) [with T = 
osg::Referenced]
/Users/sasha/source/trunk/include/osg/ref_ptr:47: note: 
osg::ref_ptrT osg::ref_ptrT::operator=(T*) [with T = osg::Referenced]
/Users/sasha/source/trunk/examples/osgviewerQT/QOSGWidget.cpp:163: error: 
expected `;' before ‘WindowData’
make[2]: *** 
[examples/osgviewerQT/CMakeFiles/example_osgviewerQT.dir/QOSGWidget.cpp.o] 
Error 1
make[1]: *** [examples/osgviewerQT/CMakeFiles/example_osgviewerQT.dir/all] 
Error 2
make: *** [all] Error 2
MacBook-Pro-15-di-Massimo-Di-Stefano:build2 sasha$ 



 Massimo.


Il giorno 08/dic/2009, alle ore 17.30, Robert Osfield ha scritto:

 Hi Massimo,
 
 I've now spotted that you problems were no longer about the quicktime
 plugin... but Qt and WxWindows.  As Stephan mentions these examples
 will be using parts of the OSG/OSX that aren't supported under 64bit
 build.
 
 It should be possible to modify the Qt examples to compile under 64bit
 by avoiding the use of GraphicsWIndowCarbon.  I don't know if
 GrahicsWindowCocoa can be successfully used in it's place but you
 could try.  The other route it not use the GraphicsWindow inheritance
 functionality, and instead use GraphicsWindow embedded or the full
 GraphicsWindow subclass  functionality.
 
 Robert.
 
 On Tue, Dec 8, 2009 at 4:06 PM, Massimo Di Stefano
 massimodisa...@yahoo.it wrote:
 Hi Ronert,
 
 sure i did it
 
 cd trunk
 mkdir build
 ccmake ..
 
 i changed the configuration
 then pressed c to configure
 an g to generate the makefile
 
 in the file CMakeCache.txt i have :
 
 //standard image plugin for os x, options are quicktime, imageio
 OSG_DEFAULT_IMAGE_PLUGIN_FOR_OSX:STRING=imageio
 
 but the make continue to try to buld quicktime.
 
 Massimo.
 
 Il giorno 08/dic/2009, alle ore 16.41, Robert Osfield ha scritto:
 
 Hi Massimo,
 
 On Tue, Dec 8, 2009 at 3:38 PM, Massimo Di Stefano
 massimodisa...@yahoo.it wrote:
 Hi,
 
 i applied the change to cmake settings :
 
 OSG_DEFAULT_IMAGE_PLUGIN_FOR_OSX = imageio
 
 but the error persists, so i make a copy of the quicktime directory and i 
 removed all the files from the original on :
 
 After setting the variable using ccmake you should then press 'c' and
 'g' to configure and then generate the finale makefiles/Xcode
 projects.  If you miss these steps out then you'll still see the
 quicktime plugin building.
 
 Robert.
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 
 ___
 osg-users mailing list
 

Re: [osg-users] Mac OS X Snow Leopard

[Massimo Di Stefano]

Hi 

i'm tring to build osg trunk on mac osx snow leopard.

i tried to apply the change to the file :


from :

#if defined(_OPENTHREADS_ATOMIC_USE_MUTEX)
mutable Mutex _mutex;
#endif
#if defined(_OPENTHREADS_ATOMIC_USE_WIN32_INTERLOCKED)
volatile long _value;
#elif defined(_OPENTHREADS_ATOMIC_USE_BSD_ATOMIC)
volatile int32_t _value;
#elif defined(_OPENTHREADS_ATOMIC_USE_SUN)
volatile uint_t _value;
mutable Mutex _mutex;  // needed for xor
#else
volatile unsigned _value;
#endif
};

to :

#if defined(_OPENTHREADS_ATOMIC_USE_MUTEX)
mutable Mutex _mutex;
#endif
#if defined(_OPENTHREADS_ATOMIC_USE_WIN32_INTERLOCKED)
volatile long _value;
#elif defined(_OPENTHREADS_ATOMIC_USE_BSD_ATOMIC)
volatile int32_t _value;
#elif defined(_OPENTHREADS_ATOMIC_USE_SUN)
volatile uint_t _value;
mutable Mutex _mutex;  // needed for xor
#if defined(_OPENTHREADS_ATOMIC_USE_GCC_BUILTINS)  defined(__i386__)
volatile unsigned _value;

#endif


but i get this error :


MacBook-Pro-15-di-Massimo-Di-Stefano:build sasha$ make
[  0%] Building CXX object 
src/OpenThreads/pthreads/CMakeFiles/OpenThreads.dir/__/common/Atomic.cpp.o
In file included from 
/Users/sasha/source/trunk/src/OpenThreads/common/Atomic.cpp:14:
/Users/sasha/source/trunk/include/OpenThreads/Atomic:14:1: error: unterminated 
#ifndef
In file included from 
/Users/sasha/source/trunk/src/OpenThreads/common/Atomic.cpp:14:
/Users/sasha/source/trunk/include/OpenThreads/Atomic:70: error: ‘int32_t’ does 
not name a type
/Users/sasha/source/trunk/src/OpenThreads/common/Atomic.cpp:24: error: expected 
unqualified-id before ‘namespace’
/Users/sasha/source/trunk/src/OpenThreads/common/Atomic.cpp:175: error: 
expected `}' at end of input
/Users/sasha/source/trunk/include/OpenThreads/Atomic: In constructor 
‘OpenThreads::Atomic::Atomic(unsigned int)’:
/Users/sasha/source/trunk/include/OpenThreads/Atomic:50: error: class 
‘OpenThreads::Atomic’ does not have any field named ‘_value’
/Users/sasha/source/trunk/include/OpenThreads/Atomic: At global scope:
/Users/sasha/source/trunk/include/OpenThreads/Atomic:51: error: expected 
unqualified-id at end of input
/Users/sasha/source/trunk/include/OpenThreads/Atomic:51: error: expected `}' at 
end of input
make[2]: *** 
[src/OpenThreads/pthreads/CMakeFiles/OpenThreads.dir/__/common/Atomic.cpp.o] 
Error 1
make[1]: *** [src/OpenThreads/pthreads/CMakeFiles/OpenThreads.dir/all] Error 2
make: *** [all] Error 2
MacBook-Pro-15-di-Massimo-Di-Stefano:build sasha$ 


have you any clue on how to build osg on snow leopard?

thanks!

Massimo.


Il giorno 19/nov/2009, alle ore 18.02, Robert Osfield ha scritto:

 Hi Stefan,
 
 I'm just reviewing submissions and have just checked your changes to
 include/osg/Atomic and rather perplexed by the changes.   It concerns
 me that while it might hack around a problem elsewhere it'll introduce
 bugs under other build combinations.  You changes were the addition
 of:
 
 #if defined(_OPENTHREADS_ATOMIC_USE_GCC_BUILTINS)  defined(__i386__)
volatile unsigned _value;
 
 And the removal of the lines:
 
 #else
volatile unsigned _value;
 
 From the same block of code.  Neither change seems easily explainable
 or valid for the long term.
 
 Robert.
 
 On Mon, Nov 2, 2009 at 11:56 PM, stefan) ste...@nortd.com wrote:
 Hey Paul,
 
 I just built osg 2.8.2 from scratch on 10.6.1 (snow leopard). I would
 be happy if we could roll a 2.8.3 release with the required patches.
 
 The patched files in question are attached. Is there anything else I
 can do to make this 2.8.3 release happen?
 
 It's also good to note that there is a bug in cmake 2.6 which has been
 resolved in the 2.8-0 preview release. The architecture is not set
 correctly in the xcode project files. this mean even though i386 is
 set in cmake the xcode project will be set to $(NATIVE_ARCH) which
 results in a 64-bit build. Using cmake 2.8 or manually setting the
 architecture resolves this issue.
 
 
 /stefanix
 
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 
 
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Mac bundle distribution can't use plugin

[Filip Wänström]

I Haven't fixed my issues yet so here comes some more info. This is
what I get when listing dependencies using otool. I have massaged the
libs extensivly using install_name_tool...

[fi...@mpq]:[~/Documents/Code/OSGTests/Build/_CPack_Packages/Darwin/DragNDrop/BasicApp-1.0.0-Darwin/BasicApp.app/Contents/MacOS]$
otool -L BasicApp
BasicApp:
@loader_path/libosgDB.61.dylib (compatibility version 61.0.0,
current version 2.9.6)
@loader_path/libosgUtil.61.dylib (compatibility version
61.0.0, current version 2.9.6)
@loader_path/libosgGA.61.dylib (compatibility version 61.0.0,
current version 2.9.6)
@loader_path/libosgText.61.dylib (compatibility version
61.0.0, current version 2.9.6)
@loader_path/libosgViewer.61.dylib (compatibility version
61.0.0, current version 2.9.6)
@loader_path/libosg.61.dylib (compatibility version 61.0.0,
current version 2.9.6)
@loader_path/libOpenThreads.11.dylib (compatibility version
11.0.0, current version 2.4.0)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0,
current version 7.9.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 123.0.0)
[fi...@mpq]:[~/Documents/Code/OSGTests/Build/_CPack_Packages/Darwin/DragNDrop/BasicApp-1.0.0-Darwin/BasicApp.app/Contents/MacOS]$
otool -L libOpenThreads.11.dylib
libOpenThreads.11.dylib:
@loader_path/libOpenThreads.11.dylib (compatibility version
11.0.0, current version 2.4.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 111.1.4)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0,
current version 7.4.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0,
current version 1.0.0)
[fi...@mpq]:[~/Documents/Code/OSGTests/
Build/_CPack_Packages/Darwin/DragNDrop/BasicApp-1.0.0-Darwin/BasicApp.app/Contents/MacOS]$
otool -L ../PlugIns/osgPlugins-2.9.6/osgdb_obj.so
../PlugIns/osgPlugins-2.9.6/osgdb_obj.so:
@loader_path/libOpenThreads.11.dylib (compatibility version
11.0.0, current version 2.4.0)
@loader_path/libosg.61.dylib (compatibility version 61.0.0,
current version 2.9.6)
@loader_path/libosgDB.61.dylib (compatibility version 61.0.0,
current version 2.9.6)
@loader_path/libosgUtil.61.dylib (compatibility version
61.0.0, current version 2.9.6)
/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon
(compatibility version 2.0.0, current version 136.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 111.1.4)
/System/Library/Frameworks/AGL.framework/Versions/A/AGL
(compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL
(compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0,
current version 7.4.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0,
current version 1.0.0)


And the output from the failing loading of the plugin is a before (in
first post). Any ideas ?
/F



On Mon, Nov 23, 2009 at 9:52 AM, Filip Wänström
filip.wanst...@gmail.com wrote:
 Hi, thanks for the answer but I am using CMake/regular makefiles to do
 all my building and using the OSX Ingest into bundle script that
 comes with osg. I just presumed it did all magic but maybe I should
 check out the actual paths in the libs. I'll be back with a report.
 /Filip

 On Fri, Nov 20, 2009 at 6:21 PM, Stephan Maximilian Huber
 ratzf...@digitalmind.de wrote:
 Hi Filip,

 check your system.log-file -- I am pretty sure the osgdb_obj pluging
 refers to the osg-dylibs in /usr/lib or similar.

 You'll have to massage the paths to the libs stored in the plugin via
 install_name_tool in a post-build-step.

 Paths to libs are hardcoded in the object-file when linked. You can
 change them to something better suited like @loader_path.../pipapo. Try
 googling for install_name_tool and @loader_path to get an idea.

 If you are using the deprecated XCode-project and embed the osg
 frameworks into your app and the obj-plugin into plugins it should work
 out of the box whithout fiddling around with install_name_tool.

 cheers,
 Stephan



 Filip Wänström schrieb:
 Hi,

 I have problems with distributing self-contained applications on the
 mac. I have reduced my issues by building a very simple example that
 basically only opens a window and loads an .obj file.

 Using OSG_NOTIFY_LEVEL=INFO (DEBUG is the same + a lot more, but
 unrelated) I get the following output:

 [fi...@mpq]:[~/Documents/Code/OSGTests/]$
 ./_CPack_Packages/Darwin/DragNDrop/BasicApp-1.0.0-Darwin/BasicApp.app/Contents/MacOS/BasicApp
 GraphicsContext::setWindowingSystemInterface() 0xc0e930 0xa13c50
 Initiating 
 Constructing BasicApp 1
 Listing plugins
 plugin: 
 /Users/filip/Documents/Code/OSGTests/_CPack_Packages/Darwin/DragNDrop/BasicApp-1.0.0-Darwin/BasicApp.app/Contents/PlugIns/osgPlugins-2.9.6/osgdb_obj.so
 Found file: data/models/clogo.obj
 

Re: [osg-users] Mac bundle distribution can't use plugin

[Filip Wänström]

And finally, I have a founf the fix. These are happy times!

The plugin loader_path should be pointing to the libs from the path of
the plugin. This means that the otool listing should be:
$otool -L osgdb_obj.so
osgdb_obj.so:
@loader_path/../../MacOS/libOpenThreads.11.dylib
(compatibility version 11.0.0, current version 2.4.0)
@loader_path/../../MacOS/libosg.61.dylib (compatibility
version 61.0.0, current version 2.9.6)
@loader_path/../../MacOS/libosgDB.61.dylib (compatibility
version 61.0.0, current version 2.9.6)
@loader_path/../../MacOS/libosgUtil.61.dylib (compatibility
version 61.0.0, current version 2.9.6)
/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon
(compatibility version 2.0.0, current version 136.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 111.1.4)
/System/Library/Frameworks/AGL.framework/Versions/A/AGL
(compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL
(compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0,
current version 7.4.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0,
current version 1.0.0)

And then it all works. I will make an example of this so that others
don't have to spend weeks to support mac deployment!
/Filip



On Wed, Nov 25, 2009 at 10:46 AM, Filip Wänström
filip.wanst...@gmail.com wrote:
 I Haven't fixed my issues yet so here comes some more info. This is
 what I get when listing dependencies using otool. I have massaged the
 libs extensivly using install_name_tool...

 [fi...@mpq]:[~/Documents/Code/OSGTests/Build/_CPack_Packages/Darwin/DragNDrop/BasicApp-1.0.0-Darwin/BasicApp.app/Contents/MacOS]$
 otool -L BasicApp
 BasicApp:
       �...@loader_path/libosgDB.61.dylib (compatibility version 61.0.0,
 current version 2.9.6)
       �...@loader_path/libosgUtil.61.dylib (compatibility version
 61.0.0, current version 2.9.6)
       �...@loader_path/libosgGA.61.dylib (compatibility version 61.0.0,
 current version 2.9.6)
       �...@loader_path/libosgText.61.dylib (compatibility version
 61.0.0, current version 2.9.6)
       �...@loader_path/libosgViewer.61.dylib (compatibility version
 61.0.0, current version 2.9.6)
       �...@loader_path/libosg.61.dylib (compatibility version 61.0.0,
 current version 2.9.6)
       �...@loader_path/libOpenThreads.11.dylib (compatibility version
 11.0.0, current version 2.4.0)
        /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0,
 current version 7.9.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
 current version 123.0.0)
 [fi...@mpq]:[~/Documents/Code/OSGTests/Build/_CPack_Packages/Darwin/DragNDrop/BasicApp-1.0.0-Darwin/BasicApp.app/Contents/MacOS]$
 otool -L libOpenThreads.11.dylib
 libOpenThreads.11.dylib:
       �...@loader_path/libOpenThreads.11.dylib (compatibility version
 11.0.0, current version 2.4.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
 current version 111.1.4)
        /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0,
 current version 7.4.0)
        /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0,
 current version 1.0.0)
 [fi...@mpq]:[~/Documents/Code/OSGTests/
 Build/_CPack_Packages/Darwin/DragNDrop/BasicApp-1.0.0-Darwin/BasicApp.app/Contents/MacOS]$
 otool -L ../PlugIns/osgPlugins-2.9.6/osgdb_obj.so
 ../PlugIns/osgPlugins-2.9.6/osgdb_obj.so:
       �...@loader_path/libOpenThreads.11.dylib (compatibility version
 11.0.0, current version 2.4.0)
       �...@loader_path/libosg.61.dylib (compatibility version 61.0.0,
 current version 2.9.6)
       �...@loader_path/libosgDB.61.dylib (compatibility version 61.0.0,
 current version 2.9.6)
       �...@loader_path/libosgUtil.61.dylib (compatibility version
 61.0.0, current version 2.9.6)
        /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon
 (compatibility version 2.0.0, current version 136.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
 current version 111.1.4)
        /System/Library/Frameworks/AGL.framework/Versions/A/AGL
 (compatibility version 1.0.0, current version 1.0.0)
        /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL
 (compatibility version 1.0.0, current version 1.0.0)
        /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0,
 current version 7.4.0)
        /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0,
 current version 1.0.0)


 And the output from the failing loading of the plugin is a before (in
 first post). Any ideas ?
 /F



 On Mon, Nov 23, 2009 at 9:52 AM, Filip Wänström
 filip.wanst...@gmail.com wrote:
 Hi, thanks for the answer but I am using CMake/regular makefiles to do
 all my building and using the OSX Ingest into bundle script that
 comes with osg. I just presumed it did all magic but maybe I should
 check out the actual paths in the libs. I'll be back with a report.
 

Re: [osg-users] Mac bundle distribution can't use plugin

[Stephan Maximilian Huber]

Hi Filip,

there's one major difference between your otool output and the otool
output of my packaged app:


[fi...@mpq]:[~/Documents/Code/OSGTests/Build/_CPack_Packages/Darwin/DragNDrop/BasicApp-1.0.0-Darwin/BasicApp.app/Contents/MacOS]$
 otool -L libOpenThreads.11.dylib
 libOpenThreads.11.dylib:
 @loader_path/libOpenThreads.11.dylib (compatibility version

in my version, there's only
 libOpenThreads.11.dylib (compatibility version

for every used lib. Not sure if this makes a difference.

Check your logfiles (open Console.app), there should be a more
descriptive errormessage from the dynamic linker.

cheers,
Stephan


Filip Wänström schrieb:
 I Haven't fixed my issues yet so here comes some more info. This is
 what I get when listing dependencies using otool. I have massaged the
 libs extensivly using install_name_tool...
 
 [fi...@mpq]:[~/Documents/Code/OSGTests/Build/_CPack_Packages/Darwin/DragNDrop/BasicApp-1.0.0-Darwin/BasicApp.app/Contents/MacOS]$
 otool -L BasicApp
 BasicApp:
 @loader_path/libosgDB.61.dylib (compatibility version 61.0.0,
 current version 2.9.6)
 @loader_path/libosgUtil.61.dylib (compatibility version
 61.0.0, current version 2.9.6)
 @loader_path/libosgGA.61.dylib (compatibility version 61.0.0,
 current version 2.9.6)
 @loader_path/libosgText.61.dylib (compatibility version
 61.0.0, current version 2.9.6)
 @loader_path/libosgViewer.61.dylib (compatibility version
 61.0.0, current version 2.9.6)
 @loader_path/libosg.61.dylib (compatibility version 61.0.0,
 current version 2.9.6)
 @loader_path/libOpenThreads.11.dylib (compatibility version
 11.0.0, current version 2.4.0)
 /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0,
 current version 7.9.0)
 /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
 current version 123.0.0)
 [fi...@mpq]:[~/Documents/Code/OSGTests/Build/_CPack_Packages/Darwin/DragNDrop/BasicApp-1.0.0-Darwin/BasicApp.app/Contents/MacOS]$
 otool -L libOpenThreads.11.dylib
 libOpenThreads.11.dylib:
 @loader_path/libOpenThreads.11.dylib (compatibility version
 11.0.0, current version 2.4.0)
 /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
 current version 111.1.4)
 /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0,
 current version 7.4.0)
 /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0,
 current version 1.0.0)
 [fi...@mpq]:[~/Documents/Code/OSGTests/
 Build/_CPack_Packages/Darwin/DragNDrop/BasicApp-1.0.0-Darwin/BasicApp.app/Contents/MacOS]$
 otool -L ../PlugIns/osgPlugins-2.9.6/osgdb_obj.so
 ../PlugIns/osgPlugins-2.9.6/osgdb_obj.so:
 @loader_path/libOpenThreads.11.dylib (compatibility version
 11.0.0, current version 2.4.0)
 @loader_path/libosg.61.dylib (compatibility version 61.0.0,
 current version 2.9.6)
 @loader_path/libosgDB.61.dylib (compatibility version 61.0.0,
 current version 2.9.6)
 @loader_path/libosgUtil.61.dylib (compatibility version
 61.0.0, current version 2.9.6)
 /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon
 (compatibility version 2.0.0, current version 136.0.0)
 /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
 current version 111.1.4)
 /System/Library/Frameworks/AGL.framework/Versions/A/AGL
 (compatibility version 1.0.0, current version 1.0.0)
 /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL
 (compatibility version 1.0.0, current version 1.0.0)
 /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0,
 current version 7.4.0)
 /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0,
 current version 1.0.0)
 
 
 And the output from the failing loading of the plugin is a before (in
 first post). Any ideas ?
 /F
 
 
 
 On Mon, Nov 23, 2009 at 9:52 AM, Filip Wänström
 filip.wanst...@gmail.com wrote:
 Hi, thanks for the answer but I am using CMake/regular makefiles to do
 all my building and using the OSX Ingest into bundle script that
 comes with osg. I just presumed it did all magic but maybe I should
 check out the actual paths in the libs. I'll be back with a report.
 /Filip

 On Fri, Nov 20, 2009 at 6:21 PM, Stephan Maximilian Huber
 ratzf...@digitalmind.de wrote:
 Hi Filip,

 check your system.log-file -- I am pretty sure the osgdb_obj pluging
 refers to the osg-dylibs in /usr/lib or similar.

 You'll have to massage the paths to the libs stored in the plugin via
 install_name_tool in a post-build-step.

 Paths to libs are hardcoded in the object-file when linked. You can
 change them to something better suited like @loader_path.../pipapo. Try
 googling for install_name_tool and @loader_path to get an idea.

 If you are using the deprecated XCode-project and embed the osg
 frameworks into your app and the obj-plugin into plugins it should work
 out of the box whithout fiddling around with install_name_tool.

 cheers,
 Stephan



 Filip Wänström schrieb:
 Hi,

 I have problems with 

Re: [osg-users] Mac bundle distribution can't use plugin

[Filip Wänström]

Hi, thanks for the answer but I am using CMake/regular makefiles to do
all my building and using the OSX Ingest into bundle script that
comes with osg. I just presumed it did all magic but maybe I should
check out the actual paths in the libs. I'll be back with a report.
/Filip

On Fri, Nov 20, 2009 at 6:21 PM, Stephan Maximilian Huber
ratzf...@digitalmind.de wrote:
 Hi Filip,

 check your system.log-file -- I am pretty sure the osgdb_obj pluging
 refers to the osg-dylibs in /usr/lib or similar.

 You'll have to massage the paths to the libs stored in the plugin via
 install_name_tool in a post-build-step.

 Paths to libs are hardcoded in the object-file when linked. You can
 change them to something better suited like @loader_path.../pipapo. Try
 googling for install_name_tool and @loader_path to get an idea.

 If you are using the deprecated XCode-project and embed the osg
 frameworks into your app and the obj-plugin into plugins it should work
 out of the box whithout fiddling around with install_name_tool.

 cheers,
 Stephan



 Filip Wänström schrieb:
 Hi,

 I have problems with distributing self-contained applications on the
 mac. I have reduced my issues by building a very simple example that
 basically only opens a window and loads an .obj file.

 Using OSG_NOTIFY_LEVEL=INFO (DEBUG is the same + a lot more, but
 unrelated) I get the following output:

 [fi...@mpq]:[~/Documents/Code/OSGTests/]$
 ./_CPack_Packages/Darwin/DragNDrop/BasicApp-1.0.0-Darwin/BasicApp.app/Contents/MacOS/BasicApp
 GraphicsContext::setWindowingSystemInterface() 0xc0e930 0xa13c50
 Initiating 
 Constructing BasicApp 1
 Listing plugins
 plugin: 
 /Users/filip/Documents/Code/OSGTests/_CPack_Packages/Darwin/DragNDrop/BasicApp-1.0.0-Darwin/BasicApp.app/Contents/PlugIns/osgPlugins-2.9.6/osgdb_obj.so
 Found file: data/models/clogo.obj
 Opened DynamicLibrary osgPlugins-2.9.6/osgdb_obj.so
 Warning: Could not find plugin to read objects from file
 data/models/clogo.obj.
 Failed to load model

 This seems self contradictory to me...

 So as far as I can tell:
 1) the bundled osglibs are found correctly and the app starts
 2) the file in the Resources directory in the app bundle is found correctly
 3) the right plugin is chosen and found in the app bundle
 PlugIns/osgPlugins-2.9.6 directory
 4) The lib is opened ok
 5) it fails

 All .dylibs/.so are copied from my /usr/local/ osg install into the app 
 bundle

 I tried to see if there were some hidden depencies on osgdb_obj.so
 using otool but as far as I could tell there were no extra Non-system
 dependencies

 I'm at a loss here and tearing my nonexistent hair. Any help would be
 greatly appreciated.

 Best
 /Filip
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Mac bundle distribution can't use plugin

[Filip Wänström]

Hi,

I have problems with distributing self-contained applications on the
mac. I have reduced my issues by building a very simple example that
basically only opens a window and loads an .obj file.

Using OSG_NOTIFY_LEVEL=INFO (DEBUG is the same + a lot more, but
unrelated) I get the following output:

[fi...@mpq]:[~/Documents/Code/OSGTests/]$
./_CPack_Packages/Darwin/DragNDrop/BasicApp-1.0.0-Darwin/BasicApp.app/Contents/MacOS/BasicApp
GraphicsContext::setWindowingSystemInterface() 0xc0e930 0xa13c50
Initiating 
Constructing BasicApp 1
Listing plugins
plugin: 
/Users/filip/Documents/Code/OSGTests/_CPack_Packages/Darwin/DragNDrop/BasicApp-1.0.0-Darwin/BasicApp.app/Contents/PlugIns/osgPlugins-2.9.6/osgdb_obj.so
Found file: data/models/clogo.obj
Opened DynamicLibrary osgPlugins-2.9.6/osgdb_obj.so
Warning: Could not find plugin to read objects from file
data/models/clogo.obj.
Failed to load model

This seems self contradictory to me...

So as far as I can tell:
1) the bundled osglibs are found correctly and the app starts
2) the file in the Resources directory in the app bundle is found correctly
3) the right plugin is chosen and found in the app bundle
PlugIns/osgPlugins-2.9.6 directory
4) The lib is opened ok
5) it fails

All .dylibs/.so are copied from my /usr/local/ osg install into the app bundle

I tried to see if there were some hidden depencies on osgdb_obj.so
using otool but as far as I could tell there were no extra Non-system
dependencies

I'm at a loss here and tearing my nonexistent hair. Any help would be
greatly appreciated.

Best
/Filip
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Mac bundle distribution can't use plugin

[Stephan Maximilian Huber]

Hi Filip,

check your system.log-file -- I am pretty sure the osgdb_obj pluging
refers to the osg-dylibs in /usr/lib or similar.

You'll have to massage the paths to the libs stored in the plugin via
install_name_tool in a post-build-step.

Paths to libs are hardcoded in the object-file when linked. You can
change them to something better suited like @loader_path.../pipapo. Try
googling for install_name_tool and @loader_path to get an idea.

If you are using the deprecated XCode-project and embed the osg
frameworks into your app and the obj-plugin into plugins it should work
out of the box whithout fiddling around with install_name_tool.

cheers,
Stephan



Filip Wänström schrieb:
 Hi,
 
 I have problems with distributing self-contained applications on the
 mac. I have reduced my issues by building a very simple example that
 basically only opens a window and loads an .obj file.
 
 Using OSG_NOTIFY_LEVEL=INFO (DEBUG is the same + a lot more, but
 unrelated) I get the following output:
 
 [fi...@mpq]:[~/Documents/Code/OSGTests/]$
 ./_CPack_Packages/Darwin/DragNDrop/BasicApp-1.0.0-Darwin/BasicApp.app/Contents/MacOS/BasicApp
 GraphicsContext::setWindowingSystemInterface() 0xc0e930 0xa13c50
 Initiating 
 Constructing BasicApp 1
 Listing plugins
 plugin: 
 /Users/filip/Documents/Code/OSGTests/_CPack_Packages/Darwin/DragNDrop/BasicApp-1.0.0-Darwin/BasicApp.app/Contents/PlugIns/osgPlugins-2.9.6/osgdb_obj.so
 Found file: data/models/clogo.obj
 Opened DynamicLibrary osgPlugins-2.9.6/osgdb_obj.so
 Warning: Could not find plugin to read objects from file
 data/models/clogo.obj.
 Failed to load model
 
 This seems self contradictory to me...
 
 So as far as I can tell:
 1) the bundled osglibs are found correctly and the app starts
 2) the file in the Resources directory in the app bundle is found correctly
 3) the right plugin is chosen and found in the app bundle
 PlugIns/osgPlugins-2.9.6 directory
 4) The lib is opened ok
 5) it fails
 
 All .dylibs/.so are copied from my /usr/local/ osg install into the app bundle
 
 I tried to see if there were some hidden depencies on osgdb_obj.so
 using otool but as far as I could tell there were no extra Non-system
 dependencies
 
 I'm at a loss here and tearing my nonexistent hair. Any help would be
 greatly appreciated.
 
 Best
 /Filip
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Mac OS X Snow Leopard

[Robert Osfield]

Hi Stefan,

I'm just reviewing submissions and have just checked your changes to
include/osg/Atomic and rather perplexed by the changes.   It concerns
me that while it might hack around a problem elsewhere it'll introduce
bugs under other build combinations.  You changes were the addition
of:

#if defined(_OPENTHREADS_ATOMIC_USE_GCC_BUILTINS)  defined(__i386__)
volatile unsigned _value;

And the removal of the lines:

#else
volatile unsigned _value;

From the same block of code.  Neither change seems easily explainable
or valid for the long term.

Robert.

On Mon, Nov 2, 2009 at 11:56 PM, stefan) ste...@nortd.com wrote:
 Hey Paul,

 I just built osg 2.8.2 from scratch on 10.6.1 (snow leopard). I would
 be happy if we could roll a 2.8.3 release with the required patches.

 The patched files in question are attached. Is there anything else I
 can do to make this 2.8.3 release happen?

 It's also good to note that there is a bug in cmake 2.6 which has been
 resolved in the 2.8-0 preview release. The architecture is not set
 correctly in the xcode project files. this mean even though i386 is
 set in cmake the xcode project will be set to $(NATIVE_ARCH) which
 results in a 64-bit build. Using cmake 2.8 or manually setting the
 architecture resolves this issue.


 /stefanix

 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Mac OS X Snow Leopard

[Stephan Huber]

Hi Paul,

Paul Martz schrieb:
 Thanks, not sure about a 2.8.3, but it's under consideration. Good to
 know you're interested.
 
 I understand you can build 2.8.2 against the 10.5 SDK and still run on
 Snow Leopard. My understanding is the changes to OSG for Snow Leopard
 will allow someone to build OSG against the 10.6 SDK, is that right?

Snow Leopard defaults to gcc 4.2 which is pickier than gcc 4.0 (the
default for 10.5) The patches to Atomic + ReaderWriterQt fixes these
issues with gcc 4.2.

If you switch your xcode-projects to gcc 4.0 the current 2.8.x source
builds fine for 10.4 on Snow Leopard.

These patches are needed regardless what sdk you are targetting if you
are using gcc 4.2. But they  even work for 10.5 / gcc 4.0 :)

I can add an automatic build/compile test for the 2.8.x-branch here on
my local machine, currently I am only monitoring osg-trunk and provide
fixes back to Robert if necessary. But I didn't move to 10.6 with this
machine.

cheers,
Stephan
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Mac OS X Snow Leopard

[Nico Kruithof]

Hi Paul,

I tried to compile osg/trunk as a static library on Snow Leopard this week
and it failed somewhere with a message about the quicktime library if I
remember correctly. I could build trunk again (shared or static) and send
the results to the cdash server if you are interested. It is a fresh snow
leopard install.

-- Nico

On Tue, Nov 3, 2009 at 9:29 AM, Stephan Huber ratzf...@digitalmind.dewrote:

 Hi Paul,

 Paul Martz schrieb:
  Thanks, not sure about a 2.8.3, but it's under consideration. Good to
  know you're interested.
 
  I understand you can build 2.8.2 against the 10.5 SDK and still run on
  Snow Leopard. My understanding is the changes to OSG for Snow Leopard
  will allow someone to build OSG against the 10.6 SDK, is that right?

 Snow Leopard defaults to gcc 4.2 which is pickier than gcc 4.0 (the
 default for 10.5) The patches to Atomic + ReaderWriterQt fixes these
 issues with gcc 4.2.

 If you switch your xcode-projects to gcc 4.0 the current 2.8.x source
 builds fine for 10.4 on Snow Leopard.

 These patches are needed regardless what sdk you are targetting if you
 are using gcc 4.2. But they  even work for 10.5 / gcc 4.0 :)

 I can add an automatic build/compile test for the 2.8.x-branch here on
 my local machine, currently I am only monitoring osg-trunk and provide
 fixes back to Robert if necessary. But I didn't move to 10.6 with this
 machine.

 cheers,
 Stephan
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Mac OS X Snow Leopard

[stefan nortd]

 If you switch your xcode-projects to gcc 4.0
 the current 2.8.x source builds fine for 10.4 on Snow Leopard. 

Nope, switching to gcc 4.0 does not make any difference for me. And BTW there 
is no 10.4 SDK on snow leopard.

/stefan


stefan hechenberger

http://linear.nortd.com

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=19097#19097





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Mac OS X Snow Leopard

[Jordi Torres]

Hi stefan

Nope, switching to gcc 4.0 does not make any difference for me. And BTW
 there is no 10.4 SDK on snow leopard.

 /stefan


It is possible to have a 10.4 SDK in snowleopard if you have activated
compatibility when you did the migration from Leopard to SnowLeopard.
However the only cofiguration working for me is SDK 10.6 and architecture
i386.

Greets.



 
 stefan hechenberger

 http://linear.nortd.com

 --
 Read this topic online here:
 http://forum.openscenegraph.org/viewtopic.php?p=19097#19097





 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org





-- 
Jordi Torres Fabra

Instituto de Automática e Informática Industrial
http://www.ai2.upv.es
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Mac OS X Snow Leopard

[Nico Kruithof]

Hi,

I submitted an experimental test. It shows on the cdash site, but it doesn't
show the errors. I took the current trunk, applied the Atomic patch, that
was previously sent to this list and ran the test with no arguments to
cmake.

It fails in ReaderWriterQT.cpp, which is probably easy to fix. I'll have a
look later today.

Bests,
Nico

On Tue, Nov 3, 2009 at 1:17 PM, Jordi Torres jtorresfa...@gmail.com wrote:

 Hi stefan

 Nope, switching to gcc 4.0 does not make any difference for me. And BTW
 there is no 10.4 SDK on snow leopard.

 /stefan


 It is possible to have a 10.4 SDK in snowleopard if you have activated
 compatibility when you did the migration from Leopard to SnowLeopard.
 However the only cofiguration working for me is SDK 10.6 and architecture
 i386.

 Greets.



 
 stefan hechenberger

 http://linear.nortd.com

 --
 Read this topic online here:
 http://forum.openscenegraph.org/viewtopic.php?p=19097#19097





 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org





 --
 Jordi Torres Fabra

 Instituto de Automática e Informática Industrial
 http://www.ai2.upv.es

 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Mac OS X Snow Leopard

[stefan nortd]

sth wrote:
 stefan nortd schrieb:
 
  Nope, switching to gcc 4.0 does not make any difference for me. And BTW 
  there is no 10.4 SDK on snow leopard.
  
 
 It's an install option when installing xcode.
 
 Stephan
 ___
 osg-users mailing list
 
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 
  --
 Post generated by Mail2Forum


Thanks for clarifying.

/stefan


stefan hechenberger

http://linear.nortd.com

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=19122#19122





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Mac OS X Snow Leopard

[stefan)]

Hey Paul,

I just built osg 2.8.2 from scratch on 10.6.1 (snow leopard). I would
be happy if we could roll a 2.8.3 release with the required patches.

The patched files in question are attached. Is there anything else I
can do to make this 2.8.3 release happen?

It's also good to note that there is a bug in cmake 2.6 which has been
resolved in the 2.8-0 preview release. The architecture is not set
correctly in the xcode project files. this mean even though i386 is
set in cmake the xcode project will be set to $(NATIVE_ARCH) which
results in a 64-bit build. Using cmake 2.8 or manually setting the
architecture resolves this issue.


/stefanix


ReaderWriterQT.cpp
Description: Binary data


Atomic
Description: Binary data
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Mac OS X Snow Leopard

[Paul Martz]

Thanks, not sure about a 2.8.3, but it's under consideration. Good to 
know you're interested.


I understand you can build 2.8.2 against the 10.5 SDK and still run on 
Snow Leopard. My understanding is the changes to OSG for Snow Leopard 
will allow someone to build OSG against the 10.6 SDK, is that right?


Paul Martz
Skew Matrix Software LLC
_http://www.skew-matrix.com_ http://www.skew-matrix.com/
+1 303 859 9466



stefan) wrote:

Hey Paul,

I just built osg 2.8.2 from scratch on 10.6.1 (snow leopard). I would
be happy if we could roll a 2.8.3 release with the required patches.

The patched files in question are attached. Is there anything else I
can do to make this 2.8.3 release happen?

It's also good to note that there is a bug in cmake 2.6 which has been
resolved in the 2.8-0 preview release. The architecture is not set
correctly in the xcode project files. this mean even though i386 is
set in cmake the xcode project will be set to $(NATIVE_ARCH) which
results in a 64-bit build. Using cmake 2.8 or manually setting the
architecture resolves this issue.


/stefanix




___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Mac OS X Snow Leopard

[stefan nortd]

(still figuring out how the mailing list is connected to the forum)


hey paul,

I needed to apply the patches for building osg against either SDK. It's not 
exactly clear to me which change in Snow Leopard makes this necessary. Even 
with the same xcode, gcc, and 10.5 SDK the osg 2.8.2 does not build without the 
changes. 


/stefan


stefan hechenberger

http://linear.nortd.com

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=19080#19080





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Mac OS X Snow Leopard

[Anderson, Ross - 1006 - MITLL]

I use the OSG within a custom GUI, so I can't speak to using  
osgViewer, but the rest of the frameworks build fine for me on Snow  
Leopard. I use 10.5 as the SDK, so I'm not using any SL-specific APIs.


I have been using trunk in order to get the 64-bit Cocoa  
configurations within the Xcode project.


---
Ross Anderson
r...@ll.mit.edu
Group 106 - Active Optical Systems
MIT Lincoln Laboratory
(781) 981-3344


On Oct 30, 2009, at 12:55 PM, Paul Martz wrote:


Hi all -- I saw some submissions for building OSG on Snow Leopard. Are
these folded into trunk? Are there any Snow Leopard users who can  
report

on how things are going?

Is there any interest in folding these changes into the 2.8 branch and
doing a 2.8.3 release -- basically 2.8.2 plus support for Snow  
Leopard?

Does anyone have cycles to take this on?
--
Paul Martz
Skew Matrix Software LLC
_http://www.skew-matrix.com_ http://www.skew-matrix.com/
+1 303 859 9466

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org




smime.p7s
Description: S/MIME cryptographic signature
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Mac OS X mouse handling Warp pointer.

[Stephan Maximilian Huber]

Hi David,

David Guthrie schrieb:
 Hi,
 
 I'm having an issue which with warping the mouse pointer on Mac OS X that is 
 generally expected, but behaves differently than on other platforms.
 
 That is, when you warp the mouse pointer using either of the warp functions 
 (GraphicsWindowCarbon uses CGDisplayMoveCursorToPoint), all input is frozen 
 for 0.25 seconds.  When trying to implement a mouse look style mouse 
 movement, the normal method is to move the mouse pointer back to the center 
 of the screen even frame on other platforms, but doing this blocks all input 
 in OS X for a quarter second unless I call
 
 CGSetLocalEventsSuppressionInterval(0);
 
 The other method is to disassociate the mouse pointer position from the mouse 
 movement, but that solution won't work with the current osx window classes 
 because they track the mouse position, not its movement.
 
 I was going to submit a change adding the above line to GraphicsWindowCarbon, 
 and possible the Cocoa version, but it appears that this function is 
 deprecated in 10.6 in favor of
 
 CGEventSourceSetLocalEventsSuppressionInterval(...);
 
 
 So, to conclude,  I have two points to this post.
 
 1.  I think we should make this the default behavior so it will work the same 
 across platforms, unless there is another solution
 
 2.  I don't know how to implement this using the other function because I'm 
 not an expert on event sources, and I haven't really been able to make it 
 work.  Does anyone more skilled than I in this area know how to make this 
 work or do you recommend I just use the older function for now?


There's really no documentation about using
CGEventSourceSetLocalEventsSuppressionInterval correctly.

I tried something along these lines, but it didn't work.

CGEventSourceRef event_source_ref =
CGEventSourceCreate(kCGEventSourceStateCombinedSessionState);
CGEventSourceSetLocalEventsSuppressionInterval(event_source_ref, 0.0);
CFRelease(event_source_ref);


So I think it's best we use the deprecated call to
CGSetLocalEventsSuppressionInterval. The carbon implementation is full
of deprecated calls :)

cheers,
Stephan
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Mac OS X mouse handling Warp pointer.

[David Guthrie]

Hi,

I'm having an issue which with warping the mouse pointer on Mac OS X that is 
generally expected, but behaves differently than on other platforms.

That is, when you warp the mouse pointer using either of the warp functions 
(GraphicsWindowCarbon uses CGDisplayMoveCursorToPoint), all input is frozen for 
0.25 seconds.  When trying to implement a mouse look style mouse movement, the 
normal method is to move the mouse pointer back to the center of the screen 
even frame on other platforms, but doing this blocks all input in OS X for a 
quarter second unless I call

CGSetLocalEventsSuppressionInterval(0);

The other method is to disassociate the mouse pointer position from the mouse 
movement, but that solution won't work with the current osx window classes 
because they track the mouse position, not its movement.

I was going to submit a change adding the above line to GraphicsWindowCarbon, 
and possible the Cocoa version, but it appears that this function is deprecated 
in 10.6 in favor of

CGEventSourceSetLocalEventsSuppressionInterval(...);


So, to conclude,  I have two points to this post.

1.  I think we should make this the default behavior so it will work the same 
across platforms, unless there is another solution

2.  I don't know how to implement this using the other function because I'm not 
an expert on event sources, and I haven't really been able to make it work.  
Does anyone more skilled than I in this area know how to make this work or do 
you recommend I just use the older function for now?



Thank you!

Cheers,
David

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=18730#18730





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Mac OSX NVIDIA GLSL bug w/ Uniform arrays broken

[Robert Osfield]

HI Davis,

Sorry to hear that you are hitting up against a driver bug.  It does
seem that NVidia on Macs is a bit of second class citizen, feedback
from Mac users (I've seen it first hand as well) is that ATI drivers
are better that NVidia drivers, with is rather than the reverse of
Windows/Linux.  This doesn't help you alas.

As for workarounds for one particular platform, we'll this is
something of a moving target, one driver revision a bug will appear,
and the next it could be fixed while others bugs can appear.  Since
the OSG isn't tied to any particular hardware or driver version it
isn't possible to match any of these driver bugs.  The best we can do
is provide a mechnanism for disabling bugs via env vars, which is what
we do - see include/osg/GLExtensions.

W.r.t not introducing OpenGL/OSG features that break on some
platforms, this would be insane, we can't drop the OSG down to the
lowest common denominator just because some drivers and some points in
time are broken, we'd end up with practically no functionality exposed
by the OSG at all, and over time we'd need to keep rolling back what
functionality that is exposed as new bugs like the one you are
reporting come in.

In your own case you have a machine with a broken driver, the people
to address this are Apple so I have to recommend that you approach
Apple with a bug report.  The other approach would be to dual boot
your machine with Windows and Linux where the NVidia drivers are
better quality.

As a general note, Mac's users make up minority of our community (web
stats suggest 5%) with Windows and Linux being the main platforms for
graphics development.  This unfortunately means that OSG gets less
testing under Mac than the other main platforms so few problems will
be spotted, and pool of engineers that are available to help support
Mac is also smaller.  While vast majority of the OSG is cross
platform, but areas like OpenGL driver quality is something that does
not cross platform boundaries, and with the smaller pool for testing
and development does put greater need for developers under Mac to
relatively more proactive to enable similar quality of results.

Robert.

On Wed, Mar 11, 2009 at 10:20 PM, McKay Davis mckay@gmail.com wrote:
 Robert et al.,

 I've run into a driver bug on OSX where all GLSL uniform array
 elements are returning a value of 0 in the shader as though they were
 not bound.

 This is the same bug referenced in this thread:

 http://markmail.org/thread/5mans4howfbu2qtg

 But, it is no longer an ATI only bug as I have the following config:
 OSX 10.5.4,  MacBook Pro 15, Nvidia GeForce 9400M, and OSG 2.6.1.
 (The latest macbook pro release)

 The workaround is to strip the '[0]' from the uniform name before
 calling glGetUniformLocation.  I did this by adding the following
 lines right after the call to glGetActiveUniform on line 528 of
 src/osg/Program.cpp:

 // Strip [0] from uniform array name to work around driver bugs
 const int len = strlen(name);
 if (len = 3  name[len-1] == ']')
   name[len-3] = 0;

 I've tested the above fix on a linux box w/ a GeForce 8800 GTX, where
 the bug did not exist in the first place, and it does not break
 anything.

 Now, I agree w/ your statement in the thread: 'One can't use a blanket
 OSG should do all it can to provide workarounds for driver bugs.',
 but isn't this a case where it should make it into the main tree as it
 affects a huge swath of users (all macbook pros) and does not break
 existing functionality?

 Thanks,

 -McKay Davis
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Mac OSX NVIDIA GLSL bug w/ Uniform arrays broken

[McKay Davis]

Robert et al.,

I've run into a driver bug on OSX where all GLSL uniform array
elements are returning a value of 0 in the shader as though they were
not bound.

This is the same bug referenced in this thread:

http://markmail.org/thread/5mans4howfbu2qtg

But, it is no longer an ATI only bug as I have the following config:
OSX 10.5.4,  MacBook Pro 15, Nvidia GeForce 9400M, and OSG 2.6.1.
(The latest macbook pro release)

The workaround is to strip the '[0]' from the uniform name before
calling glGetUniformLocation.  I did this by adding the following
lines right after the call to glGetActiveUniform on line 528 of
src/osg/Program.cpp:

// Strip [0] from uniform array name to work around driver bugs
const int len = strlen(name);
if (len = 3  name[len-1] == ']')
   name[len-3] = 0;

I've tested the above fix on a linux box w/ a GeForce 8800 GTX, where
the bug did not exist in the first place, and it does not break
anything.

Now, I agree w/ your statement in the thread: 'One can't use a blanket
OSG should do all it can to provide workarounds for driver bugs.',
but isn't this a case where it should make it into the main tree as it
affects a huge swath of users (all macbook pros) and does not break
existing functionality?

Thanks,

-McKay Davis
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Mac OS X plugins confusion

[Don Leich]

On Mac OS X *debug* version executables look for  *release* version named 
plug-in shared libraries.


$ osgviewerd cow.osg
Warning: Could not find plugin to read objects from file cow.osg.
osgviewerd: No data loaded

With OSG_NOTIFY_LEVEL=DEBUG...

DynamicLibrary::failed loading osgPlugins-2.7.7/osgdb_osg.so

I worked around the problem by creating links like this

$ ln -s osgdb_osgd.so osgdb_osg.so

for all plugin libraries.  This was seen with a fresh debug only build of 
Friday's 2.7.7 release for Mac OS X.  A similar build on 64-bit Linux did not

exhibit this problem.  Also, nothing to do with out-of-source builds.


-Don Leich

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Mac OS X plugins confusion

[Bob Kuehne]

hi don,

i fixed this by change some cmake to take a different code path so  
that it creates xxxd and osgdb_xxxd.so style names for os x as well as  
other platforms. i forgot to submit this for a while, but will right  
now. watch your osg-submissions channel...


bob

On Dec 16, 2008, at 8:52 PM, Don Leich wrote:

On Mac OS X *debug* version executables look for  *release* version  
named plug-in shared libraries.


$ osgviewerd cow.osg
Warning: Could not find plugin to read objects from file cow.osg.
osgviewerd: No data loaded

With OSG_NOTIFY_LEVEL=DEBUG...

DynamicLibrary::failed loading osgPlugins-2.7.7/osgdb_osg.so

I worked around the problem by creating links like this

$ ln -s osgdb_osgd.so osgdb_osg.so

for all plugin libraries.  This was seen with a fresh debug only  
build of Friday's 2.7.7 release for Mac OS X.  A similar build on 64- 
bit Linux did not

exhibit this problem.  Also, nothing to do with out-of-source builds.


-Don Leich

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Mac OS X plugins confusion

[Don Leich]

Thanks bob.  You've earned these bad band photos (almost as good as bad
album covers)...

  http://www.rockandrollconfidential.com/hall/hall_detail.php?dd_keyid=464

-Don


Bob Kuehne wrote:

hi don,

i fixed this by change some cmake to take a different code path so  that 
it creates xxxd and osgdb_xxxd.so style names for os x as well as  other 
platforms. i forgot to submit this for a while, but will right  now. 
watch your osg-submissions channel...


bob

On Dec 16, 2008, at 8:52 PM, Don Leich wrote:

On Mac OS X *debug* version executables look for  *release* version  
named plug-in shared libraries.


$ osgviewerd cow.osg
Warning: Could not find plugin to read objects from file cow.osg.
osgviewerd: No data loaded

With OSG_NOTIFY_LEVEL=DEBUG...

DynamicLibrary::failed loading osgPlugins-2.7.7/osgdb_osg.so

I worked around the problem by creating links like this

$ ln -s osgdb_osgd.so osgdb_osg.so

for all plugin libraries.  This was seen with a fresh debug only  
build of Friday's 2.7.7 release for Mac OS X.  A similar build on 64- 
bit Linux did not

exhibit this problem.  Also, nothing to do with out-of-source builds.


-Don Leich

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org






___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] MAC

[Robert Osfield]

Hi Don,

Cmake should only build the curl plugin if it finds libcurl installed.
  So I presume that you do have libcurl installed on your system but
an older version perhaps that the OSG can't compile against.

Could you pass on the errors, and information about which version of
libcurl you have installed on your system so we can look at ways of
fix this, even with changes to the source code or the build.

Robert.


On Mon, Dec 8, 2008 at 8:49 PM, Don Leich [EMAIL PROTECTED] wrote:
 I thought maybe it's time to bring this up.  The problem I had building
 cmake on Mac OS X had to do with libcurl.  I got the cmake build past to
 finally complete by turing off some curl specific tests.  The development
 systems I work on are not connected to the Internet and do not get updated
 libraries very often. This may be a factor.  (I also built cmake from
 downloaded source.)

 If even is libcurl is not a prerequisite for OSG is seems that some mention
 of it on the Dependencies page would be helpful.  Many seem to have been
 bitten by libcurl problems.

 -Don Leich


 Raphael Sebbe wrote:



  Re: [osg-users] MAC

 Raphael Sebbe
 Wed, 19 Nov 2008 00:37:11 -0800

 I think it's right in the middle of moving from Xcode based projects to

 cmake build system, which currently generates dylibs instead of frameworks

 (I may not be up to date, checked a couple of weeks ago, moving target).

 Once you get a successful build in cmake, with proper build flags, you

 shouldn't have much surprise on the mac.

 Raphael



 On Wed, Nov 19, 2008 at 1:46 AM, Ulrich Hertlein [EMAIL PROTECTED]wrote:



 Quoting Don Leich [EMAIL PROTECTED]:

  My experience with Mac development has not quite so smooth.  Getting

 cmake to

  build was a battle and beyond the scope of this thread.  OSG itself has

 some

  appearant rough edges with OSG and X11 integration. I am working with



 Odd, it was a complete breeze for me getting OSG/cmake/Makefiles (cmake
 2.6

 from

 DarwinPorts) compiled on OS X.



 I don't know why you have to use X11 (Qt?) but that could be the cause of

 your

 problems.  You'd probably see similar issues running OSG/X11 on Windows.



 /ulrich

 ___

 osg-users mailing list

 osg-users@lists.openscenegraph.org

 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org



 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] MAC

[Don Leich]

Hi Robert,

Too much time has lapsed to reconstruct my exact problems -- too much cursing 
instead of note taking back then. I started with Cmake 2.4.7 that we'd been 
using for Linux OSG builds. It was quickly obvious that version wouldn't do. I 
don't recall how I ended up with cmake 2.6.1 - it was probably the latest stable 
version when I grabbed it, but it was giving me problem after problem.  Just 
lucky I guess.  I later grabbed version 2.6.2 which I can build without a hitch 
and is what I ultimately used to build OSG.


I guess the big problem for me was that the Dependencies page was and still is 
way behind the curve on what's required for building on Mac OSX.  It says CMake 
2.4 or later is prefered.  On Mac specific page there's mention of grabbing the 
SVN version of Cmake for XCode considerations, but nothing more specific about a 
required cmake version.



The Mac (OS X 10.5.2) has libcurl.4.dylib.

I also had a problem building the curl plugin on an i386 Linux system with 
libcurl.2.0.2 .  Other Linux systems here have libcurl.3.0.0 although I haven't 
built on any of these.


-Don


Robert Osfield wrote:

Hi Don,

Cmake should only build the curl plugin if it finds libcurl installed.
  So I presume that you do have libcurl installed on your system but
an older version perhaps that the OSG can't compile against.

Could you pass on the errors, and information about which version of
libcurl you have installed on your system so we can look at ways of
fix this, even with changes to the source code or the build.

Robert.


On Mon, Dec 8, 2008 at 8:49 PM, Don Leich [EMAIL PROTECTED] wrote:


I thought maybe it's time to bring this up.  The problem I had building
cmake on Mac OS X had to do with libcurl.  I got the cmake build past to
finally complete by turing off some curl specific tests.  The development
systems I work on are not connected to the Internet and do not get updated
libraries very often. This may be a factor.  (I also built cmake from
downloaded source.)

If even is libcurl is not a prerequisite for OSG is seems that some mention
of it on the Dependencies page would be helpful.  Many seem to have been
bitten by libcurl problems.

-Don Leich


Raphael Sebbe wrote:




Re: [osg-users] MAC

Raphael Sebbe
Wed, 19 Nov 2008 00:37:11 -0800

I think it's right in the middle of moving from Xcode based projects to

cmake build system, which currently generates dylibs instead of frameworks

(I may not be up to date, checked a couple of weeks ago, moving target).

Once you get a successful build in cmake, with proper build flags, you

shouldn't have much surprise on the mac.

Raphael



On Wed, Nov 19, 2008 at 1:46 AM, Ulrich Hertlein [EMAIL PROTECTED]wrote:





Quoting Don Leich [EMAIL PROTECTED]:



My experience with Mac development has not quite so smooth.  Getting



cmake to



build was a battle and beyond the scope of this thread.  OSG itself has



some



appearant rough edges with OSG and X11 integration. I am working with



Odd, it was a complete breeze for me getting OSG/cmake/Makefiles (cmake
2.6



from



DarwinPorts) compiled on OS X.



I don't know why you have to use X11 (Qt?) but that could be the cause of



your



problems.  You'd probably see similar issues running OSG/X11 on Windows.



/ulrich



___



osg-users mailing list



osg-users@lists.openscenegraph.org



http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org



___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org






___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] MAC

[R Fritz]

In the most recent version of Xcode tools, the 10.4 version of libcurl  
is 7.13.1 and the 10.5 version is 7.16.3.  I believe that OSG by  
default builds against the 10.4 SDK.  Does that help?


[/Developer/SDKs/MacOSX10.4u.sdk]
$ usr/bin/curl-config --features --libs --version
SSL
IPv6
libz
-L/usr/lib -lcurl -lssl -lcrypto -lz
libcurl 7.13.1

[/Developer/SDKs/MacOSX10.5.sdk]
$ usr/bin/curl-config --features --libs --version
SSL
IPv6
libz
NTLM
-lcurl -lssl -lcrypto -lz
libcurl 7.16.3

Randolph

On Dec 9, 2008, at 12:03 PM, Robert Osfield wrote:


On Tue, Dec 9, 2008 at 7:11 PM, Don Leich [EMAIL PROTECTED] wrote:

The Mac (OS X 10.5.2) has libcurl.4.dylib.

I also had a problem building the curl plugin on an i386 Linux  
system with
libcurl.2.0.2 .  Other Linux systems here have libcurl.3.0.0  
although I

haven't built on any of these.


Looks like we need a CMake guru to help out with detecting libcurl  
version.


Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] MAC

[Don Leich]

I thought maybe it's time to bring this up.  The problem I had building cmake on 
Mac OS X had to do with libcurl.  I got the cmake build past to finally complete 
by turing off some curl specific tests.  The development systems I work on are 
not connected to the Internet and do not get updated libraries very often. 
This may be a factor.  (I also built cmake from downloaded source.)


If even is libcurl is not a prerequisite for OSG is seems that some mention of 
it on the Dependencies page would be helpful.  Many seem to have been bitten by 
libcurl problems.


-Don Leich


Raphael Sebbe wrote:




  Re: [osg-users] MAC

Raphael Sebbe
Wed, 19 Nov 2008 00:37:11 -0800

I think it's right in the middle of moving from Xcode based projects to

cmake build system, which currently generates dylibs instead of frameworks

(I may not be up to date, checked a couple of weeks ago, moving target).

Once you get a successful build in cmake, with proper build flags, you

shouldn't have much surprise on the mac.

Raphael



On Wed, Nov 19, 2008 at 1:46 AM, Ulrich Hertlein [EMAIL PROTECTED]wrote:




Quoting Don Leich [EMAIL PROTECTED]:



 My experience with Mac development has not quite so smooth.  Getting



cmake to



 build was a battle and beyond the scope of this thread.  OSG itself has



some



 appearant rough edges with OSG and X11 integration. I am working with







Odd, it was a complete breeze for me getting OSG/cmake/Makefiles (cmake 2.6



from



DarwinPorts) compiled on OS X.







I don't know why you have to use X11 (Qt?) but that could be the cause of



your



problems.  You'd probably see similar issues running OSG/X11 on Windows.







/ulrich



___



osg-users mailing list



osg-users@lists.openscenegraph.org



http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org






___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] MAC

[Eric Sokolowsky]

Wasileski, Bryan J. wrote:

Hi,

 

I’ve not monitored the group mail for a while and was wondering if 
anyone could give me some user/developer experiences of OSG with the Mac.


I was the most recent to push things along with OSG on the Mac. I was 
working a bit with the X11 path and 64-bit compiles, and think it works 
with cmake generating xcode projects. However, things like QT and 
quicktime are not available this way (which means that common image file 
formats are also broken). Eric Wing developed an ImageIO plugin for 
images that I have partially integrated but not yet finished. To get 
animations working on 64-bit a new plugin that uses QTKit needs to be 
developed. For 32-bit compiles all the old stuff should still work. The 
stuff that doesn't work is automatically excluded when a 64-bit platform 
is included in the Xcode generation. Currently the Xcode projects (the 
ones generated by CMake) just make shared libraries. I also intend on 
getting it to generate Frameworks, but that work is not very far along. 
The hand-generated Xcode projects make Frameworks, but I'm not sure if 
they are up-to-date.


There are a lot of permutations on how to build on the Mac. I am 
interested in suggestions on what is broken so it can be improved. The 
way forward is through CMake. The old Xcode projects may or may not 
function, and will probably not be maintained into the future.


As for getting CMake to run on the mac, I downloaded a binary package of 
cmake 2.6.x from CMake's web site, and it just worked for me, with a GUI 
and everything. I didn't try to compile CMake myself, nor use MacPorts 
or any other package repository. I haven't tried to run cmake on the 
command line. I believe that the binary CMake bundle has the 
command-line executables contained within. I usually generate Xcode 
projects from cmake and then compile. This is the easiest way to produce 
a universal binary.


As I was making changes this summer I tried to maintain compatibility 
with 10.4, and even cross-compiling for 10.4 on 10.5. I'm not sure how 
well I succeeded.


Suggestions and questions are welcome.

-Eric
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] MAC

[Raphael Sebbe]

I think it's right in the middle of moving from Xcode based projects to
cmake build system, which currently generates dylibs instead of frameworks
(I may not be up to date, checked a couple of weeks ago, moving target).
Once you get a successful build in cmake, with proper build flags, you
shouldn't have much surprise on the mac.
Raphael

On Wed, Nov 19, 2008 at 1:46 AM, Ulrich Hertlein [EMAIL PROTECTED]wrote:

 Quoting Don Leich [EMAIL PROTECTED]:
  My experience with Mac development has not quite so smooth.  Getting
 cmake to
  build was a battle and beyond the scope of this thread.  OSG itself has
 some
  appearant rough edges with OSG and X11 integration. I am working with

 Odd, it was a complete breeze for me getting OSG/cmake/Makefiles (cmake 2.6
 from
 DarwinPorts) compiled on OS X.

 I don't know why you have to use X11 (Qt?) but that could be the cause of
 your
 problems.  You'd probably see similar issues running OSG/X11 on Windows.

 /ulrich
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] MAC

[Wasileski, Bryan J.]

Hi,

 

I've not monitored the group mail for a while and was wondering if
anyone could give me some user/developer experiences of OSG with the
Mac. 

 

Thanks.

 

 

Bryan

[EMAIL PROTECTED]

 

 

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] MAC

[Gerrick Bivins]

Hi Bryan,
I¹ve been using OSG on Mac for the past year or so and have had no troubles
(except when Apple switched from 10.4 to 10.5 but that was on Apple not
OSG!).
I use cmake to generate Makefiles (linux style) and build from the command
line w/o problems. There is also support for Xcode as well ,but I am
unfamiliar with that route.
Gerrick


On 11/18/08 8:23 AM, Wasileski, Bryan J. [EMAIL PROTECTED] wrote:

 Hi,
  
 I¹ve not monitored the group mail for a while and was wondering if anyone
 could give me some user/developer experiences of OSG with the Mac.
  
 Thanks.
  
  
 Bryan
 [EMAIL PROTECTED]
  
  
 
 
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] MAC

[Ulrich Hertlein]

Quoting Don Leich [EMAIL PROTECTED]:
 My experience with Mac development has not quite so smooth.  Getting cmake to
 build was a battle and beyond the scope of this thread.  OSG itself has some
 appearant rough edges with OSG and X11 integration. I am working with

Odd, it was a complete breeze for me getting OSG/cmake/Makefiles (cmake 2.6 from
DarwinPorts) compiled on OS X.

I don't know why you have to use X11 (Qt?) but that could be the cause of your
problems.  You'd probably see similar issues running OSG/X11 on Windows.

/ulrich
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Mac OS X 10.5 crash in osgText

[Stephan Huber]

Hi Hartmut,

Hartmut Seichter schrieb:
 it crashes always at the same point ... see below
 
 Is there any solution? If so will it be backported to 2.6?

looking into the source and inspecting the stack-trace I would say this
crash has nothing to do with osgText.

It seems that the implementation of GraphicsWindowCarbon::
setWindowDecorationImplementation is the culprit, it removes the opengl
context from the window surface and reattach it again. This is certainly
a no-go when another thread is trying to render stuff into that context.

I marked this behavior as a hack in the source, when I coded the
implementation but I did not find another reliable way to regain access
to the whole space oocupied by the window after removing the titlebar.

I'll try to look into this next week, hopefully there's a slot of spare
time to do it.


cheers,
Stephan


 
 Cheers,
 Hartmut
 
 
 
 
 Process: osgviewer [1487]
 Path:/usr/local/bin/osgviewer
 Identifier:  osgviewer
 Version: ??? (???)
 Code Type:   X86 (Native)
 Parent Process:  bash [183]
 
 Date/Time:   2008-09-11 20:53:13.980 +1200
 OS Version:  Mac OS X 10.5.4 (9E17)
 Report Version:  6
 
 Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
 Exception Codes: KERN_INVALID_ADDRESS at 0x19274010
 Crashed Thread:  2
 
 Thread 0:
 0   libSystem.B.dylib 0x961f84a6 mach_msg_trap + 10
 1   libSystem.B.dylib 0x961ffc9c mach_msg + 72
 2   com.apple.CoreGraphics0x94deab4d _CGSRemoveSurface + 133
 3   com.apple.agl 0x94d1dc56 aglSetDrawable + 448
 4   libosgViewer.44.dylib 0x0017a460
 osgViewer::GraphicsWindowCarbon::setWindowDecorationImplementation(bool)
 + 426
 5   libosgViewer.44.dylib 0x00176ed0
 osgViewer::GraphicsWindow::setWindowDecoration(bool) + 38
 6   libosgViewer.44.dylib 0x00174959
 osgViewer::WindowSizeHandler::changeWindowedResolution(osgViewer::GraphicsWindow*,
 bool) + 1039
 7   libosgViewer.44.dylib 0x0017500c
 osgViewer::WindowSizeHandler::handle(osgGA::GUIEventAdapter const,
 osgGA::GUIActionAdapter) + 670
 8   libosgViewer.44.dylib 0x00126752
 osgGA::GUIEventHandler::handle(osgGA::GUIEventAdapter const,
 osgGA::GUIActionAdapter, osg::Object*, osg::NodeVisitor*) + 38
 9   libosgViewer.44.dylib 0x001192d4
 osgGA::GUIEventHandler::handleWithCheckAgainstIgnoreHandledEventsMask(osgGA::GUIEventAdapter
 const, osgGA::GUIActionAdapter, osg::Object*, osg::NodeVisitor*) + 120
 10  libosgViewer.44.dylib 0x0016a27c
 osgViewer::Viewer::eventTraversal() + 4620
 11  libosgViewer.44.dylib 0x0016eb21
 osgViewer::ViewerBase::frame(double) + 159
 12  libosgViewer.44.dylib 0x0016ea65
 osgViewer::ViewerBase::run() + 239
 13  libosgViewer.44.dylib 0x00161080
 osgViewer::Viewer::run() + 182
 14  osgviewer 0x865b main + 6241
 15  osgviewer 0x6dce start + 54
 
 Thread 1:
 0   libSystem.B.dylib 0x961ff68e __semwait_signal + 10
 1   libSystem.B.dylib 0x9622a36d
 pthread_cond_wait$UNIX2003 + 73
 2   libGLProgrammability.dylib0x93b92432 glvmDoWork + 162
 3   libSystem.B.dylib 0x962296f5 _pthread_start + 321
 4   libSystem.B.dylib 0x962295b2 thread_start + 34
 
 Thread 2 Crashed:
 0   ???   0x121ef200 0 + 304017920
 1   GLEngine  0x00ed531a
 gleDrawArraysOrElements_ExecCore + 266
 2   GLEngine  0x00ed6278
 gleDrawArraysOrElements_IMM_Exec + 1080
 3   libGL.dylib   0x96ddd7f1 glDrawArrays + 113
 4   libosgText.44.dylib   0x002b4d55
 osgText::Text::drawForegroundText(osg::State, osgText::Text::GlyphQuads
 const, osg::Vec4f const) const + 527
 5   libosgText.44.dylib   0x002b5ac0
 osgText::Text::renderOnlyForegroundText(osg::State, osg::Vec4f const)
 const + 118
 6   libosgText.44.dylib   0x002b61bb
 osgText::Text::drawImplementation(osg::State, osg::Vec4f const) const
 + 1117
 7   libosgText.44.dylib   0x002b68f1
 osgText::Text::drawImplementation(osg::RenderInfo) const + 107
 8   libosgViewer.44.dylib 0x00140e72
 osgViewer::TextDrawCallback::drawImplementation(osg::RenderInfo,
 osg::Drawable const*) const + 548
 9   libosgUtil.44.dylib   0x0052082e
 osg::Drawable::draw(osg::RenderInfo) const + 412
 10  libosgUtil.44.dylib   0x00520368
 osgUtil::RenderLeaf::render(osg::RenderInfo, osgUtil::RenderLeaf*) + 266
 11  libosgUtil.44.dylib   0x00516a62
 osgUtil::RenderBin::drawImplementation(osg::RenderInfo,
 osgUtil::RenderLeaf*) + 386
 12  libosgUtil.44.dylib   0x005168dd
 osgUtil::RenderBin::draw(osg::RenderInfo, osgUtil::RenderLeaf*) + 107
 13  libosgUtil.44.dylib   0x00516cbb
 

[osg-users] Mac OS X 10.5 crash in osgText

[Hartmut Seichter]

I seen some other threads mentioning FreeType not being thread save. 
This is OSG 2.6 branch


This is replicable with plain osgviewer on OSX  on a MBP 2.4

To replicate:

export OSG_WINDOW='20 20 800 600'

open osgviewer cow.osg

press 's' to show the stats

with '' and '' go up and down the window resolutions ...

it crashes always at the same point ... see below

Is there any solution? If so will it be backported to 2.6?

Cheers,
Hartmut




Process: osgviewer [1487]
Path:/usr/local/bin/osgviewer
Identifier:  osgviewer
Version: ??? (???)
Code Type:   X86 (Native)
Parent Process:  bash [183]

Date/Time:   2008-09-11 20:53:13.980 +1200
OS Version:  Mac OS X 10.5.4 (9E17)
Report Version:  6

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x19274010
Crashed Thread:  2

Thread 0:
0   libSystem.B.dylib 0x961f84a6 mach_msg_trap + 10
1   libSystem.B.dylib 0x961ffc9c mach_msg + 72
2   com.apple.CoreGraphics0x94deab4d _CGSRemoveSurface + 133
3   com.apple.agl 0x94d1dc56 aglSetDrawable + 448
4   libosgViewer.44.dylib 0x0017a460 
osgViewer::GraphicsWindowCarbon::setWindowDecorationImplementation(bool) 
+ 426
5   libosgViewer.44.dylib 0x00176ed0 
osgViewer::GraphicsWindow::setWindowDecoration(bool) + 38
6   libosgViewer.44.dylib 0x00174959 
osgViewer::WindowSizeHandler::changeWindowedResolution(osgViewer::GraphicsWindow*, 
bool) + 1039
7   libosgViewer.44.dylib 0x0017500c 
osgViewer::WindowSizeHandler::handle(osgGA::GUIEventAdapter const, 
osgGA::GUIActionAdapter) + 670
8   libosgViewer.44.dylib 0x00126752 
osgGA::GUIEventHandler::handle(osgGA::GUIEventAdapter const, 
osgGA::GUIActionAdapter, osg::Object*, osg::NodeVisitor*) + 38
9   libosgViewer.44.dylib 0x001192d4 
osgGA::GUIEventHandler::handleWithCheckAgainstIgnoreHandledEventsMask(osgGA::GUIEventAdapter 
const, osgGA::GUIActionAdapter, osg::Object*, osg::NodeVisitor*) + 120
10  libosgViewer.44.dylib 0x0016a27c 
osgViewer::Viewer::eventTraversal() + 4620
11  libosgViewer.44.dylib 0x0016eb21 
osgViewer::ViewerBase::frame(double) + 159
12  libosgViewer.44.dylib 0x0016ea65 
osgViewer::ViewerBase::run() + 239
13  libosgViewer.44.dylib 0x00161080 
osgViewer::Viewer::run() + 182

14  osgviewer 0x865b main + 6241
15  osgviewer 0x6dce start + 54

Thread 1:
0   libSystem.B.dylib 0x961ff68e __semwait_signal + 10
1   libSystem.B.dylib 0x9622a36d 
pthread_cond_wait$UNIX2003 + 73

2   libGLProgrammability.dylib0x93b92432 glvmDoWork + 162
3   libSystem.B.dylib 0x962296f5 _pthread_start + 321
4   libSystem.B.dylib 0x962295b2 thread_start + 34

Thread 2 Crashed:
0   ???   0x121ef200 0 + 304017920
1   GLEngine  0x00ed531a 
gleDrawArraysOrElements_ExecCore + 266
2   GLEngine  0x00ed6278 
gleDrawArraysOrElements_IMM_Exec + 1080

3   libGL.dylib   0x96ddd7f1 glDrawArrays + 113
4   libosgText.44.dylib   0x002b4d55 
osgText::Text::drawForegroundText(osg::State, osgText::Text::GlyphQuads 
const, osg::Vec4f const) const + 527
5   libosgText.44.dylib   0x002b5ac0 
osgText::Text::renderOnlyForegroundText(osg::State, osg::Vec4f const) 
const + 118
6   libosgText.44.dylib   0x002b61bb 
osgText::Text::drawImplementation(osg::State, osg::Vec4f const) const 
+ 1117
7   libosgText.44.dylib   0x002b68f1 
osgText::Text::drawImplementation(osg::RenderInfo) const + 107
8   libosgViewer.44.dylib 0x00140e72 
osgViewer::TextDrawCallback::drawImplementation(osg::RenderInfo, 
osg::Drawable const*) const + 548
9   libosgUtil.44.dylib   0x0052082e 
osg::Drawable::draw(osg::RenderInfo) const + 412
10  libosgUtil.44.dylib   0x00520368 
osgUtil::RenderLeaf::render(osg::RenderInfo, osgUtil::RenderLeaf*) + 266
11  libosgUtil.44.dylib   0x00516a62 
osgUtil::RenderBin::drawImplementation(osg::RenderInfo, 
osgUtil::RenderLeaf*) + 386
12  libosgUtil.44.dylib   0x005168dd 
osgUtil::RenderBin::draw(osg::RenderInfo, osgUtil::RenderLeaf*) + 107
13  libosgUtil.44.dylib   0x00516cbb 
osgUtil::RenderBin::drawImplementation(osg::RenderInfo, 
osgUtil::RenderLeaf*) + 987
14  libosgUtil.44.dylib   0x00524179 
osgUtil::RenderStage::drawImplementation(osg::RenderInfo, 
osgUtil::RenderLeaf*) + 1005
15  libosgUtil.44.dylib   0x005168dd 
osgUtil::RenderBin::draw(osg::RenderInfo, osgUtil::RenderLeaf*) + 107
16  libosgUtil.44.dylib   0x00526b95 
osgUtil::RenderStage::drawInner(osg::RenderInfo, osgUtil::RenderLeaf*, 
bool) + 363
17  libosgUtil.44.dylib   0x00526799