[22704] Link problem with MinGW

[RookieCLY]

Is there an already existing issue for this?

• I have searched the existing issues

Expected behavior

I have already compile foonathan_memory, fastcdr and tinyxml2 with MinGW successfully. But there are some problem when I compile the fastdds with MinGW, like "i64 to LL","stat redefined","declspec( dllexport ) to attribute((visibility("default")))"...... I used some special means to solve these problems and finally successfully compiled fastdds, then i got libfastdds.dll and libfastdds.dll.a

Current behavior

But when I use libfastdds.dll and libfastdds.dll.a in my project, there are some thing wrong like
E:/mingw32-14/bin/../lib/gcc/i686-w64-mingw32/14.2.0/../../../../i686-w64-mingw32/bin/ld.exe: CMakeFiles\MBus.dir/objects.a(startlogPubSubTypes.cxx.obj):startlogPubSubTypes.cxx:(.text+0x5cd): undefined reference to eprosima::fastdds::MD5::MD5()'`......
All the symbol from FastDDS which i used in my project was undefined. I tried every import and export combination in fastdds_dll.hpp, "attribute((visibility("default")))" "declspec( dllexport )" "declspec( dllimport )" "null" . But does not work.
Are there some special export config for MinGW in FastDDS?

Steps to reproduce

1:Compile foonathan_memory, fastcdr and tinyxml2 with MinGW.
2:Modify the source code, like modify CMAKE_CXX_FLAGS, modify include in some files, and so on.
3:Use libfastdds.dll.a in your project.

Fast DDS version/commit

FastDDS v3.1.1 master
FastCDR v2.2.5
MinGW v14.2.0
Windows10

Platform/Architecture

Other. Please specify in Additional context section.

Transport layer

Default configuration, UDPv4 & SHM

Additional context

No response

XML configuration file

No response

Relevant log output

No response

Network traffic capture

No response

[Javgilavi]

Hi @RookieCLY,

Can you share more details on the errors that you had when compiling fastdds? And what were the "solution means" that you did?

[RookieCLY]

@Javgilavi
Yes, my pleasure. “solution means” can be divided into three parts.
First, warning with little impact. like "unused-parameter" "missing-field-initializers" and so on. I just use command like "-Wno-unused-parameter" to ignore them.
Then, some llibrary error between windows and unix. Added option for "elif defined(MINGW)" to ifdef _WIN32(or _MSC_VER) and else , then fill the MINGW branch, so it can work as same as the _WIN32(or _MSC_VER) branch. For example, in "RobustExclusiveLock.hpp", add "elif defined(MINGW)" to ifdef _MSC_VER and else in the "include" block and "class" block. Then copy the code from "_MSC_VER" block, use the same function "_sopen_s" with <io.h>(MinGW), modify "_SH_DENYRW" to "0x0010", which is not defined in <io.h>(MinGW).
Third, Manually link library, like "target_link_libraries(fastdds PUBLIC ws2_32 mswsock)".

As for the error in this issue, I solved this problem with "declspec( dllexport )" and "-Wno-attributes". So i can use almost all the symbols from libfastdds.dll and libfastdds.dll.a.
Why "almost all"? There are some new problem for "TypeSupport".
When I use TypeSupport(new startlogPubSubType()) to construct a TypeSupport object, i got the error
E:/mingw32-14/bin/../lib/gcc/i686-w64-mingw32/14.2.0/../../../../i686-w64-mingw32/bin/ld.exe: C:\Users\CUILIU~1\AppData\Local\Temp\ccEr7V0I.o:xmsgbus.cxx:(.text$_ZN8eprosima7fastdds3dds11TypeSupportC1EPNS1_13TopicDataTypeE[__ZN8eprosima7fastdds3dds11TypeSupportC1EPNS1_13TopicDataTypeE]+0x20): undefined reference to "vtable for eprosima::fastdds::dds::TypeSupport"
Maybe there are some thing wrong with "class TypeSupport : public std::shared_ptr<TopicDataType>" and MinGW?
By the way, "startlogPubSubType" was generated by fastdds-gen with a idl.

