MantisBT - Buildsystem
View Issue Details
0002618Buildsystem[All Projects] Generalpublic2018-09-24 18:302019-08-01 11:33
ReporterJ. Peter Mugaas 
Assigned To 
StatusclosedResolutionno change required 
PlatformWindows (mingw-w64_OSWindows 10 64-bitOS Version
Fixed in CI build #
Reported in CI build #
Summary0002618: buildsystem fails to compile shared libraries
DescriptionI was trying to build some libraries such as libparseutils and libhubbub using the build system. Unfortunately, the build system did not work on Windows mingw-w64 toolchains There's several issues involved here.

1) .DLL's unlike .so links are NOT symlinked to reflect version information. In fact, symlinking may not always expected in Windows.
2) The filename conventions for shared libraries are different. In MSVC and MINGW are probably different when it comes to file names. The library extension is not .a but ".lib". The shared library run-time is named with a .DLL extension and typically, the filename does not include version information. If MINGW, a prefix of "lib" is used for the .DLL but inCygwin, the.DLL prefix is "cyg" and if compiling for MSYS2, the prefix of "msys-" is used instead.
3) In Windows, shared libraries involve two files, a .DLL and an import library for the .dll that in MINGW, would be named .dll.a. The CygWin developers have written about this at: and the MINGW authors have also written their related notes: .
4) The .dll is placed in a binary directory or in the same directory as the .exe that uses it or possibly anyplace on the user's PATH environment variable. In Cygwin, MSYS2, and MINGW distributions with a bash environment, they are put in the bin dir instead of the lib dir.
5) Instead of using symlinks to denote versions, the .DLL contains the version information inside the .DLL using a resource file.

I tried look at the netsurf buildsystem but my attempts to try adjust it have failed probably because I don't understand how things go together and I rather suspect that whatever work I do would be a cludge or crude hack So I gave up any attempt to use it opting instead to build libparseutils, libhubbub, and libwapcatlet using the CMake build system and I will be more happy to contribute a CMakeLists.txt file that I used to build those libraries.

CMake seems to offer several advantages over the netsurf-buildsystem.
1) You can build your binaries in separate directories from your source-code. You could actually have several sets of compiled binaries. I have two sets (one for Win32 and one for Win64) but you could use a number of different toolchains if you wish.
2) You do NOT need to know how something is compiled or filename conventions for a platform or compiler target.
3) You can actually compile BOTH a static version and a shared version in one go (you just define two libraries in CMake,one static and one shared).
4) You can do various types of fix ups depending upon what software is available on your system. In MSYS2 environment using the MINGW compilers, you have pkg-config available as a well as a number of other libraries and it is easy to make adjusts for platform differences. In Windows for example, iconv is not in the C RTL so you use a separate library such as GNU iconv or win-iconv.
Steps To ReproduceTry compiling using "Shared Library" as a component with the MINGW environment.
TagsNo tags attached.
Attached Files

Daniel Silverstone   
2019-08-01 11:33   
It is not intended at this time to support shared library builds of the NetSurf libraries. They are implementation details of the browser and not meant to be used in a shared scenario.

In addition, none of us here use CMake and as such, CMakeLists will not be accepted simply because we are unable to maintain them.

Thank you for your efforts and other bug reports.

Issue History
2018-09-24 18:30J. Peter MugaasNew Issue
2019-08-01 11:33Daniel SilverstoneStatusnew => closed
2019-08-01 11:33Daniel SilverstoneResolutionopen => no change required
2019-08-01 11:33Daniel SilverstoneNote Added: 0002046