Upgrading from dcmtk354

Compilation and installation of DCMTK

Moderator: Moderator Team

Post Reply
Message
Author
OliWe
Posts: 7
Joined: Tue, 2019-12-10, 08:44

Upgrading from dcmtk354

#1 Post by OliWe »

Hi - I've been using dcmtk354 with C++Builder for a long time :wink:
Now I want to upgrade to a newer dcmtk in my projects.
The compiler will be bcc64x (based on clang 15, C++Builder 12.2).
Should I go straight to dcmtk369 or should I use an earlier version?
Are the versions backwards compatible? What changes do I need to make in my own source code? Is there any information about code migration somewhere?

Marco Eichelberg
OFFIS DICOM Team
OFFIS DICOM Team
Posts: 1507
Joined: Tue, 2004-11-02, 17:22
Location: Oldenburg, Germany
Contact:

Re: Upgrading from dcmtk354

#2 Post by Marco Eichelberg »

First of all, there is no documentation that describes all of the API changes from version to version. Some changes are typically necessary from release to release, but in many cases these are relatively small.
Now, DCMTK 3.5.4 is almost 20 years old (it was published in 2005), therefore, it is hard to predict how much you will have to change.
Since Clang 15 is one of the supported compilers for DCMTK 3.6.9, I would indeed go straight to the latest version, it does not make much sense to use an older one.

J. Riesmeier
DCMTK Developer
Posts: 2548
Joined: Tue, 2011-05-03, 14:38
Location: Oldenburg, Germany
Contact:

Re: Upgrading from dcmtk354

#3 Post by J. Riesmeier »

You could also use a tool to create a "ABI/API compatibility report", e.g. as described here: https://lvc.github.io/abi-compliance-checker/

OliWe
Posts: 7
Joined: Tue, 2019-12-10, 08:44

Re: Upgrading from dcmtk354

#4 Post by OliWe »

Thank you for the answers.

I started building dcmtk 3.6.9 with bcc64x using CMake.
Configuration worked without problems.

First build failed with:
Error E2904 C:\PROGRA~2\EMBARC~1\Studio\23.0\lib\clang\15.0.7\include\intrin.h 158(13): conflicting types for '__intrinsic_setjmpex'
int __cdecl _setjmp(jmp_buf);

I realized that in the configuration step cmake generates a ifdef for BORLANDC in osconfig.h.

According to the Embarcadero help, such sections should be removed because they are no longer necessary, see https://blogs.embarcadero.com/practical ... lder-12-2/.

So I removed the #ifdef __BORLANDC__.
Next build was building to files:
liboficonv.a
libofstd.a

and then the building process stopped again, this time with:
Error E4128 D:/GitHub/YACTA_Athens/dcmtk/dcmtk369/dcmtk-3.6.9/oflog/libsrc/timehelp.cc 184(5): no matching function for call to 'gmtime_s'
gmtime_s (&clock, t);

In timehelp.cc I added a
#undef __BORLANDC__
before line 184 (where again a __BORLANDC__ is used)
and then 29 dcmtk libs an 78 executables were build :-)

So, yes the new Embarcadero bcc64x compiler (contained in C++Builder 12.2) can build dcmtk 3.6.9 (nearly) out of the box.

Would be cool if the cmake configuration steps could be changed for the bcc64x in the dcmtk code base - not using ifdef-s for BORLANDC should be enough.

Next I need to integrate the new dcmtk libs in one of my projects - let's see how much code needs to be changed.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest