From: Richard v. <va...@cs...> - 2005-10-15 21:14:26
|
Folks, Some pretty important parts of Player now rely on boost. Installing boost by hand is a pain, it's only available in the Fink unstable tree, and even after I spent an hour downloading and compiling it, a fresh check out of Player can't detect it. It's really not fun to have to jump through these hoops to run playerjoy or laserobstacleavoid I moved playerprint to libplayerc last week for the same reason. Questions: Has anyone managed to get the new C++ client libs to compile on OS X? How did you do it? Do we really need this dependency on software which is not standard on current systems, uses a weird installation method, and doesn't freakin' work on my vanilla OS X/Fink box? I just wasted a big chunk of a saturday. Richard/ |
From: Richard v. <va...@cs...> - 2005-10-15 21:48:29
|
I apologize for the lack of tact in my earlier post. I wouldn't be surprised if offended Brad and possibly others. Not cool of me, sorry. I still can't build libplayerc++, but I wish I'd asked for help in a less grumpy way. best, Richard/ On 15-Oct-05, at 2:14 PM, Richard vaughan wrote: > > Folks, > > Some pretty important parts of Player now rely on boost. Installing > boost by hand is a pain, it's only available in the Fink unstable > tree, and even after I spent an hour downloading and compiling it, > a fresh check out of Player can't detect it. It's really not fun to > have to jump through these hoops to run playerjoy or > laserobstacleavoid I moved playerprint to libplayerc last week for > the same reason. > > Questions: > > Has anyone managed to get the new C++ client libs to compile on OS > X? How did you do it? > > Do we really need this dependency on software which is not standard > on current systems, uses a weird installation method, and doesn't > freakin' work on my vanilla OS X/Fink box? > > I just wasted a big chunk of a saturday. > > Richard/ > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, > discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > |
From: Brad K. <bkr...@et...> - 2005-10-15 23:01:33
|
Richard vaughan wrote: > I apologize for the lack of tact in my earlier post. I wouldn't be > surprised if offended Brad and possibly others. Not cool of me, sorry. > > I still can't build libplayerc++, but I wish I'd asked for help in a > less grumpy way. No offense taken. I guess this is why the CVS version is currently considered unstable :p I didn't realize it was going to be this much of a pain to install. I use Debain here and so it's just a simple apt-get away. I've also downloaded and compiled boost before and didn't have a problem. > Has anyone managed to get the new C++ client libs to compile on OS X? > How did you do it? I found a install guide for boost that listed OS X. Are you sure threads are enabled? http://interreality.org/static/docs/manual-html/boost.html Could you be more specific about the errors you're running into? I've seen a number of posts online that seem to have boost working on OS X. On the boost website, they have a list of all the compilers/systems that they regularly test on at: http://engineering.meta-comm.com/boost-regression/1_33_0/user/summary.html > even after I spent an hour downloading and compiling it, a fresh > check out of Player can't detect it. Is it not detecting both the signal and the thread libraries? I had to look a little to get the check working in Linux. It seems that on Posix systems, you need to have the following defines defined for the compiler to work. -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT In the acinclude.m4 file, the test for BOOST_THREAD checks to make sure it can compile a small program w/ boost. To do that, I have to first set the compiler flags, then I can use AC_LANG_PROGRAM to test for it. After a little searching, I found that OS X doesn't require those two defines, but ... >it complains about not having the necessary compiler flags when >compiling the threading library in devel/boost-libs. I.e. it's asking >for something like -pthread, but this isn't required on OS X. >The problem is that BOOST_HAS_THREADS doesn't get defined during configuration and it fails only because it lacks that definition. taken from http://mail-index.netbsd.org/pkgsrc-bugs/2005/06/14/0017.html So, maybe you just need to define BOOST_HAS_THREADS on OS X and it will work (I hope). Otherwise, it may be good to just adjust the check so that it allows libplayerc++ to be compiled and see what happens. If so, then we at least know boost works and I need to write a better check macro. If not, see the next segment... > Do we really need this dependency on software which is not standard > on current systems, uses a weird installation method, and doesn't > freakin' work on my vanilla OS X/Fink box? Right now, I'm using the boost stuff to handle signaling and the new multithreaded aspects of libplayerc++. They have quite a few libraries that are really handy for this sort of thing. Considering their mission of trying to write code that works well with standard C++, I'm surprised there's that much problem getting it installed. It could be due to the multithreading stuff though. I've been debating changing the compilation to be able to selectively include boost or not. That way, people could still have the c++ library and not. Before choosing boost to take care of signaling I also took a look at some other signaling libraries. I ended up choosing boost because it seemed to be very standards complient and the api was well designed. At the time, it seemed like the best option to build into the API (and I still think it is). I've put a fair amount of work into libplayerc++, but if some aspects of it don't work for everyone, we'll have to make some changes. I'm open to suggestions. I'll also see if I can rustle up an OS X box to test on. -bk |
From: Richard v. <va...@cs...> - 2005-10-16 00:08:12
|
Thanks for your help, Brad. Boost seems to install OK under OS X/Fink (unstable). But Player doesn't find any of it: $ ./configure ... checking whether the compiler implements namespaces... yes checking whether the Boost::Thread library is available... no checking for main in -lboost_thread... no checking for main in -lboost_thread-mt... no checking whether the Boost::Signal library is available... no checking for main in -lboost_signals... no ... I've spent a few hours tinkering and I really can't face any more today, but some important chunks of Player are broken on OS X until this problem is solved. OS X is a minority platform, but lots of us use it every day. It would be great if you could have a go at fixing this. In general, major changes - no matter how well motivated - to objects high up in Player's dependency tree should be checked in on a branch until they've been tested on the major platforms. cheers, Richard/ On 15-Oct-05, at 4:01 PM, Brad Kratochvil wrote: > Richard vaughan wrote: > > >> I apologize for the lack of tact in my earlier post. I wouldn't >> be surprised if offended Brad and possibly others. Not cool of >> me, sorry. >> >> I still can't build libplayerc++, but I wish I'd asked for help in >> a less grumpy way. >> > > No offense taken. I guess this is why the CVS version is currently > considered unstable :p I didn't realize it was going to be this > much of a pain to install. I use Debain here and so it's just a > simple apt-get away. I've also downloaded and compiled boost > before and didn't have a problem. > >> Has anyone managed to get the new C++ client libs to compile on OS >> X? How did you do it? >> > > I found a install guide for boost that listed OS X. Are you sure > threads are enabled? > http://interreality.org/static/docs/manual-html/boost.html > > Could you be more specific about the errors you're running into? > I've seen a number of posts online that seem to have boost working > on OS X. On the boost website, they have a list of all the > compilers/systems that they regularly test on at: > > http://engineering.meta-comm.com/boost-regression/1_33_0/user/ > summary.html > > >> even after I spent an hour downloading and compiling it, a fresh >> check out of Player can't detect it. >> > > Is it not detecting both the signal and the thread libraries? I > had to look a little to get the check working in Linux. It seems > that on Posix systems, you need to have the following defines > defined for the compiler to work. > > -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT > > In the acinclude.m4 file, the test for BOOST_THREAD checks to make > sure it can compile a small program w/ boost. To do that, I have > to first set the compiler flags, then I can use AC_LANG_PROGRAM to > test for it. After a little searching, I found that OS X doesn't > require those two defines, but ... > > >it complains about not having the necessary compiler flags when > >compiling the threading library in devel/boost-libs. I.e. it's asking > >for something like -pthread, but this isn't required on OS X. > >The problem is that BOOST_HAS_THREADS doesn't get defined during > configuration and it fails only because it lacks that definition. > taken from http://mail-index.netbsd.org/pkgsrc-bugs/ > 2005/06/14/0017.html > > So, maybe you just need to define BOOST_HAS_THREADS on OS X and it > will work (I hope). Otherwise, it may be good to just adjust the > check so that it allows libplayerc++ to be compiled and see what > happens. If so, then we at least know boost works and I need to > write a better check macro. If not, see the next segment... > > >> Do we really need this dependency on software which is not >> standard on current systems, uses a weird installation method, >> and doesn't freakin' work on my vanilla OS X/Fink box? >> > > Right now, I'm using the boost stuff to handle signaling and the > new multithreaded aspects of libplayerc++. They have quite a few > libraries that are really handy for this sort of thing. > Considering their mission of trying to write code that works well > with standard C++, I'm surprised there's that much problem getting > it installed. It could be due to the multithreading stuff though. > I've been debating changing the compilation to be able to > selectively include boost or not. That way, people could still > have the c++ library and not. > > Before choosing boost to take care of signaling I also took a look > at some other signaling libraries. I ended up choosing boost > because it seemed to be very standards complient and the api was > well designed. At the time, it seemed like the best option to > build into the API (and I still think it is). I've put a fair > amount of work into libplayerc++, but if some aspects of it don't > work for everyone, we'll have to make some changes. I'm open to > suggestions. I'll also see if I can rustle up an OS X box to test on. > > -bk > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, > discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > |
From: Brad K. <bkr...@et...> - 2005-10-16 06:51:46
|
Richard vaughan wrote: > > Thanks for your help, Brad. > > Boost seems to install OK under OS X/Fink (unstable). But Player > doesn't find any of it: > > $ ./configure > ... > checking whether the compiler implements namespaces... yes > checking whether the Boost::Thread library is available... no > checking for main in -lboost_thread... no > checking for main in -lboost_thread-mt... no > checking whether the Boost::Signal library is available... no > checking for main in -lboost_signals... no > ... Can you send me the config.log when you configure? That should tell me what's failing. > I've spent a few hours tinkering and I really can't face any more > today, but some important chunks of Player are broken on OS X until > this problem is solved. OS X is a minority platform, but lots of us > use it every day. It would be great if you could have a go at fixing > this. Will do, I just have to find an OS X machine. > In general, major changes - no matter how well motivated - to > objects high up in Player's dependency tree should be checked in on a > branch until they've been tested on the major platforms. The thing was with this particular example, is that with Player v 2.0 we didn't have a C++ api, so I figured it couldn't be any more broken than it currently was. In lieu of putting this all into a seperate branch (now), I'll just add conditions to the code which will conditionally build in the multithreading/signaling. Then, if you don't want to use boost, you don't have too. Sorry for ruining your Saturday, -bk |
From: Brad K. <bkr...@et...> - 2005-10-17 09:52:34
|
All the boost stuff should now be optionally compiled in and give you annoucements to that effect in the configure script. I tested this on a machine w/out boost, a machine w/ only the boost_signals library, and a machine with both the threading and signaling libraries. To the best of my knowledge the only utils that use libplayerc++ are currently playerprint and player joy, so I updated their Makefiles. If you're still interested in getting the boost stuff to work on OS X, I'm willing to help, but I haven't found a machine I can test on here. So, I'd need your help. -bk |