Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[question] Building xz_utils with mingw fails #16254

Open
1 task done
WangZhongDian opened this issue May 14, 2024 · 13 comments
Open
1 task done

[question] Building xz_utils with mingw fails #16254

WangZhongDian opened this issue May 14, 2024 · 13 comments
Assignees

Comments

@WangZhongDian
Copy link

What is your question?

profiles

[settings]
arch=x86_64
build_type=Release
compiler=gcc
compiler.cppstd=gnu17
compiler.libcxx=libstdc++11
compiler.version=13
os=Windows

conanfile

[requires]
opencv/4.9.0

[generators]
CMakeDeps
CMakeToolchain

[layout]
cmake_layout

Log

/c/users/86186/.conan2/p/b/xz_ut28f3219c5926f/b/src/src/common/mythread.h:396:25: 警告:‘uintptr_t’ {或称 ‘long unsigned int’}转换自‘int’时可能会改变结果的符号 [-Wsign-conversion]
In file included from /c/users/86186/.conan2/p/b/xz_ut28f3219c5926f/b/src/src/xz/private.h:14,
                 from /c/users/86186/.conan2/p/b/xz_ut28f3219c5926f/b/src/src/xz/util.c:13:
/c/users/86186/.conan2/p/b/xz_ut28f3219c5926f/b/src/src/common/mythread.h: 在函数‘mythread_create’中:
/c/users/86186/.conan2/p/b/xz_ut28f3219c5926f/b/src/src/common/mythread.h:396:25: 警告:隐式声明函数‘_beginthreadex’ [-Wimplicit-function-declaration]
  396 |         uintptr_t ret = _beginthreadex(NULL, 0, func, arg, 0, NULL);
      |                         ^~~~~~~~~~~~~~
/c/users/86186/.conan2/p/b/xz_ut28f3219c5926f/b/src/src/common/mythread.h:396:25: 警告:‘uintptr_t’ {或称 ‘long unsigned int’}转换自‘int’时可能会改变结果的符号 [-Wsign-conversion]
mv -f .deps/xz-main.Tpo .deps/xz-main.Po
mv -f .deps/xz-args.Tpo .deps/xz-args.Po
/c/users/86186/.conan2/p/b/xz_ut28f3219c5926f/b/src/src/xz/signals.c: 在函数‘signals_block’中:
/c/users/86186/.conan2/p/b/xz_ut28f3219c5926f/b/src/src/xz/signals.c:125:25: 警告:implicit declaration of function ‘mythread_sigmask’; did you mean ‘pthread_sigmask’? [-Wimplicit-function-declaration]
  125 |                         mythread_sigmask(SIG_BLOCK, &hooked_signals, NULL);
      |                         ^~~~~~~~~~~~~~~~
      |                         pthread_sigmask
mv -f .deps/xz-hardware.Tpo .deps/xz-hardware.Po
mv -f .deps/xz-mytime.Tpo .deps/xz-mytime.Po
mv -f .deps/xz-suffix.Tpo .deps/xz-suffix.Po
mv -f .deps/xz-signals.Tpo .deps/xz-signals.Po
mv -f .deps/xz-options.Tpo .deps/xz-options.Po
In file included from /c/users/86186/.conan2/p/b/xz_ut28f3219c5926f/b/src/src/xz/private.h:14,
                 from /c/users/86186/.conan2/p/b/xz_ut28f3219c5926f/b/src/src/xz/list.c:13:
/c/users/86186/.conan2/p/b/xz_ut28f3219c5926f/b/src/src/common/mythread.h: 在函数‘mythread_create’中:
/c/users/86186/.conan2/p/b/xz_ut28f3219c5926f/b/src/src/common/mythread.h:396:25: 警告:隐式声明函数‘_beginthreadex’ [-Wimplicit-function-declaration]
  396 |         uintptr_t ret = _beginthreadex(NULL, 0, func, arg, 0, NULL);
      |                         ^~~~~~~~~~~~~~
