Jean-François Mertens wrote: > Could you please have a look at pwlib1 on 10.5 ? > I'm committing now, thanks to your msg, a small > additional item, that should fix Alexander's psetgrp issue > on 10.5 w/o change on 10.4.
OK, I tried, although I hope I shall never be in a situation where I will need this pwlib1 thing. On 10.5 it fails to build with > tlibthrd.cxx:1565: error: ISO C++ forbids comparison between > pointer and integer Note that this is the version where this line is *not* patched. > There is an additional (10.5) possible issue about semaphores, [] > It just implies that he thinks that on his system the equivalent > of an additional line in the patchscript like (exactly) : >> sed -ri.bak -e '/SEM_FAILED/s,\(int\),,' src/ptlib/unix/tlibthrd.cxx > > might _ help ? be usefull ? be needed ?? > > The whole thing concerns lines 1548 to 1568 in src/ptlib/unix/ > tlibthrd.cxx > (and /usr/include/sys/semaphore.h ). The (visible) difference between 10.4 and 10.5 is the following: In /usr/include/sys/semaphore.h: 10.4: #define SEM_FAILED -1 10.5: #define SEM_FAILED ((sem_t *)-1) Since this is a return value of the sem_open function, it is possible that that function has also changed, although both 10.4 and 10.5 man pages give its type as sem_t *. As you observed, the posix standard on this point is confused. Perhaps until 10.4 Apple simply relied on the fact that gcc used to allow comparison of pointers and integers. I am not sure how the more anal gcc that we now have can be made to accept both versions. Maybe instead of the present upstream ((int)sem != SEM_FAILED) which fails on 10.5, or the proposed (sem != SEM_FAILED) which fails on 10.4, one could use ((int)sem != (int)SEM_FAILED) or (sem != (sem_t *)SEM_FAILED) Google shows <http://paulbeachsblog.blogspot.com/2007/12/building-firebird-20x-macos-semaphoreh.html> where they propose the latter in a similar situation. [] > _ but, according to http://www.opengroup.org/onlinepubs/000095399/ > functions/sem_open.html, > SEM_FAILED is the \emph{value} (as opposed to "address" there) > returned by sem_open in case of failure, > so there might be some logic in that no coercion should be needed, > when taking things literally. > Of course, I don't see how they could implement easily (or jjust > declare..) in C a function that returns > in one case a value and otherwise a pointer. Note how the posix guys carefully avoid giving the definition of SEM_FAILED... -- Martin ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Fink-users mailing list Fink-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-users