[Javgilavi]

Hi again @RookieCLY,

Currently, MinGW is not officially supported, and it's highly probable your issue is related to that.

At first, seams like maybe after the changes you made for compiling, an export can be missing on TypeSupport.
But has I said, MinGW is not currently support.
If you manage to fix the problem, fill free to make a PR.

For further help, please contact us directly to [email protected] for further work on this issue if this is a need for your project.

[RookieCLY]

Hi, @Javgilavi
Thanks for you attention. After resolving some dependency library compatibility issues, I have successfully compiled FastDDS (v3.1.1) using MSYS2-MinGW (x86_64-w64-mingw32-v14.2.0), and run HelloWorldExample successfully.
I also noticed a destructor problem like #3590. When there are no user-created reader or writer entities under the DomainParticipantFactory, the destructor becomes stuck, preventing the program from exiting normally. But it didn't matter，We always need to create writer when using fastdds, you can even create a writer by default at startup.
By the way, Could I make a PR for compiling in MinGW?

[Javgilavi]

Hi @RookieCLY,

Really happy to hear you successfully solve the issue!!

Regarding the destructor behavior you mentioned, feel free to add any findings or workarounds you have to the existing discussion #3820 — it’s always helpful to have more details.

Yes, absolutely, we encourage you to open a PR with your MinGW compilation improvements. Every contribution is appreciated, and we’re happy to review and merge good PRs that help others build Fast DDS on more platforms.

Thanks again.

[Atharvsam]

@Javgilavi Yes, my pleasure. “solution means” can be divided into three parts. First, warning with little impact. like "unused-parameter" "missing-field-initializers" and so on. I just use command like "-Wno-unused-parameter" to ignore them. Then, some llibrary error between windows and unix. Added option for "elif defined(MINGW)" to ifdef _WIN32(or _MSC_VER) and else , then fill the MINGW branch, so it can work as same as the _WIN32(or _MSC_VER) branch. For example, in "RobustExclusiveLock.hpp", add "elif defined(MINGW)" to ifdef _MSC_VER and else in the "include" block and "class" block. Then copy the code from "_MSC_VER" block, use the same function "_sopen_s" with <io.h>(MinGW), modify "_SH_DENYRW" to "0x0010", which is not defined in <io.h>(MinGW). Third, Manually link library, like "target_link_libraries(fastdds PUBLIC ws2_32 mswsock)".

As for the error in this issue, I solved this problem with "declspec( dllexport )" and "-Wno-attributes". So i can use almost all the symbols from libfastdds.dll and libfastdds.dll.a. Why "almost all"? There are some new problem for "TypeSupport". When I use TypeSupport(new startlogPubSubType()) to construct a TypeSupport object, i got the error E:/mingw32-14/bin/../lib/gcc/i686-w64-mingw32/14.2.0/../../../../i686-w64-mingw32/bin/ld.exe: C:\Users\CUILIU~1\AppData\Local\Temp\ccEr7V0I.o:xmsgbus.cxx:(.text$_ZN8eprosima7fastdds3dds11TypeSupportC1EPNS1_13TopicDataTypeE[__ZN8eprosima7fastdds3dds11TypeSupportC1EPNS1_13TopicDataTypeE]+0x20): undefined reference to "vtable for eprosima::fastdds::dds::TypeSupport" Maybe there are some thing wrong with "class TypeSupport : public std::shared_ptr" and MinGW? By the way, "startlogPubSubType" was generated by fastdds-gen with a idl.

I have hit the same walls as you hence reproducible and have reached the same point in compilation. Where do we go from here?

[juanlofer-eprosima]

Hi @Atharvsam , @RookieCLY has kindly opened a PR that should make compilation with MinGW possible. We will be reviewing his contribution as soon as possible, feel free to test it out in the meantime.

[RookieCLY]

Hi, @Atharvsam , I have opened a PR for this problem. Simply put, I deleted the key words virtual. if you can't wait to know it, you can get more detail in https://github.com/RookieCLY/Fast-DDS.