Fail to compilation: duplicate section `***' has different size #150
Comments
|
Looks like the same issue as #35 which was fixed long ago Note that the fix for that bug https://github.com/mystor/rust-cpp/pull/54/files does #ifdef _WIN64
__declspec (selectany)
#elif __GNUC__
__attribute__((weak))
#endifBut i guess in this case both I know nothing about MSYS2 so i don't know if it is related. |
|
I wonder if instead of using a weak symbol for the metadata, we couldn't just give it a unique name. |
|
Thanks for the awesome detailed bug report, @stuartZhang! Personally, I've only used MSYS2 for a short period of time, and it was one hell of a laggy experience (due to hundreds of forks under the hood, which Windows kernel didn't like), but otherwise somehow worked for me to get a decent shell, package management, and python workspace in a UNIX-way. Now that there is WSL and WSL2, I don't know if MSYS2 is relevant anymore, but I also haven't tried neither of them; so it's up to you to figure out if you will try to switch. Other than that, I am excited to say that I am currently writing a commercial project with bits of CMake, Qt, Rust, qmetaobject-rs for Windows (but it's really cross-platform, so I mainly develop on a more comfortable Linux). So far it's working alright, using either MinGW-gcc or MSVC kits. I only had to specify some global PATHs to Qt tools on Windows, otherwise qttypes sub-crate fails to find Qt directory. So, I'd definitely recommend going the "easy way" first. And if/when you feel confident enough — try the MSYS2 or other alternative workflows. |
Is there any of Wiki pages about how to set up the DEV environment in Windows OS? Perhaps, the Wiki page makes my effort of practicing "qmetaobject-rs" painless. Once my individual demo becomes successful, I shall definitely promote your commercial solution to my team leads. |
According to the article https://www.msys2.org/wiki/Porting/, there is a platform-check flag (e.g. _WIN64) provided by MSYS2.
|
|
@ratijas Yesterday, I consulted the Wiki page https://wiki.qt.io/MSYS2 to set up the MSYS2 + QT development environment. |
|
Last night, I have consulted the Wiki page https://wiki.qt.io/MinGW and followed the below steps:
@ogoffart @ratijas In this case, I gave up MSYS2 and merely used MinGW-gcc and the official Qt installation. |
|
The problem here is in the But apparently this doesn't work. Maybe because these define are not set, or maybe we need to have both. |
|
Perhaps, the fault is fixed in Qt 6.x. I shall install and link Qt 6.0 and retry to |
|
Unlikely.
This is a problem in the
This is even another problem i don't know what causes that. |
|
@ogoffart In this evening, I shall attempt the combination of MSVC + QT. Perhaps, the fault originates from the mingw gcc. |
|
@ogoffart Are there any of DLL dependencies whose names conflict with the built-in DLL files in Win32? I have ever run across the analogous situation, when playing with [Gnome.GTK3 + Rust] (i.e. gtk-rs). In that case, the [zlib1.dll] was shadowed by c:\windows\system32\zlib1.dll. Due to the Windows-specific Safe DLL Search Mode, the zlib1.dll that I really expect can't always loaded. |
|
@ogoffart I have just made an experiment, following the below steps:
And then, the different error logs appeared as such: = note: H:\github_projects\qt_rs_todos\target\debug\deps\libqttypes-929376424a1dde2b.rlib(cpp_closures.o):cpp_closures.cpp:(.data$_ZN7rustcpp8metadataE+0x0): multiple definition of `.weak._ZN7rustcpp8metadataE._ZnwyPv'
H:\github_projects\qt_rs_todos\target\debug\deps\libqmetaobject-e284a3ee801d53d3.rlib(cpp_closures.o):cpp_closures.cpp:(.data$_ZN7rustcpp8metadataE+0x0): first defined here
H:/symbol_link_source/mingw64_qt/bin/../lib/gcc/x86_64-w64-mingw32/7.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lmsvcrtdIn this case, the As for the build error I'm not aware of whether it's helpful for my issue or not? I really want to enjoy the |
|
Recently, I have just established a Virtual Machine [Ubuntu-20.04] where the compilation and running against the crate's todos example is perfect.
However, the target platform of my GUI application distribution is Windows-serial operation system. As a result, I had to also installed the following facilities for the cross compilation towards Windows 10 x64:
After running the command I'd like to say that the Windows-serial operation system is ubiquitous and significant for any GUI toolkit. I anticipate that the issue will be resolved in future. |
|
Well, in case of cross-compilation from Ubuntu to Windows (mingw-w64) you are probably missing migw-w64 compiled Qt libraries, right? At least that's what error message says ("cannot find -lQt5Core" etc.). Have you installed required target's Qt libraries through Qt online installer? And don't forget to use its environment, like correct PATH for bundled tools (including qmake). In case on Windows 64 to Windows 32 builds, I just installed through Qt online installer only required parts: Qt libs for mingw-32, CMake, Ninja, and ofc Qt Creator itself. Then I pushed paths to installed tools to the System/User's global PATH environment variable (because I don't care about other platforms, but normally you'd use some kind of bat for setting env similar to what |
|
@ratijas the root reason of the compiling failure is as below:
It's analogous with the situation in the Windows platform. |
|
By the way, are you still using rust nightly toolchain from 2021-03-25? What about latest nightly or stable branch? |
To avoid duplicated metadata This should help for woboq/qmetaobject-rs#150
|
Commit mystor/rust-cpp@9433d1b should fix the duplicated Also, when cross compiling, one must make sure that one use the target Qt and not the host Qt: So for that you can set the |
I put to use the rustup toolchain |
Great! Thanks. I am going to try it. Moreover, I have a question:
De facto, I have already utilized both export PATH="$HOME/Qt/5.12.11/gcc_64/bin:$PATH";
export LD_LIBRARY_PATH="$HOME/Qt/5.12.11/gcc_64/lib:$LD_LIBRARY_PATH"; |
|
Interestingly enough, I have just encountered the same issue with a duplicate section. It is Windows-specific, and does not affect Linux builds (which is my main workstation, hence I didn't notice right away). Happened when building a static lib for later linking via CMake to other libs and executables. I figured out, it doesn't happen with old qmetaobject v0.1.4. Probably because back then it was not split in different crates, thus it didn't have a duplicating section from separately compiled and linked object code? Patch on cpp family of crates works like magic, so I suggest publishing new version to crates.io ASAP [patch.crates-io]
cpp = { path = "../rust-cpp/cpp" }
cpp_common = { path = "../rust-cpp/cpp_common" }
cpp_macros = { path = "../rust-cpp/cpp_macros" }
cpp_build = { path = "../rust-cpp/cpp_build" }But even after that, I'm now hit by a different one. Similar to yours, @stuartZhang , l started having problems while locating Qt libraries. And they got this weird Something definitely went south in Windows land. |
these lines are coming from qttypes build script output. The letter let debug = std::env::var("DEBUG").ok().map_or(false, |s| s == "true");
let windows_dbg_suffix = if debug && cfg!(target_os = "windows") {
println!("cargo:rustc-link-lib=msvcrtd");
"d"
} else {
""
};It's supposed to use debug builds of libs, which I apparently didn't care to download. Indeed, when compiling with
Just out of curiosity, I've installed Qt 5.15.2 for MSCV 2019, and... boom! Here they are, right in the Directory contentSo, to conclude, this is highly Window & MSVC compiler-specific stuff, which does not play well with MinGW. Probably worth fixing in qttypes. The only question is how to detect which toolchain is being used, and adapt accordingly. |
|
@ratijas In terms of the programmers' developing experience, both MSVC rustup toolchain and QT-MSVC lib are rarely the best choice, due to the lack of the breakpoint debugger. So, I honestly wish both GNU and MinGW become available for the Windows-hosted programmers. |
|
So, it supports separate debug builds of DLLs, but not the breakpoints? How weird. Well, whatever. I don't have neither MS Visual Studio nor MSVC compiler installed on my fresh Windows. Rustc uses GNU toolchain, and MinGW libs are provided by Qt Maintenance tool, which works perfectly fine together. I assume, your compilation problems described in this thread are resolved by now? I'd like to close this issue, in favor of opening a new one regarding toolchain auto-detection by qttypes. |
It is probably contained in one of the environment variable. Maybe |
|
I have extracted things related to MSVC linkage problems into its own issue. At this point it's already obvious how to fix it. I'll give it a shot right now. |
|
@ratijas Ok. At least, I have the following chance, even though the rustup nightly channel is unavailable to the cross compilation.
When will the new version of this crate be published? I eagerly put it to use in my cross compilation. |
Here you go: [patch.crates-io]
qttypes = { git = "https://github.com/woboq/qmetaobject-rs" }
qmetaobject = { git = "https://github.com/woboq/qmetaobject-rs" }
qmetaobject_impl = { git = "https://github.com/woboq/qmetaobject-rs" }Alternatively, fork to your own repo with fixes, or clone locally and use See rust-lang/cargo#9624 and https://doc.rust-lang.org/cargo/reference/overriding-dependencies.html for more. |
|
You are a genius too. @ratijas |
Simple cfg!(target_* = "...") doesn't work in build scripts the way it does in crate's code, because build scripts are being compiled for the toolchain's target triple -- not the default-host nor the cargo's eventual target. Instead, such configuration should be loaded from provided environment variables at run-time. While initially trying to fix linkage issues for Windows + MinGW target (first reported by @stuartZhang in #150), I came to realize in the process that cfg!(target_os = ...), although being used only for OS X at this moment, is likely screwed up in the same way (except, who would ever cross-compile to or from Mac, and why?) https://doc.rust-lang.org/cargo/reference/environment-variables.html#environment-variables-cargo-sets-for-build-scripts Fixes #154
Simple cfg!(target_* = "...") doesn't work in build scripts the way it does in crate's code, because build scripts are being compiled for the toolchain's target triple -- not the default-host nor the cargo's eventual target. Instead, such configuration should be loaded from provided environment variables at run-time. While initially trying to fix linkage issues for Windows + MinGW target (first reported by @stuartZhang in #150), I came to realize in the process that cfg!(target_os = ...), although being used only for OS X at this moment, is likely screwed up in the same way (except, who would ever cross-compile to or from Mac, and why?) https://doc.rust-lang.org/cargo/reference/environment-variables.html#environment-variables-cargo-sets-for-build-scripts Fixes #154
(1) My OS: windows 10 x64
(2) My package management: MSYS2
(3) The installed libraries related to
QTinclude:local/mingw-w64-i686-qbs 1.18.0-2 Qt Build Suite (mingw-w64) local/mingw-w64-i686-qt-creator 4.14.2-1 Cross-platform IDE (mingw-w64) local/mingw-w64-i686-qt5 5.15.2-8 (mingw-w64-i686-qt mingw-w64-i686-qt5) A cross-platform application and UI framework (mingw-w64) local/mingw-w64-i686-qt5-static 5.15.2-2 (mingw-w64-i686-qt-static mingw-w64-i686-qt5-static) A cross-platform application and UI framework (mingw-w64-static) local/mingw-w64-i686-qtbinpatcher 2.2.0-4 Patcher for Qt libraries (mingw-w64) local/mingw-w64-x86_64-qbs 1.18.0-2 Qt Build Suite (mingw-w64) local/mingw-w64-x86_64-qt-creator 4.14.2-1 Cross-platform IDE (mingw-w64) local/mingw-w64-x86_64-qt5 5.15.2-8 (mingw-w64-x86_64-qt mingw-w64-x86_64-qt5) A cross-platform application and UI framework (mingw-w64) local/mingw-w64-x86_64-qt5-static 5.15.2-2 (mingw-w64-x86_64-qt-static mingw-w64-x86_64-qt5-static) A cross-platform application and UI framework (mingw-w64-static) local/mingw-w64-x86_64-qtbinpatcher 2.2.0-4 Patcher for Qt libraries (mingw-w64)(4) The installed libraries related to
libcryptinclude:local/libcrypt 2.1-3 (libraries) Encryption/Decryption library local/libcrypt-devel 2.1-3 (development) Libcrypt headers and libraries local/libgcrypt 1.9.2-1 (libraries) General purpose cryptographic library based on the code from GnuPG local/libgpg-error 1.42-1 (libraries) Support library for libgcrypt local/libhogweed 3.7.2-1 (libraries) A low-level cryptographic library local/libnettle 3.7.2-1 (libraries) A low-level cryptographic library local/libxxhash 0.8.0-1 (libraries) Extremely fast non-cryptographic hash algorithm local/mingw-w64-i686-libgcrypt 1.9.2-2 General purpose cryptographic library based on the code from GnuPG (mingw-w64) local/mingw-w64-i686-libgpg-error 1.42-1 Support library for libgcrypt (mingw-w64) local/mingw-w64-x86_64-libdvdcss 1.4.2-1 Portable abstraction library for DVD decryption (mingw-w64) local/mingw-w64-x86_64-libgcrypt 1.9.2-2 General purpose cryptographic library based on the code from GnuPG (mingw-w64) local/mingw-w64-x86_64-libgpg-error 1.42-1 Support library for libgcrypt (mingw-w64) local/mingw-w64-x86_64-nettle 3.7.2-1 A low-level cryptographic library (mingw-w64) local/mingw-w64-x86_64-xxhash 0.8.0-1 Extremely fast non-cryptographic hash algorithm (mingw-w64) local/nettle 3.7.2-1 (net-utils) A low-level cryptographic library local/xxhash 0.8.0-1 Extremely fast non-cryptographic hash algorithm(5) When I executes the command
cargo run -p todosinmingw64.exe, the following error is shown:Do you give me a few of suggestions for how to compile the project? Maybe, are there certain libraries I missed in my local MSYS2? Or I shoundn't utilize MSYS2?
The text was updated successfully, but these errors were encountered: