search

pupnp / pupnp

libupnp: Build UPnP-compliant control points, devices, and bridges on several operating systems.
https://pupnp.github.io/pupnp
BSD 3-Clause "New" or "Revised" License
352 stars 115 forks source link

[1.8.4] Cannot be built on Windows #106

Closed emptyVoid closed 3 years ago

emptyVoid commented 5 years ago

I'm getting errors while trying to build release-1.8.4 with Visual Studio 2017:

Cannot open include file: 'autoconfig.h': No such file or directory
Cannot open source file: '..\..\threadutil\src\FreeList.c': No such file or directory
Cannot open source file: '..\..\threadutil\src\LinkedList.c': No such file or directory
Cannot open source file: '..\..\threadutil\src\ThreadPool.c': No such file or directory
Cannot open source file: '..\..\threadutil\src\TimerThread.c': No such file or directory
Cannot open include file: 'upnpconfig.h': No such file or directory
Vollstrecker commented 4 years ago

This is an older problem introduced with: https://github.com/mrjimenez/pupnp/commit/c493ccbebe5cc648327fc77b572d6dbfe59598e8

The pregenerated file was removed, and as VS doesn't run autoconf or configure, it isn't genrated again.

uhrb commented 4 years ago

Half of the problem solved! Just about 1year passed. Hope 2021 will bring windows builds back :D

emptyVoid commented 4 years ago

@mrjimenez, I take it you are not interested in fixing Windows build? Why don't you remove broken Windows configuration and instruction then to make it clear the project no longer supports Windows?

whyman commented 4 years ago

@emptyVoid is it same situation with the latest tarball?

I imagine the intention is to support windows, but I would assume that @mrjimenez like myself runs *nix exclusively.

Really what we need is a friendly windows developer to help fix up the build :+1:

Vollstrecker commented 4 years ago

It's the same with master, except that upnpconfig.h isn't mentioned anymore.

As I stumpled over this while porting aMule to cmake, I could offer to do here the same. I could test on linux and win atm.

emptyVoid commented 4 years ago

I've checked 1.12.0 -- headers generated by autotools are missing (autoconfig.h, upnpconfig.h, and config_sample.h). A few compatibility issues with modern Windows SDK and Visual C Standard Library.

I agree CMake-based build system would be great -- one place to define sources for all platforms. Would require some effort to replicate autotools functionality though (like make dist).

Vollstrecker commented 4 years ago

Why? make dist is meant to create a tarball including such thing like configure pregenerated, so the user doesn't need to run e.g. autogen.

As cmake replaces that stuff, make dist would just do nothing than creating a tarball similar to the zip you can download here. With cmake you just use that zip, or better git to checkout, then configure, build and maybe install.

emptyVoid commented 4 years ago

I have no idea why it's needed, I've just stumbled upon a concern about it in https://github.com/pupnp/pupnp/issues/159#issuecomment-578134284.

Vollstrecker commented 4 years ago

Exactly what I meant. dist should run bootstrap and pack the source.

But in this case here I would use cmake in addition, not as a replacement, so just on windows the outdated and not working vc-projects can get deleted and generated in a working version, on linux it or the old stuff can be used, and on other plattforms the usual ways stay as they are.

uhrb commented 4 years ago

In any case, just closing the issue, taking into account windows builds are still not there - awkward from my perspective. Cause of the issue is not solved. So why close?

mrjimenez commented 4 years ago

Hi folks,

I don't mean to offend anyone, so please excuse me if that was the case. I am not against reopening it, and so I will.

The issue was opened in February 2019, and is about 1.8.4. 1.8.x is bugfix only. There has not been a windows programmer in this project for a long time. As far as I remember, windows development files have been removed more than a year ago. These files were a visual studio support contributed by windows programmers interested in making the library compile on this IDE. But windows compilation became broken in many ways due to the lack of support, and the community decided to remove them.

If I recall correctly, autotools could be used in windows using mingw or cygwin, but really, I am not sure about it since I don't do any programming in Windows since 1998. I imagine someone must have already tried that, since it would be the obvious path to me.

If anything, closing it was good because at least now people are discussing the issue, who knows if we can find someone to make a windows build?

Best regards, Marcelo.

mrjimenez commented 4 years ago

Hi Vollstrecker,

Good to see you here! It's been a while since aMule days.

Exactly what I meant. dist should run bootstrap and pack the source.

But in this case here I would use cmake in addition, not as a replacement, so just on windows the outdated and not working vc-projects can get deleted and generated in a working version, on linux it or the old stuff can be used, and on other plattforms the usual ways stay as they are.

