Master issue for static library nonsense: Windows resource file copying and Unix build oddities

[andlabs]

libui needs to be available as both a static and as a dynamic library, as different users have different requirements. Static libraries have two major issues:

• they share the same symbol namespace with whatever they are linked to
• on Windows, static libraries can't have resources

Right now, libui tries to hack around all this by a) obfuscating non-public symbols using a trick deduced by @pcwalton b) manually copying the compiled resources.o file on Windows into the build\out folder so it can be linked into binaries.

These options have caused nothing but build issues and maintenance nightmares for everyone, including myself, so I'm going to be fixing this properly:

• prefix all non-public names that aren't static with uipriv
• embed compiled resources on Windows directly into the binary somehow

I need to figure out whether all structs and classes (including ones only used in one source file) need to have this too. All GObject and Objective-C classes also need this change, because they share an application-global namespace regardless.

I need to figure out how to do the Windows resource precompiling thing in a way suitable for each toolchain.

[mischnic]

The macOS linker warning (built for newer OSX version (10.11) than being linked (10.8)) should already be fixed with this:

libui/CMakeLists.txt

Line 19 in 51f72ab

set(CMAKE_OSX_DEPLOYMENT_TARGET "10.8" CACHE STRING "" FORCE)

You can test this with:

$ otool -l out/libui.a | grep -A3 LC_VERSION_MIN_MACOSX
      cmd LC_VERSION_MIN_MACOSX
  cmdsize 16
  version 10.8
      sdk n/a

$ otool -l out/libui.dylib | grep -A3 LC_VERSION_MIN_MACOSX
      cmd LC_VERSION_MIN_MACOSX
  cmdsize 16
  version 10.8
      sdk 10.13

[andlabs]

Oh good, so it's already fixed then because package ui on OS X currently uses a cmake build with that patch applied. Either way, those issues can be closed. (And that problem is far from the only one here.)

[DemiMarie]

I think we should localize symbols in static libraries where we can.

[andlabs]

What do you mean?

[DemiMarie]

@andlabs I think we should keep using objcopy --localize-hidden whenever it is available on the build machine. CMake can easily check for this.

[andlabs]

Why?

For the record, the current static library hacks (all of them combined) doesn't properly inherit object options like -fPIC, relies on things having specific pathnames that have proven wrong many times, and the resultant .a file doesn't get rebuilt when the source files change, which is annoying for testing.

[andlabs]

Windows resource copying is gone now. cmake builds should Just Work™.

[andlabs]

Oops, forgot to mark unix-namespace-cleanup as part of this issue.

Most of the immediate work is now finished. I still need to finalize naming policy and apply these fixes to Windows, but we should be better off than before in the meantime. I'll probably make this stop blocking Alpha 4's release now...