bug-commoncpp
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Building CC++ on Mac OS X


From: Ian Gough
Subject: RE: Building CC++ on Mac OS X
Date: Mon, 3 Feb 2003 10:38:51 -0500

address@hidden@

Investigated the problem with the compiler not being able to find
lockf() on Mac OS X. So I put in an AC_CHECK_FUNCS rule to check for
lockf(), and to my surprise, autoconf found the function. After looking
at the code generated for the test, I determined that it is not
attempting to find the file in a header, but instead, checking if it
exists in the standard libs. It seems that on Mac OS X, the func is in
the libs and there is a man page, but it is NOT declared in any header
file. Grrr.

I have submitted a bug report to Apple but dunno when it will get fixed.

In the meanwhile, do you think it make sense to attempt to detect if
lockf() is declared in some header file and if not, to declare it if the
autoconf test for the function succeeds?

> -----Original Message-----
> From: Federico Montesino Pouzols 
> [mailto:address@hidden On Behalf Of Federico 
> Montesino Pouzols
> Sent: Friday, January 31, 2003 4:02 AM
> To: Ian Gough
> Cc: 'David Sugar'; 'Federico Montesino Pouzols'; 'bug-commoncpp'
> Subject: Re: Building CC++ on Mac OS X
> 
> 
> 
>       Ah, I have replaced the test with a call to 
> AC_CHECK_FUNCS, which I suspect is what I should have done 
> first instead of using AC_TRY_COMPILE. After all, CHECK_FUNCS 
> is the predefined autoconf macro for this issues.
> 
> On Thu, Jan 30, 2003 at 01:33:00PM -0500, Ian Gough wrote:
> > Wouldn't the C/C++ issue be a general problem for ANY test 
> that uses 
> > AC_TRY_COMPILE?. If you use the C compiler, autoconf cannot detect 
> > missing functionality properly.
> > 
> > Will somebody be making this change or is there an 
> expectation that I 
> > would make the change? Not that I know what file in which 
> to make any 
> > changes. :-)
> > 
> > > -----Original Message-----
> > > From: David Sugar [mailto:address@hidden
> > > Sent: Thursday, January 30, 2003 12:23 PM
> > > To: Ian Gough; 'Federico Montesino Pouzols'
> > > Cc: 'bug-commoncpp'
> > > Subject: Re: Building CC++ on Mac OS X
> > > 
> > > 
> > > The AC_LANG_CPP and AC_LANG_RESTORE options will need to be
> > > used in the 
> > > section that tests for this function.  This will make sure 
> > > they are tested 
> > > with the local machines C++ compiler rather than the C 
> compiler....
> > > 
> > > On Thursday 30 January 2003 11:41, Ian Gough wrote:
> > > > OK, found the problem.
> > > >
> > > > If I call the small sched_getscheduler test program 
> test.c, then 
> > > > it
> > > > compiles with no errors or warnings. If I call the same 
> program but 
> > > > named test.cpp, then gcc complains about an undefined 
> identifier.
> > > >
> > > > The autoconf test creates conftest.c when testing for
> > > > sched_getscheduler (and probably other functions too) 
> and so the 
> > > > compiler never complains about missing functions. Using the 
> > > -std=c99
> > > > options to gcc causes warnings to be reported on the c files.
> > > >
> > > > [commoncpp2 613] cat test.c
> > > > #include <sched.h>
> > > >
> > > > int main ()
> > > > {
> > > >   int policy;
> > > >   policy = sched_getscheduler(0);
> > > >   return 0;
> > > > }
> > > > [commoncpp2 614] cat test.cpp
> > > > #include <sched.h>
> > > >
> > > > int main ()
> > > > {
> > > >   int policy;
> > > >   policy = sched_getscheduler(0);
> > > >   return 0;
> > > > }
> > > > [commoncpp2 615] gcc -c -g -O2 test.cpp
> > > > test.cpp: In function `int main()':
> > > > test.cpp:6: `sched_getscheduler' undeclared (first use this
> > > function)
> > > > test.cpp:6: (Each undeclared identifier is reported only
> > > once for each
> > > > function
> > > >    it appears in.)
> > > > [commoncpp2 616] gcc -c -g -O2 test.c
> > > > [commoncpp2 617]
> > > > [commoncpp2 618] gcc -c -g -O2 -std=c99 test.c
> > > > test.c: In function `main':
> > > > test.c:6: warning: implicit declaration of function
> > > > `sched_getscheduler'
> > > >
> > > > > -----Original Message-----
> > > > > From: Federico Montesino Pouzols
> > > > > [mailto:address@hidden On Behalf Of 
> > > Federico Montesino
> > > > > Pouzols
> > > > > Sent: Wednesday, January 29, 2003 4:18 PM
> > > > > To: Ian Gough
> > > > > Cc: 'bug-commoncpp'
> > > > > Subject: Re: Building CC++ on Mac OS X
> > > > >
> > > > >
> > > > >
> > > > >       Yes, the semaphore stuff is still pending, I 
> expect to fix it 
> > > > > soon. As for the sched_getscheduler issue, it is
> > > weird that
> > > > > it is detected, since the test is like this:
> > > > >
> > > > >         AC_TRY_COMPILE(
> > > > >                 [#include <sched.h>],
> > > > >                 [
> > > > >                 int policy;
> > > > >                 policy = sched_getscheduler(0);
> > > > >                 ],
> > > > >                 [AC_DEFINE(HAVE_SCHED_GETSCHEDULER)])
> > > > >
> > > > >       Could you try to compile on your system a 
> simple C program like 
> > > > > the one above? It should not compile, but it
> > > seems that
> > > > > autoconf is able to succesfully compile it.
> > > > >
> > > > > On Mon, Jan 27, 2003 at 11:10:46AM -0500, Ian Gough wrote:
> > > > > > Grabbed a new CVS snapshot this morning and tried to build
> > > > >
> > > > > after these
> > > > >
> > > > > > changes and I still get compilation failures:
> > > > > >
> > > > > > g++ -DHAVE_CONFIG_H -I. -I. -I../include -I../src
> > > > > > g++ -DCCXX_EXPORT_LIBRARY
> > > > > > -I/usr/local/include -D_GNU_SOURCE -Wall -ansi -pedantic
> > > > >
> > > > > -I../include
> > > > >
> > > > > > -c thread.cpp -MT thread.lo -MD -MP -MF .deps/thread.TPlo
> > > > >
> > > > > -fno-common
> > > > >
> > > > > > -DPIC -o .libs/thread.lo
> > > > > > cc1plus: warning: changing search order for system directory
> > > > > > "/usr/local/include"
> > > > > > cc1plus: warning:   as it has already been specified as 
> > > a non-system
> > > > > > directory
> > > > > > thread.cpp: In constructor `ost::Thread::Thread(int,
> > > long unsigned
> > > > > > int)':
> > > > > > thread.cpp:536: `sched_getscheduler' undeclared (first use 
> > > > > > this
> > > > > > function)
> > > > > > thread.cpp:536: (Each undeclared identifier is reported
> > > > >
> > > > > only once for
> > > > >
> > > > > > each
> > > > > >    function it appears in.)
> > > > > > thread.cpp:554: `sched_getparam' undeclared (first use this
> > > > >
> > > > > function)
> > > > >
> > > > > > make[1]: *** [thread.lo] Error 1
> > > > > > make: *** [all-recursive] Error 1
> > > > > >
> > > > > > Checking if HAVE_SCHED_GETSCHEDULER is defined in one of the
> > > > > > header files shows that it is defined in config.h for 
> > > some reason.
> > > > > >
> > > > > > [/var/root/src/revgen/xGrid/ccxx 552] grep -r HAVE_SCHED *
> > > > > > acconfig.h:#undef HAVE_SCHED_GETSCHEDULER acconfig.h:#ifdef 
> > > > > > HAVE_SCHED_H config.log:#define HAVE_SCHED_H 1 
> > > config.log:#define
> > > > > > HAVE_SCHED_GETSCHEDULER 1
> > > > >
> > > > > config.status:${ac_dA}HAVE_SCHED_H${ac_dB}HAVE_SCHED_H${ac_dC}
> > > > > 1${ac_dD}
> > > > >
> > > > > config.status:${ac_dA}HAVE_SCHED_GETSCHEDULER${ac_dB}HAVE_SCHE
> > > >
> > > > D_GETSCHED
> > > >
> > > > > > ULER${ac_dC}1${ac_dD}
> > > > >
> > > > > config.status:${ac_uA}HAVE_SCHED_H${ac_uB}HAVE_SCHED_H${ac_uC}
> > > > > 1${ac_uD}
> > > > >
> > > > > config.status:${ac_uA}HAVE_SCHED_GETSCHEDULER${ac_uB}HAVE_SCHE
> > > >
> > > > D_GETSCHED
> > > >
> > > > > > ULER${ac_uC}1${ac_uD}
> > > > > > configure:#define HAVE_SCHED_GETSCHEDULER 1
> > > > > > include/cc++/config.h:#define HAVE_SCHED_GETSCHEDULER 1 
> > > > > > include/cc++/config.h:#define HAVE_SCHED_H 1 
> > > > > > include/cc++/config.h:#ifdef HAVE_SCHED_H 
> > > > > > include/cc++/config.tmp:#define HAVE_SCHED_GETSCHEDULER 1 
> > > > > > include/cc++/config.tmp:#define HAVE_SCHED_H 1 
> > > > > > include/cc++/config.tmp:#ifdef HAVE_SCHED_H 
> > > > > > include/config.h:#define HAVE_SCHED_GETSCHEDULER 1 
> > > > > > include/config.h:#define HAVE_SCHED_H 1 
> include/config.h:#ifdef 
> > > > > > HAVE_SCHED_H include/config.h.in:#undef 
> HAVE_SCHED_GETSCHEDULER
> > > > > > include/config.h.in:#undef HAVE_SCHED_H
> > > > > > include/config.h.in:#ifdef HAVE_SCHED_H
> > > > > > m4/ost_pthread.m4:
> > > > >
> > > > > [AC_DEFINE(HAVE_SCHED_GETSCHEDULER)])
> > > > >
> > > > > > m4/ost_pthread.m4:dnl #undef HAVE_SCHED_GETSCHEDULER
> > > > > > m4/ost_pthread.m4:dnl #ifdef HAVE_SCHED_H 
> src/thread.cpp:#ifdef 
> > > > > > HAVE_SCHED_GETSCHEDULER src/thread.cpp:#endif // ifdef 
> > > > > > HAVE_SCHED_GETSCHEDULER
> > > > > >
> > > > > > But /usr/include/sched.h shows that there is no
> > > > >
> > > > > sched_getscheduler()
> > > > >
> > > > > > function.
> > > > > >
> > > > > > #ifndef _SCHED_H_
> > > > > > #define _SCHED_H_
> > > > > >
> > > > > > #include <pthread_impl.h>
> > > > > >
> > > > > > /*
> > > > > >  * Scheduling paramters
> > > > > >  */
> > > > > > #ifndef __POSIX_LIB__
> > > > > > struct sched_param { int sched_priority;  char
> > > > > > opaque[__SCHED_PARAM_SIZE__]; }; #endif
> > > > > >
> > > > > > extern int sched_yield(void);
> > > > > > extern int sched_get_priority_min(int);
> > > > > > extern int sched_get_priority_max(int);
> > > > > > #endif /* _SCHED_H_ */
> > > > > >
> > > > > > I grepped for sched_getscheduler and turned up no 
> hits, so I 
> > > > > > am
> > > > > > not sure why the autoconf system thinks that it exists.
> > > > > >
> > > > > > I then defined __FreeBSD__ to get around this 
> problem, but ran
> > > > > > into another compile problem.
> > > > > >
> > > > > > g++ -DHAVE_CONFIG_H -I. -I. -I../include -D__FreeBSD__ 
> > > > > > g++ -I../src
> > > > > > -DCCXX_EXPORT_LIBRARY -I/usr/local/include -D_GNU_SOURCE
> > > > >
> > > > > -Wall -ansi
> > > > >
> > > > > > -pedantic -I../include -c semaphore.cpp -MT semaphore.lo
> > > > >
> > > > > -MD -MP -MF
> > > > >
> > > > > > .deps/semaphore.TPlo  -fno-common -DPIC -o 
> .libs/semaphore.lo
> > > > > > cc1plus: warning: changing search order for system directory
> > > > > > "/usr/local/include"
> > > > > > cc1plus: warning:   as it has already been specified as 
> > > a non-system
> > > > > > directory
> > > > > > /usr/include/sys/sem.h: In destructor `virtual
> > > > > > ost::Semaphore::~Semaphore()':
> > > > > > /usr/include/sys/sem.h:242: too few arguments to 
> function `int
> > > > > > ost::semctl(int,
> > > > > >    int, int, ost::semun)'
> > > > > > semaphore.cpp:100: at this point in file
> > > > > > /usr/include/sys/sem.h: In member function `int
> > > > > > ost::Semaphore::getValue()':
> > > > > > /usr/include/sys/sem.h:242: too few arguments to 
> function `int 
> > > > > > ost::semctl(int,
> > > > > >    int, int, ost::semun)'
> > > > > > semaphore.cpp:126: at this point in file
> > > > > > make: *** [semaphore.lo] Error 1
> > > > > >
> > > > > > Mac OS X does not seem to have SYSV semaphores and an
> > > > >
> > > > > incomplete set
> > > > >
> > > > > > of POSIX semaphore functions. It does NOT have sem_init and
> > > > > > sem_destroy, but it does have sem_open and sem_close.
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Federico Montesino Pouzols
> > > > > > > [mailto:address@hidden On Behalf Of 
> Federico 
> > > > > > > Montesino Pouzols
> > > > > > > Sent: Wednesday, January 22, 2003 3:20 AM
> > > > > > > To: Ian Gough
> > > > > > > Cc: 'bug-commoncpp'
> > > > > > > Subject: Re: Building CC++ on Mac OS X
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >   Good, I have commited some modifications that
> > > should fix this
> > > > > > > issue.
> > > > > > >
> > > > > > > On Tue, Jan 21, 2003 at 09:47:57AM -0500, Ian Gough wrote:
> > > > > > > > >       Um, I have just looked at this and 
> actually there is
> > > > > > >
> > > > > > > already some
> > > > > > >
> > > > > > > > > autoconf stuff. Could you confirm if, in the 
> config.h of
> > > > > > >
> > > > > > > cc++, the
> > > > > > >
> > > > > > > > > symbol HAVE_SOCKLEN_T is undefined?
> > > > > > > >
> > > > > > > > It is commented out. From include/cc++/config.h
> > > > > > > >
> > > > > > > > #define HAVE_INET_ATON 1
> > > > > > > > #define HAVE_INET_SOCKETS 1
> > > > > > > > #define HAVE_UNIX_SOCKETS 1
> > > > > > > > /* #undef HAVE_SOCKLEN_T */
> > > > > > > > /* #undef HAVE_SYS_LIBCSYS_H */
> > > > > > > > /* #undef HAVE_SYS_STREAM_H */
> > > > > > > > /* #undef HAVE_SYS_POLL_H */
> > > > > > > > /* #undef HAVE_POLL_H */
> > > > > >
> > > > > > _______________________________________________
> > > > > > Bug-commoncpp mailing list
> > > > > > address@hidden
> > > > > > http://mail.gnu.org/mailman/listinfo/bug-commoncpp
> > > >
> > > > _______________________________________________
> > > > Bug-commoncpp mailing list
> > > > address@hidden
> > > > http://mail.gnu.org/mailman/listinfo/bug-commoncpp
> > > 
> > > 
> > 
> > 
> > 
> > _______________________________________________
> > Bug-commoncpp mailing list
> > address@hidden 
> > http://mail.gnu.org/mailman/listinfo/bug-commoncpp
> 





reply via email to

[Prev in Thread] Current Thread [Next in Thread]