That seems to be a great solution. An alternative build that does not conflict is great. As mentioned in #159 I have nothing against changing the build system. Autotools is a pain, but as pointed by @ukleinek , changing build systems usually just changes the set of problems to resolve. One plus to adding an alternative.

Best regards, Marcelo.

Vollstrecker commented 4 years ago

Not for me, I'm still active there. It's an interesting coincidence that you closed that one just one day after I finished the other stuff. I commited yesterday a bunch of chnages for the amule windows build for wx cryptopp etc and just wanted to start today including upnp.

So I maybe would've send you a pullrequest on tuesday or wednesday without offering the changes first.

And @ukleinek is right, changing always brings some new views. I had yesterday errors in my build that didn't happen before. I'm not sure it's from how I create cryptopp, or that now paths of our code are reached, that just haven't been used before without anyone knew it for the past years. So maybe here some things like that will pop up, too.

Vollstrecker commented 4 years ago

https://github.com/Vollstrecker/pupnp

The first part is done, replacing autoheader is a real pita. *.la for libtool won't be integrated, most of the distributions don't ship them anymore. For now only the build on linux is tested. Next step are the test-progs.

mrjimenez commented 4 years ago

NIce job!

We'll be waiting for the pull requests.

Stullemon commented 3 years ago

Hi everyone,

I tried to use Vollstrecker's work and get everything to compile in Visual Studio 2019. I failed... Anyhow, I used cygwin to compile the last release, version copied the config files, changed a couple of things (like remove IPv6 support) and setup the Visual Studio project files. The resulting commit can be viewed here: https://github.com/Stullemon/pupnp/commit/5deec7c0df90faf59efa0b0c6ec61b4a2f74b51b

I hope this'll help the next person running into this issue on a Windows based project. :-)

Regards, Stulle

Vollstrecker commented 3 years ago

Maybe you could tell me how you failed. You recreated autoconfig.h, I didn't check how this affects other plattforms, but shipping a file that configures the build to the local requirements doesn't look that smart to me.

An yes, there didn't happen that much for some time, that's just because I started this to allow amule to build it's deps while it's own build, and as this only works when upnp is able to do the same, I'm just at enabling pthreads-w32 for this. This works almost, but the tests are not trivial on each project, and even harder to get them all combined. Plus, I'm no windows guy, so understanding the win-specialies takes some time, and doing it all in a virtualbox takes even more time.

Stullemon commented 3 years ago

I reckon it was just my impatience and my lack of understanding of CMake. That said, the build apparently fails (partially because recent versions of pupnp have changed the file/dir structure) but the generation of the config files works. So what I will look into is how to just use the configuration file generation excluding any other build steps in order to integrate that into the VS2019 solution files. I will get back here when I made that work out for me.

Vollstrecker commented 3 years ago

k, but wouldn't it be easier to find out what is not working with the generated file, so users of other VS-versions or IDEs could benefit, too?

Stullemon commented 3 years ago

Sure, which is why I want to update the VS Project Files so they provide all means to compile correctly in a VS solution. Truth be told, I am really no expert in these matters and I am mostly just trying to get it to work for another project which I work on. I hope somebody else will be able to pick up the crumbs and revise the cmake project entirely from the point where I'll leave it. In the end I prefer the VS project file build mechanisms, which is why I don't care enough for educating myself in cmake more than I need to.

Vollstrecker commented 3 years ago

I'm not talking about educating yourself. I'm talking about telling me what is wrong. Here it didn't fail and anything I know is that file generation works, but you need something else to get it working.

Why don't you just tell me what and why you had to change?

Stullemon commented 3 years ago

Oh, sorry about that. I thought you were out of time which is why your fork is not merged up to the most recent release version of pupnp. My bad. So, here is what I did:

  1. Clone your fork
  2. Add official pupnp as remote rootRep
  3. git pull rootRep master
  4. Navigate to directory ./build/vc10
  5. Open libupnp.sln with Visual Studio 2019
  6. Retarget projects to VS2019 (SDK and platform tools both to most recent version)
  7. Open folder view in Solution Explorer panel (which automatically executes CMake)

The following output is generated:

