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: Federico Montesino Pouzols
Subject: Re: Building CC++ on Mac OS X
Date: Fri, 31 Jan 2003 10:02:20 +0100
User-agent: Mutt/1.4i

        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__ -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]