Compiling dcmtk 3.5.3 on OSX (gcc 4.0)
Moderator: Moderator Team
Compiling dcmtk 3.5.3 on OSX (gcc 4.0)
Hello,
I am trying to build the latest dcmtk (3.5.3) on OS X as the latest version available via fink is 3.5.2 and lacks some new features that I would like to use. Unfortunately I am getting compile errors that I do not know how to correct. I am using gcc 4.0, which I suspect is the issue. Here are the relevant error messages:
c++ -DHAVE_CONFIG_H -DNDEBUG -c -I. -I. -I../include -I../../config/include -I../../ofstd/include \
-O -I/sw/include/libxml2 -I/sw/include -D_REENTRANT -D_XOPEN_SOURCE_EXTENDED -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_BSD_COMPAT -D_OSF_SOURCE -D_POSIX_C_SOURCE=199506L -Wall dcpixseq.cc
/usr/include/bsm/audit.h:219: error: expected %<;%> before '*' token
/usr/include/bsm/audit.h:229: error: expected %<;%> before '*' token
/usr/include/sys/ucred.h:76: error: 'u_long' does not name a type
/usr/include/sys/ucred.h:95: error: 'u_int' does not name a type
/usr/include/sys/attr.h:69: error: 'u_short' does not name a type
/usr/include/sys/attr.h:365: error: 'u_long' does not name a type
/usr/include/sys/attr.h:377: error: 'u_char' does not name a type
make[2]: *** [dcpixseq.o] Error 1
make[1]: *** [libsrc-all] Error 2
make: *** [dcmdata-install] Error 2
I plan to re-install a gcc 3.x compiler to see if this solves my problem, but if in the meantime I'd be grateful if someone who has some experience in the matter can share their thoughts.
Thanks,
Roch
I am trying to build the latest dcmtk (3.5.3) on OS X as the latest version available via fink is 3.5.2 and lacks some new features that I would like to use. Unfortunately I am getting compile errors that I do not know how to correct. I am using gcc 4.0, which I suspect is the issue. Here are the relevant error messages:
c++ -DHAVE_CONFIG_H -DNDEBUG -c -I. -I. -I../include -I../../config/include -I../../ofstd/include \
-O -I/sw/include/libxml2 -I/sw/include -D_REENTRANT -D_XOPEN_SOURCE_EXTENDED -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_BSD_COMPAT -D_OSF_SOURCE -D_POSIX_C_SOURCE=199506L -Wall dcpixseq.cc
/usr/include/bsm/audit.h:219: error: expected %<;%> before '*' token
/usr/include/bsm/audit.h:229: error: expected %<;%> before '*' token
/usr/include/sys/ucred.h:76: error: 'u_long' does not name a type
/usr/include/sys/ucred.h:95: error: 'u_int' does not name a type
/usr/include/sys/attr.h:69: error: 'u_short' does not name a type
/usr/include/sys/attr.h:365: error: 'u_long' does not name a type
/usr/include/sys/attr.h:377: error: 'u_char' does not name a type
make[2]: *** [dcpixseq.o] Error 1
make[1]: *** [libsrc-all] Error 2
make: *** [dcmdata-install] Error 2
I plan to re-install a gcc 3.x compiler to see if this solves my problem, but if in the meantime I'd be grateful if someone who has some experience in the matter can share their thoughts.
Thanks,
Roch
Roch M. Comeau, Ph.D.
Rogue Research Inc.
www.rogue-research.com
Rogue Research Inc.
www.rogue-research.com
-
- OFFIS DICOM Team
- Posts: 1437
- Joined: Tue, 2004-11-02, 17:22
- Location: Oldenburg, Germany
- Contact:
Since you are getting parse errors from system header files such as <bsm/audit.h>, I doubt the problem is really related to DCMTK. It could be a problem with the compiler installation, a header file dependency not resolved by the system header files themselves, or a problem with certain macros such as the ones that enable Single Unix APIs. We don't have access to your OS and compiler combination here, so I can at best guess.
Compiling dcmtk with OS X 10.4 (Tiger)
Hello,
After some investigation and posting to Apple's unix-port forum, I have found what has changed going from OS X 10.3 (gcc 3.3) and 10.4 (gcc 4.0) that was causing dcmtk to not build:
1: In many header files in 10.3 (e.g. types.h, time.h ...), certain typedefs were within a
#ifndef _POSIX_SOURCE
...
#endif
block. These have now changed to
#ifndef _POSIX_C_SOURCE
...
#endif
dcmtk defines _POSIX_C_SOURCE so the typedefs inside these blocks are never declared leading to the errors encountered. As a temporary hack, I altered the header files to change them back to _POSIX_SOURCE, however I don't know what a general and robust solution should be. Is this something that:
A: Should be changed by adding something when I type ./config (to generate different Makefiles
B: Should be changed in the dcmtk source code to update it to the latest version of OS X (there are platform specific things in dcmtk, so this may be valid as well)
C: Should Apple's headers be changes if this was an error somewhere on their part
Any comments would be appreciated.
Regards,
Roch Comeau
After some investigation and posting to Apple's unix-port forum, I have found what has changed going from OS X 10.3 (gcc 3.3) and 10.4 (gcc 4.0) that was causing dcmtk to not build:
1: In many header files in 10.3 (e.g. types.h, time.h ...), certain typedefs were within a
#ifndef _POSIX_SOURCE
...
#endif
block. These have now changed to
#ifndef _POSIX_C_SOURCE
...
#endif
dcmtk defines _POSIX_C_SOURCE so the typedefs inside these blocks are never declared leading to the errors encountered. As a temporary hack, I altered the header files to change them back to _POSIX_SOURCE, however I don't know what a general and robust solution should be. Is this something that:
A: Should be changed by adding something when I type ./config (to generate different Makefiles
B: Should be changed in the dcmtk source code to update it to the latest version of OS X (there are platform specific things in dcmtk, so this may be valid as well)
C: Should Apple's headers be changes if this was an error somewhere on their part
Any comments would be appreciated.
Regards,
Roch Comeau
Roch M. Comeau, Ph.D.
Rogue Research Inc.
www.rogue-research.com
Rogue Research Inc.
www.rogue-research.com
-
- OFFIS DICOM Team
- Posts: 1437
- Joined: Tue, 2004-11-02, 17:22
- Location: Oldenburg, Germany
- Contact:
Thank you for this report, that helps. The compatibility macros mess up compilation with new OS versions now and then and indeed may need manual modification. The problem is that some operating systems require certain macros to be defined in order to declare certain system functions in their header files, other systems hide functions depending on these macros. There are already a number of special cases, and maybe it is time to add another one for MacOS X. The definition of these macros actually happens in config/configure.in:
One could add another section here for *-*-darwin* and define the macros as needed. You should check if there is a setting that works both with OS X 10.3 and 10.4; if not, the section could even be version specific (see how config.guess identifies the system in 10.3 and 10.4). Please note that the changes have to be done consistently in two places in configure.in. You need autoconf 2.53 or newer to re-generate the configure script and header files. A shell script named "autoall" is provided in dcmtk/config to automate this task.
Code: Select all
case "${host}" in
mips-sgi-irix6*)
CXXFLAGS="-D_XOPEN_SOURCE_EXTENDED -D_BSD_SOURCE -D_BSD_COMPAT $CXXFLAGS"
CFLAGS="-D_XOPEN_SOURCE_EXTENDED -D_BSD_SOURCE -D_BSD_COMPAT $CFLAGS"
;;
*-*-openbsd3*)
CXXFLAGS="-D_POSIX_C_SOURCE=199506L $CXXFLAGS"
CFLAGS="-D_POSIX_C_SOURCE=199506L $CFLAGS"
;;
*)
CXXFLAGS="-D_XOPEN_SOURCE_EXTENDED -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_BSD_COMPAT -D_OSF_SOURCE -D_POSIX_C_SOURCE=199506L $CXXFLAGS"
CFLAGS="-D_XOPEN_SOURCE_EXTENDED -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_BSD_COMPAT -D_OSF_SOURCE -D_POSIX_C_SOURCE=199506L $CFLAGS"
;;
esac
Solution for compiling dcmtk 3.5.3 on OSX 10.4 with gcc 4.0
With the following settings in the configure.in file, dcmtk 3.5.3 compiles and works for us on OSX v. 10.4 with gcc 4.0:
After changing the configure.in file, we ran "autoall" as Marco wrote in his post.
Note: This is only for OSX 10.4.0 (darwin8.0.0) since dcmtk 3.5.3 did compile on OSX 10.3 without any changes. When 10.4.1 will be released the change in configure.in might no longer be needed or might need to be updated to "*-*-darwin8.*)".
Jens Breitenborn
MeVis Diagnostics
Code: Select all
*-*-darwin8.0.0)
CXXFLAGS="-D_XOPEN_SOURCE_EXTENDED -D_BSD_SOURCE -D_BSD_COMPAT -D_OSF_SOURCE $CXXFLAGS"
CFLAGS="-D_XOPEN_SOURCE_EXTENDED -D_BSD_SOURCE -D_BSD_COMPAT -D_OSF_SOURCE $CFLAGS"
;;
Note: This is only for OSX 10.4.0 (darwin8.0.0) since dcmtk 3.5.3 did compile on OSX 10.3 without any changes. When 10.4.1 will be released the change in configure.in might no longer be needed or might need to be updated to "*-*-darwin8.*)".
Jens Breitenborn
MeVis Diagnostics
Hello,
I have not checked back for a while because I assumed that the e-mail notification would let me now if there was another response. I guess that only applies if an offis member replies.
Anyway, jens, your solution worked for me as well, thank you very much! I used "*-*-darwin8.*)" as I am running 10.4.1. Is there any way this can be added to the next official release?
Thanks again,
Roch Comeau
I have not checked back for a while because I assumed that the e-mail notification would let me now if there was another response. I guess that only applies if an offis member replies.
Anyway, jens, your solution worked for me as well, thank you very much! I used "*-*-darwin8.*)" as I am running 10.4.1. Is there any way this can be added to the next official release?
Thanks again,
Roch Comeau
Roch M. Comeau, Ph.D.
Rogue Research Inc.
www.rogue-research.com
Rogue Research Inc.
www.rogue-research.com
-
- OFFIS DICOM Team
- Posts: 1437
- Joined: Tue, 2004-11-02, 17:22
- Location: Oldenburg, Germany
- Contact:
Compiling dcmtk with OS X 10.4 (Tiger)
Marco,
Thank you for the reply and the fix!
Regards,
Roch Comeau
Thank you for the reply and the fix!
Regards,
Roch Comeau
Roch M. Comeau, Ph.D.
Rogue Research Inc.
www.rogue-research.com
Rogue Research Inc.
www.rogue-research.com
-
- Posts: 1
- Joined: Sun, 2010-11-21, 14:33
Re: Compiling dcmtk with OS X 10.4 (Tiger)
Marco.rcomeau wrote:Marco,
Thank you for the reply and the fix for https://affmountain.com/my-wealthy-affi ... nd-results the Wealthy Affiliate!
Regards,
Roch Comeau
Who is online
Users browsing this forum: No registered users and 1 guest