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
> Playerstage-developers@...
> https://lists.sourceforge.net/lists/listinfo/playerstage-developers
>
|