Upgrading from dcmtk354

[OliWe]

Hi - I've been using dcmtk354 with C++Builder for a long time
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]

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]

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]

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.

[Marco Eichelberg]

Thanks for letting us know. I will put it on the to-do-list to remove the __BORLANDC__ #ifdefs, which were intended for a rather ancient version of Borland C++.

[OliWe]

Thx.

addition:
To implement compiler specific code for the new bcc64x this should be used:

#if defined(__BORLANDC__) && defined(_WIN64) && defined(__MINGW64__)

e.g. I used in another library where I am not using Cmake this in the inital cpp-file:

#if defined(__BORLANDC__) && defined(_WIN64) && defined(__MINGW64__)
#undef __BORLANDC__
#endif

and it did the trick.