/c/users/86186/.conan2/p/b/xz_ut28f3219c5926f/b/src/src/common/mythread.h:396:25: 警告:‘uintptr_t’ {或称 ‘long unsigned int’}转换自‘int’时可能会改变结果的符号 [-Wsign-conversion]
mv -f .deps/xz-util.Tpo .deps/xz-util.Po
mv -f .deps/xz-coder.Tpo .deps/xz-coder.Po
mv -f .deps/xz-file_io.Tpo .deps/xz-file_io.Po
mv -f .deps/xz-message.Tpo .deps/xz-message.Po
mv -f .deps/xz-list.Tpo .deps/xz-list.Po
/bin/sh ../../libtool  --tag=CC   --mode=link gcc -Wall -Wextra -Wvla -Wc99-c11-compat -Wformat=2 -Winit-self -Wmissing-include-dirs -Wshift-overflow=2 -Wstrict-overflow=3 -Walloc-zero -Wduplicated-cond -Wfloat-equal -Wundef -Wshadow -Wpointer-arith -Wbad-function-cast -Wwrite-strings -Wdate-time -Wsign-conversion -Wfloat-conversion -Wlogical-op -Waggregate-return -Wstrict-prototypes -Wold-style-definition -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -m64 -O3  -m64 -o xz.exe xz-args.o xz-coder.o xz-file_io.o xz-hardware.o xz-main.o xz-message.o xz-mytime.o xz-options.o xz-signals.o xz-suffix.o xz-util.o xz-tuklib_open_stdxxx.o xz-tuklib_progname.o xz-tuklib_exit.o xz-tuklib_mbstr_width.o xz-tuklib_mbstr_fw.o xz-list.o xz_w32res.o ../../src/liblzma/liblzma.la
libtool: link: gcc -Wall -Wextra -Wvla -Wc99-c11-compat -Wformat=2 -Winit-self -Wmissing-include-dirs -Wshift-overflow=2 -Wstrict-overflow=3 -Walloc-zero -Wduplicated-cond -Wfloat-equal -Wundef -Wshadow -Wpointer-arith -Wbad-function-cast -Wwrite-strings -Wdate-time -Wsign-conversion -Wfloat-conversion -Wlogical-op -Waggregate-return -Wstrict-prototypes -Wold-style-definition -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -m64 -O3 -m64 -o xz.exe xz-args.o xz-coder.o xz-file_io.o xz-hardware.o xz-main.o xz-message.o xz-mytime.o xz-options.o xz-signals.o xz-suffix.o xz-util.o xz-tuklib_open_stdxxx.o xz-tuklib_progname.o xz-tuklib_exit.o xz-tuklib_mbstr_width.o xz-tuklib_mbstr_fw.o xz-list.o xz_w32res.o  ../../src/liblzma/.libs/liblzma.a
/c/users/86186/.conan2/p/msys27f2f094a41efb/p/bin/msys64/usr/bin/../lib/gcc/x86_64-pc-msys/13.2.0/../../../../x86_64-pc-msys/bin/ld: xz-signals.o:signals.c:(.text+0x157): undefined reference to `mythread_sigmask'
/c/users/86186/.conan2/p/msys27f2f094a41efb/p/bin/msys64/usr/bin/../lib/gcc/x86_64-pc-msys/13.2.0/../../../../x86_64-pc-msys/bin/ld: xz-signals.o:signals.c:(.text+0x1a7): undefined reference to `mythread_sigmask'
/c/users/86186/.conan2/p/msys27f2f094a41efb/p/bin/msys64/usr/bin/../lib/gcc/x86_64-pc-msys/13.2.0/../../../../x86_64-pc-msys/bin/ld: ../../src/liblzma/.libs/liblzma.a(liblzma_la-stream_encoder_mt.o):stream_encoder_mt.c:(.text+0x9f9): undefined reference to `_beginthreadex'
/c/users/86186/.conan2/p/msys27f2f094a41efb/p/bin/msys64/usr/bin/../lib/gcc/x86_64-pc-msys/13.2.0/../../../../x86_64-pc-msys/bin/ld: ../../src/liblzma/.libs/liblzma.a(liblzma_la-stream_decoder_mt.o):stream_decoder_mt.c:(.text+0x1f2f): undefined reference to `_beginthreadex'
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile:513:xz.exe] 错误 1
make[3]: 离开目录“/c/Users/86186/.conan2/p/b/xz_ut28f3219c5926f/b/build-release/src/xz”
make[2]: *** [Makefile:426:all-recursive] 错误 1
make[2]: 离开目录“/c/Users/86186/.conan2/p/b/xz_ut28f3219c5926f/b/build-release/src”
make[1]: *** [Makefile:621:all-recursive] 错误 1
make[1]: 离开目录“/c/Users/86186/.conan2/p/b/xz_ut28f3219c5926f/b/build-release”
make: *** [Makefile:490:all] 错误 2