1> CMake generation started for default configuration: 'x64-Debug (default)'.
1> Command line: "cmd.exe" /c ""C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO\2019\COMMUNITY\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\CMAKE\CMake\bin\cmake.exe"  -G "Ninja"  -DCMAKE_BUILD_TYPE:STRING="Debug" -DCMAKE_INSTALL_PREFIX:PATH="D:\C++\pupnp_Vollstrecker\out\install\x64-Debug (default)" -DCMAKE_C_COMPILER:FILEPATH="C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.27.29110/bin/Hostx64/x64/cl.exe" -DCMAKE_CXX_COMPILER:FILEPATH="C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.27.29110/bin/Hostx64/x64/cl.exe"  -DCMAKE_MAKE_PROGRAM="C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO\2019\COMMUNITY\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\CMAKE\Ninja\ninja.exe" "D:\C++\pupnp_Vollstrecker" 2>&1"
1> Working directory: D:\C++\pupnp_Vollstrecker\out\build\x64-Debug (default)
1> [CMake] -- Setting package-version to 1.14.1
1> [CMake] -- Setting ixml-version to 11.0.0
1> [CMake] -- Setting upnp-version to ..
1> [CMake] -- The C compiler identification is MSVC 19.27.29112.0
1> [CMake] -- The CXX compiler identification is MSVC 19.27.29112.0
1> [CMake] -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.27.29110/bin/Hostx64/x64/cl.exe
1> [CMake] -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.27.29110/bin/Hostx64/x64/cl.exe - works
1> [CMake] -- Detecting C compiler ABI info
1> [CMake] -- Detecting C compiler ABI info - done
1> [CMake] -- Detecting C compile features
1> [CMake] -- Detecting C compile features - done
1> [CMake] -- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.27.29110/bin/Hostx64/x64/cl.exe
1> [CMake] -- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.27.29110/bin/Hostx64/x64/cl.exe - works
1> [CMake] -- Detecting CXX compiler ABI info
1> [CMake] -- Detecting CXX compiler ABI info - done
1> [CMake] -- Detecting CXX compile features
1> [CMake] -- Detecting CXX compile features - done
1> [CMake] -- Check if the system is big endian
1> [CMake] -- Searching 16 bit integer
1> [CMake] -- Looking for sys/types.h
1> [CMake] -- Looking for sys/types.h - found
1> [CMake] -- Looking for stdint.h
1> [CMake] -- Looking for stdint.h - found
1> [CMake] -- Looking for stddef.h
1> [CMake] -- Looking for stddef.h - found
1> [CMake] -- Check size of unsigned short
1> [CMake] -- Check size of unsigned short - done
1> [CMake] -- Searching 16 bit integer - Using unsigned short
1> [CMake] -- Check if the system is big endian - little endian
1> [CMake] -- Looking for sys/socket.h
1> [CMake] -- Looking for sys/socket.h - not found
1> [CMake] -- Looking for ws2tcpip.h
1> [CMake] -- Looking for ws2tcpip.h - found
1> [CMake] -- Check size of socklen_t
1> [CMake] -- Check size of socklen_t - done
1> [CMake] -- Check size of off_t
1> [CMake] -- Check size of off_t - done
1> [CMake] -- Looking for fseeko
1> [CMake] -- Looking for fseeko - not found
1> [CMake] -- Looking for strnlen
1> [CMake] -- Looking for strnlen - found
1> [CMake] -- Looking for strndup
1> [CMake] -- Looking for strndup - not found
1> [CMake] -- Looking for pthread.h
1> [CMake] -- Looking for pthread.h - not found
1> [CMake] -- Found Threads: TRUE  
1> [CMake] -- Check size of pthread_rwlock_t
1> [CMake] -- Check size of pthread_rwlock_t - failed
1> [CMake] -- Configuring done
1> [CMake] CMake Error at upnp/CMakeLists.txt:14 (ADD_LIBRARY):
1> [CMake]   Cannot find source file:
1> [CMake] 
1> [CMake]     src/api/ActionComplete.c
1> [CMake] 
1> [CMake]   Tried extensions .c .C .c++ .cc .cpp .cxx .cu .m .M .mm .h .hh .h++ .hm
1> [CMake]   .hpp .hxx .in .txx
1> [CMake] 
1> [CMake] 
1> [CMake] CMake Error at upnp/unittest/CMakeLists.txt:1 (ADD_EXECUTABLE):
1> [CMake]   Cannot find source file:
1> [CMake] 
1> [CMake]     main.c
1> [CMake] 
1> [CMake]   Tried extensions .c .C .c++ .cc .cpp .cxx .cu .m .M .mm .h .hh .h++ .hm
1> [CMake]   .hpp .hxx .in .txx
1> [CMake] 
1> [CMake] 
1> [CMake] CMake Error at upnp/CMakeLists.txt:191 (ADD_LIBRARY):
1> [CMake]   No SOURCES given to target: upnp_static
1> [CMake] 
1> [CMake] 
1> [CMake] CMake Error at upnp/CMakeLists.txt:14 (ADD_LIBRARY):
1> [CMake]   No SOURCES given to target: upnp_objects
1> [CMake] 
1> [CMake] 
1> [CMake] CMake Error at upnp/CMakeLists.txt:122 (ADD_LIBRARY):
1> [CMake]   No SOURCES given to target: upnp_shared
1> [CMake] 
1> [CMake] 
1> [CMake] CMake Error at upnp/unittest/CMakeLists.txt:1 (ADD_EXECUTABLE):
1> [CMake]   No SOURCES given to target: unittest
1> [CMake] 
1> [CMake] 
1> [CMake] CMake Generate step failed.  Build files cannot be regenerated correctly.
1> 'cmd.exe' '/c ""C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO\2019\COMMUNITY\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\CMAKE\CMake\bin\cmake.exe"  -G "Ninja"  -DCMAKE_BUILD_TYPE:STRING="Debug" -DCMAKE_INSTALL_PREFIX:PATH="D:\C++\pupnp_Vollstrecker\out\install\x64-Debug (default)" -DCMAKE_C_COMPILER:FILEPATH="C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.27.29110/bin/Hostx64/x64/cl.exe" -DCMAKE_CXX_COMPILER:FILEPATH="C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.27.29110/bin/Hostx64/x64/cl.exe"  -DCMAKE_MAKE_PROGRAM="C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO\2019\COMMUNITY\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\CMAKE\Ninja\ninja.exe" "D:\C++\pupnp_Vollstrecker" 2>&1"' execution failed with error: ''cmd.exe' '/c ""C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO\2019\COMMUNITY\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\CMAKE\CMake\bin\cmake.exe"  -G "Ninja"  -DCMAKE_BUILD_TYPE:STRING="Debug" -DCMAKE_INSTALL_PREFIX:PATH="D:\C++\pupnp_Vollstrecker\out\install\x64-Debug (default)" -DCMAKE_C_COMPILER:FILEPATH="C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.27.29110/bin/Hostx64/x64/cl.exe" -DCMAKE_CXX_COMPILER:FILEPATH="C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.27.29110/bin/Hostx64/x64/cl.exe"  -DCMAKE_MAKE_PROGRAM="C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO\2019\COMMUNITY\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\CMAKE\Ninja\ninja.exe" "D:\C++\pupnp_Vollstrecker" 2>&1"' returned with exit code: 1'.

