0002618: buildsystem fails to compile shared libraries

View Issue Details [ Jump to Notes ]

[ Issue History ] [ Print ]

Project

Category

View Status

Date Submitted

Last Update

0002618

Buildsystem

[All Projects] General

public

2018-09-24 18:30

2019-08-01 11:33

Reporter

J. Peter Mugaas

Assigned To

Priority

normal

Severity

feature

Reproducibility

always

Status

closed

Resolution

no change required

Platform

Windows (mingw-w64_

Windows 10 64-bit

OS Version

Summary

0002618: buildsystem fails to compile shared libraries

Description

I 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: https://cygwin.com/cygwin-ug-net/dll.html and the MINGW authors have also written their related notes: http://www.mingw.org/wiki/sampledll .
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 Reproduce

Try compiling using "Shared Library" as a component with the MINGW environment.

Date Modified	Username	Field	Change
Issue History
2018-09-24 18:30	J. Peter Mugaas	New Issue
2019-08-01 11:33	Daniel Silverstone	Status	new => closed
2019-08-01 11:33	Daniel Silverstone	Resolution	open => no change required
2019-08-01 11:33	Daniel Silverstone	Note Added: 0002046

Relationships