xz_utils/5.4.5: ERROR:
Package '74fce2c720f804facc619f996bab77ff99796c4d' build failed
xz_utils/5.4.5: WARN: Build folder C:\Users\86186\.conan2\p\b\xz_ut28f3219c5926f\b\build-release
ERROR: xz_utils/5.4.5: Error in build() method, line 141
        autotools.make()
        ConanException: Error 2 while executing

Based on my investigation. I found that the dependency on ffmpeg for OpenCV requires xz_utils/5.4.5, which cannot be installed. I tried to install xz_utils/5.4.5 and received the same error

Have you read the CONTRIBUTING guide?

  • I've read the CONTRIBUTING guide
@memsharded memsharded self-assigned this May 14, 2024
@memsharded
Copy link
Member

Hi @WangZhongDian

Thanks for your question.

First, I'd like to advice about using mingw in Windows. Packages in ConanCenter are built with msvc compiler, but they are not built nor tested with mingw gcc on Windows. That means that support for it in ConanCenter recipes will be varying, and it is possible that not all of them will build correctly.

Then, it is typically necessary to define some more configuration to use MinGW on windows, some [buildenv] with different env-vars, etc.

Also, mingw gcc compiler has more settings to define, as there are different threads and exceptions model, please check the settings.yml:

threads: [null, posix, win32]  # Windows MinGW
exception: [null, dwarf2, sjlj, seh]  # Windows MinGW

These settings should be defined too. This page of the docs might help: https://docs.conan.io/2/examples/dev_flow/tool_requires/mingw.html

So, in summary, if you are starting/learning Conan and using packages from ConanCenter, I'd strongly recommended to use Visual Studio community instead of MinGW, as it will be better supported.

Then, regarding the problem you are reporting, there could be different things. For some reason it seems it is using information from msys2 but this is not expected, could be a setup problem. A good way to investigate this, is to build simple packages first, you can create simple CMake and Autotools projects with:

conan new cmake_lib -d name=mypkg -d version=0.1
conan create . -pr=myprofile

and

conan new autotools_lib-d name=mypkg -d version=0.1
conan create . -pr=myprofile -tf=""

Note the last command the test_package doesn't work on Windows, so disabling it with -tf="" is necessary.

And this should work with your setup.

@WangZhongDian
Copy link
Author

@memsharded Thank you very much for your answer, I will try your solution, I am very bullish on conan and I will continue to support conan

@memsharded
Copy link
Member

@memsharded Thank you very much for your answer, I will try your solution, I am very bullish on conan and I will continue to support conan

Great, thanks very much and thanks for your feedback.

I'll keep the ticket open, let me know how it goes with the above suggestions.

@memsharded memsharded changed the title [question] SHORT DESCRIPTION [question] Building xz_utils with mingw fails May 15, 2024
@WangZhongDian
Copy link
Author

WangZhongDian commented May 15, 2024

我想知道exceptionthreads的参数怎么选择,在文档中没用说明,只是给了一个示例,我不知道是否可以适应其他的计算机 @memsharded

@memsharded
Copy link
Member

Not sure what you mean, I entered above in translator.

If you mean what are the default settings.yml, the definition is here: https://docs.conan.io/2/reference/config_files/settings.html

But if you just enter any value, Conan will error and will tell you what are the available possible values.

@WangZhongDian
Copy link
Author

WangZhongDian commented May 15, 2024