Note that Pthreads4Win is not available when building the solution. However, I also do not presume that this is the error that keeps me from getting this to work.

Furthermore (and this is probably due to how I expect this to work for me), it automatically tries to build x64-debug, building/caching everything to a corresponding output dir. Now, when I want to build x64-release or x86-debug I need to manually add configurations in Visual Studio, which would then be stored in a CMakeSettings.json file. Since it is my aim to have it all compile after opening the solution file (or after integrating the project files in another solution file, for the matter) and hitting the build solution button, this is also undesireable.

Please let me know if you need anything else. Any improvement will be much appreciated!

Vollstrecker commented 3 years ago

Sorry for the delay, too many parallel stuff going on.

First, it's not unusual for build-systems to fail if source-files are removed, VS, autotools, you name it, so your 3rd step causes the first problems. I'm going to adjust this all, when the process itself works.

Second, I know it is possible (and usually works), but I really not recommend to use the VS-cmake module. The best thing of cmake is, that it's always possible to build outside the source-tree, so you don't pollute your source with anything generated but not needed. VS always stores CMakeSettings.json in the source-dir. I strongly recommend cmake-gui for the configuration.

From my mind I can't remember if pthread is mandatory, but I think so. That's why I interrupted work on this stuff and switched to get pthread buildable with cmake. My final plans are, that if pthread is not foundwhile configuration, it's downloaded into the build-dir and configured there. Then it is built while building upnp, and then it is installed while upnp is installed. That's the original plan from amule, which then downloads upnp, which then keeps track of it's own deps.

Finally the release/debug flavors will be added as a last step. Adding them all together to the project is way less work, than doing the whole work for all flavors in parallel. So I first get everything from the last paragraph done, then the unittests, and then the comfort-functionalities.

mrjimenez commented 3 years ago

Hi Vollstrecker,

Posix threads are required. It seems reasonable to require a previous installation of a pthread library on config. The Linux autotools files require it and simply abort the build process if pthreads are not found.

Care must be taken if using MinGW64, because it is an option to install it with its own thread library, in which case it is not necessary to download and build. I don't know about other compilers.

There is a git repository in sourceforge for a project called POSIX Threads for Windows that has been updated about a year ago. I don't know if this is the best choice. The home page claims that posix code should run unmodified, so it seems like a good thing. From my past experience with Windows, I would try to build a DLL and run with it, I would not link it statically, but this is up to you.

