When using wraps, How To link a binary to static libraries

[andy5995]

I'm trying to build NetPanzer so it will link to static libraries that are built via meson wraps. Though I've specified default_options: 'default_library=static' for the 5 dependencies, when I build on Linux (in a docker container where the dependencies aren't installed), ldd reports the resulting binary as linking dynamically to all of them.

My meson.build is in netpanzer/netpanzer#133

Clearly trying to use the wrap system primarily for a Windows build, I could see possibly shipping NetPanzer with the dlls, but I can't imagine installing them to Windows system locations when the binary is installed. What do most Windows developers do in cases like this? I don't normally develop on Windows and not familiar with the environment, to be honest, so I'm pretty much open to feedback about this.

I searched the meson docs of course, and found these tickets that are possibly related:

#8047
#10472

[eli-schwartz]

phyfs_dep = dependency('physfs', required: false)
if not phyfs_dep.found()
  phyfs_dep = cc.find_library('physfs', has_headers: 'physfs.h', required: false)
  if not phyfs_dep.found()
    # This will use the fallback
    phyfs_dep = dependency('physfs')
    # or
    phyfs_dep = dependency(
      'physfs',
      required: false,
      fallback: 'physfs',
      default_options: ['default_library=static']
      )
  endif
endif
deps += phyfs_dep

So what you're doing here is 4 lookups:

• dependency (external, optional)
• find_library(external, optional)
• dependency (mandattory)
• dependency (subproject fallback, optional)

Only if the number 4 lookup is the one that gets found, does the default_options for it apply. But it seems to be a straight-up duplicate of the number 3 lookup (it cannot fail, because it is defaulting to required: true).

There is a good reason to use the number 1 and number 2 lookups as you've done, iff you cannot rely on dependency() working but want to find an external physfs. This assumes, however, that physfs can be installed without a pkg-config file.

It works because the number 1 lookup is not required, so by default it won't use a subproject fallback. Hence you advance to the find_library lookup, and only trigger subprojects after find_library has failed too.

[andy5995]

Thanks. I was confused by that third lookup. I essentially copied from the meson docs.

[eli-schwartz]

Sorry, the "or" there meant "you can either use the previous line in your own meson.build, or else you can use the next line".

[andy5995]

After applying those changes, the binary is much improved. But for some reason it's still linking to the SDL2 so, and the dependencies of the explicitly specified dependences, such as freetype and vorbis (required by sdl2_mixer.

        linux-vdso.so.1 (0x00007ffdd3108000)
        libvorbisfile.so.3 => /netpanzer/docker3_build/./subprojects/libvorbis-1.3.7/lib/libvorbisfile.so.3 (0x00007f6595bf2000)
        libsdl2.so => /netpanzer/docker3_build/./subprojects/SDL2-2.28.5/libsdl2.so (0x00007f6595916000)
        libfreetype.so.6 => /netpanzer/docker3_build/./subprojects/freetype/libfreetype.so.6 (0x00007f6595817000)
        libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f65955e8000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f65954ff000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f65954df000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f65952b6000)
        libvorbis.so.0 => /netpanzer/docker3_build/./subprojects/libvorbis-1.3.7/lib/libvorbis.so.0 (0x00007f6595279000)
        libogg.so.0 => /netpanzer/docker3_build/./subprojects/libvorbis-1.3.7/lib/../../libogg-1.3.5/src/libogg.so.0 (0x00007f659526c000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f6595f96000)

I've pushed my changes to the meson.build

[andy5995]

I think you answered this here so I'll try that soon, but I have high hopes it's all solved, thanks to your help.