Well, I'm having a problem with dcmtk + dcmprint where there are LNK2019 errors even if you don't have anything in my main, dcmtk's include's are enought to throw errors. I read that this can be generated by the lack of libs in the linker or by their order, but I think i have this part right. I'm going to add some prints of my code and the linker.
If you detect something wrong, please correct me.
Looking forward your reply. Thanks!
The error message indeed indicates that the linker cannot resolve some symbols, either because a library is missing, or because the link order is incorrect.
The symbols reported in the error message are present in the ofstd library (ofstd.lib), and I cannot see that library in the list of library dependencies in your screenshot, so perhaps you simply need to add this.
The symbols reported in the error messages somewhere in the lower part of the screenshot are related to oflog.lib, which may also be missing.
As a rule of thumb, when working with DCMTK you will always need to link against ofstd.lib and oflog.lib, since these provide basic functions that are used everywhere in the toolkit.
And yes, you are right: Including header files can be enough to create library dependencies. That is a typical C++ feature that you probably won't find in pure C code.
Possible. You might want to check the command line options used to build DCMTK and compare these with the settings of your own project. There are some command line options that are mutually incompatible, such as /Gd, /Gr, /Gv, /Gz, which change the calling conventions (e.g. __thiscall, __fastcall, __stdcall) for functions.
Marco Eichelberg wrote: ↑Tue, 2021-04-06, 15:30
Possible. You might want to check the command line options used to build DCMTK and compare these with the settings of your own project. There are some command line options that are mutually incompatible, such as /Gd, /Gr, /Gv, /Gz, which change the calling conventions (e.g. __thiscall, __fastcall, __stdcall) for functions.
I already fixed this by recompilind all libs with the "shared libs option" off and "overwrite flags" off and is running but im having a problem while connecting to it using your client.
The print server uses two TCP ports, one for DICOM communication and one for inter-process communication (although the latter one is not really needed in the Windows version). The error message indicates that "somebody" has connected to the IPC port instead of the DICOM port.