I really appreciate your answer. I used MSVC and Conan is working properly. I will continue to use your method to try using GCC. This question will be closed and I have obtained a satisfactory answer @memsharded

@WangZhongDian
Copy link
Author

@memsharded
I modified the configuration according to my version of GCC, but still got the same error. I will use MSVC first, but I hope GCC can get more support. I really appreciate it

[settings]
arch=x86_64
build_type=Release
compiler=gcc
compiler.cppstd=gnu17
compiler.libcxx=libstdc++11
compiler.version=13
compiler.threads=posix
compiler.exception=seh
os=Windows

[buildenv]
PATH+=C:\\Users\\86186\\software\\compiler\\mingw64\\bin
CXX=C:\\Users\\86186\\software\\compiler\\mingw64\\bin\\g++

@WangZhongDian
Copy link
Author

@memsharded I have a small question for you. Is there a way or configuration to specify the dynamic libraries, static libraries, and header files generated by Conan in my project directory, so that it is convenient for me to package my project without having to search and copy them from the Conan directory?

@memsharded
Copy link
Member

I modified the configuration according to my version of GCC, but still got the same error. I will use MSVC first, but I hope GCC can get more support. I really appreciate it

ConanCenter got almost 6000 Pull Requests in 2023 alone. This is a huge task, improving support for MinGW might be eventually possible adding more CI builds with MinGW, but that will take a long time and a big effort from the community too. This is not something that it is in our hands, without the community this is almost impossible. Sometimes the issue is that there are libraries that don't compile at all in MinGW, only with MSVC, and for those cases, Conan cannot do anything, it is not in scope of Conan to patch C++ source code to make it work for all scenarios, so those might take even longer if the upstream maintainers do not prioritize that, and that is also another challenge.

I have a small question for you. Is there a way or configuration to specify the dynamic libraries, static libraries, and header files generated by Conan in my project directory, so that it is convenient for me to package my project without having to search and copy them from the Conan directory?

I am not sure what you mean. You can control dependencies, if you want them as shared libraries you can use -o *:shared=True (in command line) or *:shared=True in your profile [options] section. But those are the dependencies installed in the Conan cache. Whatever is created in your project directory is what your local project creates. If you are talking about later doing a copy of the artifacts from the Conan cache for final deployment, you might want to check the --deployer deployers to do such a copy. Check https://docs.conan.io/2/reference/extensions/deployers.html for more info.

@WangZhongDian
Copy link
Author

@memsharded
What I want to express is that I am a consumer of Conan bags.
If my project address is in E: \ project \.
And the dynamic or static libraries built by Conan are in~/. conan2/p. Is there any way for Conan to put the addresses of the static or dynamic libraries in my project when building, that is, in E: \ project \ lib

@WangZhongDian
Copy link
Author

I have tried setting the imports property, which is similar to some invalid configurations found on the internet

[requires]
zlib/1.3.1

[generators]
CMakeDeps
CMakeToolchain

[layout]
cmake_layout

[imports]
bin, *.dll -> ./bin
lib, *.lib -> ./lib

@WangZhongDian
Copy link
Author

@memsharded
Sorry, I didn't take your reply seriously. -- deployer=full_deploy is useful

@memsharded
Copy link
Member

The imports is the Conan 1.X legacy way of doing it, but this has been removed in Conan 2 and it is no longer recommended.

The deployer is the Conan 2 way to go to extract dependencies from Conan, but this is most likely not recommended in the first place, please take into account:

  • Using --deployer for development is not recommended. For development it is recommended to leave the Conan packages in the Conan cache. It has a specific structure to avoid collisions, to be efficient, traceable, to allow easier updates without breaking, rolling back to previous versions easily and many more. There are basically no advantages in doing an extra copy to a specific location to just build against them. There is also no advantages to having a local copy inside the project, like in a deps folder in the project, and on the contrary that will mostly disallow using different binary variants properly.
  • Using --deployer is only intended for the last-mile deployment, outside of Conan. That is, not for development, but only for extracting the final artifacts, for example runtime shared libraries from dependencies and deploying them in the servers or final application location, without using Conan but other methods.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants