You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-users@xerces.apache.org by Mark Roberts <mr...@barkinglizards.com> on 2008/04/10 01:07:36 UTC
Build problem with threading libraries on FreeBSD
Hello Everyone,
I was in the midst of building xerces-c 2.8.0 from source on FreeBSD 7.0 and
ran into a problem. I found that the runConfigure script fails with this
message while testing gcc:
-------------------
$./runConfigure -pfreebsd -cgcc -xg++ -minmem -nsocket -tIconvFBSD -rpthread
-s
Generating makefiles with the following options ...
Platform: freebsd
C Compiler: gcc
C++ Compiler: g++
Message Loader: inmem
Net Accessor: socket
Transcoder: IconvFBSD
Thread option: pthread
Library type: static
bitsToBuild option: 32
Extra compile options:
Extra link options:
Extra configure options:
Debug is OFF
checking for gcc... gcc
checking for C compiler default output file name...
configure: error: C compiler cannot create executables
See `config.log' for more details.
-------------------
Looking at config.log shows the real problem:
-------------------
configure:2083: checking for C compiler default output file name
configure:2110: gcc -w -O -DNDEBUG -DPROJ_XMLPARSER -DPROJ_XMLUTIL
-DPROJ_PARSERS -DPROJ_SAX4C -DPROJ_SAX2 -DPROJ_DOM -DPROJ_DEPRECATED_DOM
-DPROJ_VALIDATORS -DXML_USE_LIBICONV -I/usr/local/include
-DXML_USE_INMEM_MESSAGELOADER -D_THREAD_SAFE -DXML_USE_PTHREADS
-DXML_USE_NETACCESSOR_SOCKET conftest.c -pthread -lc_r >&5
/usr/bin/ld: cannot find -lc_r
configure:2113: $? = 1
configure:2151: result:
configure: failed program was:
| /* confdefs.h. */
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:2158: error: C compiler cannot create executables
-------------------
It turns out that libc_r could not be found. After a bit more research, it
sounds like (correct me if I'm wrong) libc_r has been deprecated on FreeBSD
since version 5.X and removed from version 7.0. I edited runConfigure (line
358) to not include "-lc_r" in the list of threading libraries to use for
FreeBSD and was able to build just fine.
Side note: This has also caused problems for us on FreeBSD 6.X because
xerces ends up being linked to both pthread and libc_r, which produced
runtime errors in our app ("Fatal error 'Spinlock called when not
threaded.'"). A similar change resolved this problem as well.
So, here is my question: runConfigure's behavior seems misleading to me. I
used the "-rpthread" option for runConfigure and yet "-pthread -lc_r" is
still given to configure and eventually xerces will be linked to both of
these libraries. Should this be changed now that libc_r is either deprecated
or no longer available on supported versions of FreeBSD?
If nothing else, I figured I would share my experience in case anyone is
having similar issues.
Thanks!
Mark Roberts
Re: Build problem with threading libraries on FreeBSD
Posted by Alberto Massari <am...@datadirect.com>.
Hi Mark,
the runConfigure script builds this command line options for FreeBSD
elif test $platform = "freebsd"; then
threadingLibs="-pthread -lc_r"
threadingDefines="-D_THREAD_SAFE -DXML_USE_PTHREADS"
Can you suggest a patch that works on both FreeBSD 5.x and FreeBSD 7.x?
Thanks,
Alberto
Mark Roberts wrote:
> Hello Everyone,
>
> I was in the midst of building xerces-c 2.8.0 from source on FreeBSD 7.0 and
> ran into a problem. I found that the runConfigure script fails with this
> message while testing gcc:
>
> -------------------
> $./runConfigure -pfreebsd -cgcc -xg++ -minmem -nsocket -tIconvFBSD -rpthread
> -s
>
> Generating makefiles with the following options ...
> Platform: freebsd
> C Compiler: gcc
> C++ Compiler: g++
> Message Loader: inmem
> Net Accessor: socket
> Transcoder: IconvFBSD
> Thread option: pthread
> Library type: static
> bitsToBuild option: 32
> Extra compile options:
> Extra link options:
> Extra configure options:
> Debug is OFF
>
> checking for gcc... gcc
> checking for C compiler default output file name...
> configure: error: C compiler cannot create executables
> See `config.log' for more details.
> -------------------
>
> Looking at config.log shows the real problem:
>
> -------------------
> configure:2083: checking for C compiler default output file name
> configure:2110: gcc -w -O -DNDEBUG -DPROJ_XMLPARSER -DPROJ_XMLUTIL
> -DPROJ_PARSERS -DPROJ_SAX4C -DPROJ_SAX2 -DPROJ_DOM -DPROJ_DEPRECATED_DOM
> -DPROJ_VALIDATORS -DXML_USE_LIBICONV -I/usr/local/include
> -DXML_USE_INMEM_MESSAGELOADER -D_THREAD_SAFE -DXML_USE_PTHREADS
> -DXML_USE_NETACCESSOR_SOCKET conftest.c -pthread -lc_r >&5
> /usr/bin/ld: cannot find -lc_r
> configure:2113: $? = 1
> configure:2151: result:
> configure: failed program was:
> | /* confdefs.h. */
> | #define PACKAGE_NAME ""
> | #define PACKAGE_TARNAME ""
> | #define PACKAGE_VERSION ""
> | #define PACKAGE_STRING ""
> | #define PACKAGE_BUGREPORT ""
> | /* end confdefs.h. */
> |
> | int
> | main ()
> | {
> |
> | ;
> | return 0;
> | }
> configure:2158: error: C compiler cannot create executables
> -------------------
>
> It turns out that libc_r could not be found. After a bit more research, it
> sounds like (correct me if I'm wrong) libc_r has been deprecated on FreeBSD
> since version 5.X and removed from version 7.0. I edited runConfigure (line
> 358) to not include "-lc_r" in the list of threading libraries to use for
> FreeBSD and was able to build just fine.
>
> Side note: This has also caused problems for us on FreeBSD 6.X because
> xerces ends up being linked to both pthread and libc_r, which produced
> runtime errors in our app ("Fatal error 'Spinlock called when not
> threaded.'"). A similar change resolved this problem as well.
>
> So, here is my question: runConfigure's behavior seems misleading to me. I
> used the "-rpthread" option for runConfigure and yet "-pthread -lc_r" is
> still given to configure and eventually xerces will be linked to both of
> these libraries. Should this be changed now that libc_r is either deprecated
> or no longer available on supported versions of FreeBSD?
>
> If nothing else, I figured I would share my experience in case anyone is
> having similar issues.
>
> Thanks!
>
>
> Mark Roberts
>
>