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

[WINDOWS] THREADS_PTHREADS_WIN32_LIBRARY #7044

Closed
MVoz opened this issue Jun 26, 2019 · 16 comments
Closed

[WINDOWS] THREADS_PTHREADS_WIN32_LIBRARY #7044

MVoz opened this issue Jun 26, 2019 · 16 comments
Labels
category:port-bug The issue is with a library, which is something the port should already support

Comments

@MVoz
Copy link
Contributor

MVoz commented Jun 26, 2019

faced with the problem THREADS_PTHREADS version 3
the fact is that most people use the old version, new does not see, even with a wrapper

if you specify explicitly then everything works

but there are projects that explicitly link by library name

OPTIONS_DEBUG # automatic templates
   -DLIBUSB_LIBRARIES=${CURRENT_INSTALLED_DIR}/debug/lib/libusb-1.0.lib
   -DTHREADS_PTHREADS_WIN32_LIBRARY=${CURRENT_INSTALLED_DIR}/debug/lib/pthreadVC2.lib
 OPTIONS 
   -DLIBUSB_LIBRARIES=${CURRENT_INSTALLED_DIR}/lib/libusb-1.0.lib
   -DTHREADS_PTHREADS_WIN32_LIBRARY=${CURRENT_INSTALLED_DIR}/lib/pthreadVC2.lib

example
https://github.com/steve-m/librtlsdr

had to symbolic link pthreadVC3.lib -->> pthreadVC2.lib

@cenit
Copy link
Contributor

cenit commented Jun 26, 2019

Instead of patching our pthread v3 portfile to rename/copy pthreadVC3.lib —> pthreadVC2.lib, do you think it would be impossible to fix the problem upstream in the libraries that still expect the ancient v2?

@MVoz
Copy link
Contributor Author

MVoz commented Jun 26, 2019

no copy, symbolic reference ))
you have to write a script wrapper ((

alias?

@cenit
Copy link
Contributor

cenit commented Jun 26, 2019

What do you mean with symbolic references? If it is a file link, unfortunately before win10 1803 and even then without developer mode enabled, it requires admin privileges and so it’s out of question.
In any case any “double entry” to the same file would cause maybe some problems with vcpkg auto linking for vs solutions (same symbol in different libs)

Can you tell me in that project exactly where is the wrong pthread linking line? Maybe it’s not easy to locate? What about patching that project so to be pthreadVC* version independent?

@MVoz
Copy link
Contributor Author

MVoz commented Jun 26, 2019

for a personal directory that is not created as an administrator, you do not need any privileges to create a symbolic link
and if many people work with one project, then in any case there are permissions to record

and this is not the only project, there are about 8 of them, which I faced

@cenit
Copy link
Contributor

cenit commented Jun 26, 2019

for a personal directory that is not created as an administrator, you do not need any privileges to create a symbolic link

What os version do you use? To create symbolic links in Windows you had always needed admin privileges, even if you were working in your home folder. Things changed one year ago, but still you had to opt-in in the new mechanism (developer mode)

@MVoz
Copy link
Contributor Author

MVoz commented Jun 26, 2019

I just voiced the problem that many face, in more detail I do not have time to figure out
I go for less resistance

\sorry google translate

windows 1803

ver
Microsoft Windows [Version 10.0.17134.345]

@cenit
Copy link
Contributor

cenit commented Jun 26, 2019

That’s exactly what I look for: least resistance. And that maybe means just a copy of the file, from VC3 to VC2, apart from the symbolic redundancy that may create.
@ras0219-msft what do you think?

@Neumann-A
Copy link
Contributor

Stupid question: Can you not simply delete the FindThreads module and use CMakes buildin FindThreads module and set THREADS_PREFER_PTHREAD_FLAG?

@MVoz
Copy link
Contributor Author

MVoz commented Jun 27, 2019

worth a try, just remove the module

\google translator smiles

@MVoz
Copy link
Contributor Author

MVoz commented Jun 27, 2019

@Neumann-A
Is it possible to set a priority in the search for modules?

suppose, search first in VCPKG then in CMAKE share MODULE and last with the project files?

@cenit
Copy link
Contributor

cenit commented Jun 27, 2019

Can you not simply delete the FindThreads module and use CMakes buildin FindThreads module and set THREADS_PREFER_PTHREAD_FLAG?

CMake integrated thread module doesn’t look for posix thread implementations on Windows afaik, no matter how much hard you ask for them. I had also to write a custom module for darknet/yolo back in the time, but I didn’t overlay the official one. I can understand the problem that pthreadVC2 has been there for a long time, i’d patch problematic projects to bring them to the modern age, but still can also understand replicating files, if it’s so simple and fixes many projects in a glimpse.

@cenit
Copy link
Contributor

cenit commented Jun 27, 2019

Is it possible to set a priority in the search for modules?

That’s what CMAKE_MODULE_PATH is there for

@MVoz
Copy link
Contributor Author

MVoz commented Jun 27, 2019

That’s what CMAKE_MODULE_PATH is there for

it is understandable, globally in VCPKG
What is the default priority in the CMAKE?

@cenit
Copy link
Contributor

cenit commented Jun 27, 2019

This is the order CMake follows: First of all, look in the folders in that path (in the order they are written), then look in the internal repository (share/cmake-x.y/Modules).
vcpkg does not have a single module folder, each port writes its own module in its share folder (similar to the config mode)

@MVoz
Copy link
Contributor Author

MVoz commented Jun 27, 2019

Well, as implemented in meson dependency search via cmake
#6977 (comment)

example
"C:/Program Files/cmake/bin\cmake.EXE" -G "Visual Studio 10 2010" --trace-expand -DNAME=libelf -DARCHS= -DCMAKE_PREFIX_PATH=E:/tools/vcpkg/installed/x64-windows .

The root folder x64-windows .

modules are default
folder root Cmake or lib/Cmake

installed/x64-windows/Cmake
installed/x64-windows/lib/Cmake

@LilyWangL LilyWangL added the category:port-bug The issue is with a library, which is something the port should already support label Jun 28, 2019
@MVoz MVoz closed this as completed Jul 19, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
category:port-bug The issue is with a library, which is something the port should already support
Projects
None yet
Development

No branches or pull requests

4 participants