https://sourceforge.net/projects/pthreads4w/

git repo: $ git clone git://git.code.sf.net/p/pthreads4w/code pthreads4w-code

Regards, Marcelo.

Stullemon commented 3 years ago

Yeah, that's actually the one i used for building on Windows... For all i can tell: It appears to be working just fine.

Vollstrecker commented 3 years ago

I found that one already, I hoped to find something similar on github, but here the youngest is from 2016. Maybe I'll clone that into a repo here and keep it in sync with the sf one. I need to add cmake-support there, too. Otherwise I would have to configure it outside cmake with the way they provide, including the checks to make sure their buidl-environment is complete.

For sure there is a switch to turn downloading and building of the deps, and even if it is turned on, the checks if the system-provided one is useable are always run, so download happens only when there's no other possibillity.

Same problem would occur on linux, too. As I aim to get one build-system for all plattforms.

mrjimenez commented 3 years ago

Hi again,

On Wed, Nov 18, 2020 at 6:44 PM Vollstrecker notifications@github.com wrote:

For sure there is a switch to turn downloading and building of the deps, and even if it is turned on, the checks if the system-provided one is useable are always run, so download happens only when there's no other possibillity.

Same problem would occur on linux, too. As I aim to get one build-system for all plattforms.

In fact, that is a problem only in very old linux distributions. Posix threads have long been incorporated in glibc, it is unlikely that it does not pass the configure test in any recent system.

The automatic download feature is really a plus, I think it could even be postponed in a first release. But again, that's your call.

Best regards, Marcelo.

Stullemon commented 3 years ago

I found that one already, I hoped to find something similar on github, but here the youngest is from 2016. Maybe I'll clone that into a repo here and keep it in sync with the sf one.

I actually cloned it to here, already: https://github.com/Stullemon/pthreads4w

Vollstrecker commented 3 years ago

threads have long been incorporated in glibc

Jep, that's why it is hard to find them as separate sources. But checking for them (or better for the correct compiler switches) and stopping config seems better to me than getting strange compile errors afterwards.

The automatic download feature is really a plus, I think it could even be postponed in a first release.

I remember trying to follow the instructions with downloading and compiling this stuff like in the README (iirc). I failed miserably, so doing the cmake for this is needed anyways (at least for me, as I'm still not experienced enough with dev-stuff on win) to get upnp finished. The download part is just 2 more lines when that is done. I think I postpone the unittests (of both) for the first release as it's not trivial to define them in subdirs (which obviously happens with separate downloaded stuff).

I actually cloned it to here

You want to to commit directly there, do you prefer pull-requests?

Vollstrecker commented 3 years ago

I made some big steps, the pthreads is done (execpt the unittests), but with upnp installation I have a little problem. Is there any reason to have the DEBUG/NDEBUG defines in the outconfig instead of the cmd-line?

I mean, if they would be on cmd-line I wouldn't have to create two autoconfig.h and two sample_config.h, and projects including that stuff usually have them on cmdline for their own stuff anyways.

Stullemon commented 3 years ago

I actually cloned it to here

You want to to commit directly there, do you prefer pull-requests?

We could push it into my repository, if you like. However, I want to clarify that I will not be maintaining the repository actively. So we can do it whichever way you think is best.

Also, great to know you are making progress. I cannot say anything useful about your question, though. Sorry about that.

mrjimenez commented 3 years ago

I made some big steps, the pthreads is done (execpt the unittests), but with upnp installation I have a little problem. Is there any reason to have the DEBUG/NDEBUG defines in the outconfig instead of the cmd-line?

I mean, if they would be on cmd-line I wouldn't have to create two autoconfig.h and two sample_config.h, and projects including that stuff usually have them on cmdline for their own stuff anyways.

I am sorry, I did not understand your question. What is outconfig? Do you mean configure.ac? Which cmd-line are you referring to?

autoconfig.h is automatically generated by configure. I also don't know about sample_config.h.

Regards, Marcelo.

Vollstrecker commented 3 years ago

I meant that in autoconfig.h (and I think sample_config.h, too) DEBUG or NDEBUG ist defined, so there is only the choice to build either with or without debug support, or to install the header into separate dirs. The second option isn't supported by the cmake export for the targets.

I just decided to remove them from the config and tell the source by compiler-define what it's supposed to do. So on cmake-build you will get upnp.dll and upnpd.dll for both versions (and upnps.dll and upnpsd.dll for the static ones). And the exported files let's any dependant project know about every of them.

I first thought about changing the names back to the normal ones on linux but then decided, if the distributions ship the lib built by cmake, the projects that use it, can either use the release-version as found the usual way, or switch to cmake, too.