Building on windows gives "LINK : fatal error LNK1189: library limit of 65535 objects exceeded [D:\repos\libossia\build\src\ossia.vcxproj]"

[onar3d]

Hi!

When I try to build the latest master on windows I get the following:

PS D:\repos\libossia\build> cmake --build .
MSBuild version 17.11.2+c078802d4 for .NET Framework

artnet.vcxproj -> D:\repos\libossia\build\libartnet\Debug\artnet.lib
coap-3.vcxproj -> D:\repos\libossia\build_deps\libcoap-build\Debug\coap-3.lib
kfr_dsp_avx.vcxproj -> D:\repos\libossia\build\kfr_build\lib\kfr_dsp_avx.lib
kfr_dsp_avx2.vcxproj -> D:\repos\libossia\build\kfr_build\lib\kfr_dsp_avx2.lib
kfr_dsp_avx512.vcxproj -> D:\repos\libossia\build\kfr_build\lib\kfr_dsp_avx512.lib
kfr_dsp_sse2.vcxproj -> D:\repos\libossia\build\kfr_build\lib\kfr_dsp_sse2.lib
kfr_dsp_sse41.vcxproj -> D:\repos\libossia\build\kfr_build\lib\kfr_dsp_sse41.lib
kfr_io.vcxproj -> D:\repos\libossia\build\kfr_build\lib\kfr_io.lib
dnssd-static.vcxproj -> D:\repos\libossia\build\lib\Debug\dnssd-static.lib
libremidi.vcxproj -> D:\repos\libossia\build\3rdparty\libremidi\Debug\libremidi.lib
re2.vcxproj -> D:\repos\libossia\build\Debug\re2.lib
rnd.vcxproj -> D:\repos\libossia\build\3rdparty\rnd\Debug\rnd.lib
samplerate.vcxproj -> D:\repos\libossia\build\3rdparty\libsamplerate\Debug\samplerate.lib
rubberband.vcxproj -> D:\repos\libossia\build\3rdparty\rubberband\Debug\rubberband.lib
wiiuse.vcxproj -> D:\repos\libossia\build\wiiuse\src\Debug\wiiuse_debug.lib
Auto build dll exports
LINK : D:\repos\libossia\build\src\Debug\ossia_x64d.dll not found or not built by the last incremental link; performi
ng full link
LINK : fatal error LNK1189: library limit of 65535 objects exceeded [D:\repos\libossia\build\src\ossia.vcxproj]

I cloned, submodule updated, ran cmake, and cmake --build, with no settings changed.
I suppose that's not how you build libossia for ossia score on windows?

[jcelerier]

hum that's strange, ossia score bundles libossia and exports much more symbols, yet less than the 65k limit. I'll investigate.
Can you share the link line ?
Also I see that MSVC is bundling a lot of libraries but if you only use libossia for oscquery you can really slim it down with -DOSSIA_OVERRIDE_PROTOCOLS=OSCQUERY -DOSSIA_EDITOR=0 -DOSSIA_DATAFLOW=0, this way it won't build with e.g. wiimote support, FFT and a full-blown DAW & dataflow system builtin :)

[jcelerier]

Not on windows at the moment but if on linux I build in release with these flags:

$ nm -CD src/libossia.so  | egrep ' (T|t) ' | wc -l
1235

I get 1235 exported symbols (in particular I'm seeing that re2 symbols are mistakenly exported... will fix that but that's still just 328-ish symbols).

[jcelerier]

I get around the same number in debug mode. I'll try with MSVC on windows.

[onar3d]

Hi, I was traveling for a while and left my dev machine at home so I couldn't follow up on this, but now I'm back.

I pulled master and tried building again just in case, That didn't make a difference, so I configured with "-DOSSIA_EDITOR=0 -DOSSIA_DATAFLOW=0" and built again. It still reached the limit.

So I added "-DOSSIA_OVERRIDE_PROTOCOLS=OSCQUERY", configured and built, that worked fine!

All the above were with a debug build configuration only, I should add.

I've since tried a release build, and actually with that there's no problem!

But I guess I can leave the issue open since it persists with the debug build?

Thanks for looking in to this!

Now on to making my old code work with this new release - I imagine there might have been some breaking changes, the build I use is a few years old, 1.0.x IIRC :)

[jcelerier]

hmm since 1.0 there actually shouldn't be too many deep changes for the oscquery part, unless you opt-in to the new class that work with a boost.asio context (in order to have more control over threading, etc)

[jcelerier]

and yes, I still want to make sure that it's possible to produce workable debug builds! Although I assume this is happening because of no inlining at /O0..

[onar3d]

Hi,

This is along the same lines, so I figured I'd write in the same thread, even if it's not the exact same issue.

Building and running on Windows worked fine:

cmake .. -DOSSIA_EDITOR=0 -DOSSIA_DATAFLOW=0 -DOSSIA_EXAMPLES=1 -DOSSIA_CPP=ON -DOSSIA_OVERRIDE_PROTOCOLS=OSCQUERY
cmake --build . --config Release
Finally
cmake --build . --config Release --target INSTALL
Created a folder with include / bin / lib folders that I could use to add libossia to my project. There were some refactors in my code needed since it was old, but nothing dramatic.

NOW, I want to replicate this on MacOS.

But, the result is not comparable - when I run target install, the include folder doesn't contain a boost subfolder for example.

And when I try to build on mac pointing to that folder, it fails because it doesn't find a "variant":

#if __has_include(<boost/variant2.hpp>)
#include <boost/variant2.hpp>
namespace ossia_variant_alias = boost::variant2;
#else
#include <mpark/variant.hpp> <---- it fails here
namespace ossia_variant_alias = mpark;
#endif

NOW, if I copy over the "install" folder from windows, it works, and builds, but I'm not sure that's the best solution!

Also, with the above, I get OSC Query working, BUT, when I try to delete the generic device, created as follows:

std::make_uniqueossia::net::generic_device(std::unique_ptrossia::net::protocol_base(protocol), "Mirror");

I get a crash:

libossia.dylib`ossia::net::generic_device::~generic_device:
0x109c53364 <+0>: sub sp, sp, #0x20
0x109c53368 <+4>: stp x29, x30, [sp, #0x10]
0x109c5336c <+8>: add x29, sp, #0x10
0x109c53370 <+12>: str x0, [sp, #0x8]
0x109c53374 <+16>: ldr x0, [sp, #0x8]
0x109c53378 <+20>: str x0, [sp]
0x109c5337c <+24>: bl 0x109c5331c ; ossia::net::generic_device::~generic_device()
-> 0x109c53380 <+28>: ldr x0, [sp]
0x109c53384 <+32>: bl 0x10a09e968 ; symbol stub for: operator delete(void*)
0x109c53388 <+36>: ldp x29, x30, [sp, #0x10]
0x109c5338c <+40>: add sp, sp, #0x20
0x109c53390 <+44>: ret

And one step in:

libc++.1.dylib`std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator>::~basic_string:
0x1978b62c8 <+0>: pacibsp
0x1978b62cc <+4>: stp x20, x19, [sp, #-0x20]!
0x1978b62d0 <+8>: stp x29, x30, [sp, #0x10]
0x1978b62d4 <+12>: add x29, sp, #0x10
0x1978b62d8 <+16>: mov x19, x0
-> 0x1978b62dc <+20>: ldrsb w8, [x0, #0x17]
0x1978b62e0 <+24>: tbz w8, #0x1f, 0x1978b62ec ; <+36>
0x1978b62e4 <+28>: ldr x0, [x19]
0x1978b62e8 <+32>: bl 0x1978fff30 ; symbol stub for: operator delete(void*)
0x1978b62ec <+36>: mov x0, x19
0x1978b62f0 <+40>: ldp x29, x30, [sp, #0x10]
0x1978b62f4 <+44>: ldp x20, x19, [sp], #0x20
0x1978b62f8 <+48>: retab

The above is from a debug build on MacOS, sorry I'm not a Mac dev - at all - and so the stack trace might not be the most useful, I'm not sure why it doesn't contain debug info, the dylib I use IS a debug build.

The exact same code works fine on Windows. I get the crash both with the master branch, and with v2.0.0-rc4, on Mac. On Windows I just use master.

Can the above instability be because I use the include folder created on windows? or is it a bug?

My code is attached here in case it's useful - with a lot of debug printing, TODO's etc, since it's not production code...

Archive.zip

The methods that are relevant are void OSCQueryAddress::connectAndQuery(), and, disconnect(), which is where the crash happens, when I set m_Device to nullptr.

It won't build and run, but it might give you a view. It worked fine with the older libossia version for years, and works also now on windows - the only change I've made after the update is comment some secondary functionality that wasn't building any longer, and to use the .osc_address() field on the node instead of the "ossia::net::osc_parameter_string(n);" call of before.

If there's any more information you need, or if it's easier in any way to diagnose, feel free to email also, it's onar3d at gmail.
Thanks!

[onar3d]

On that note - I don't want to build from source unless I have to of course, maybe there is a distribution I can download and use? I didn't find any recent one on gihub.

Also, maybe I should get cmake to create a .framework from libossia? Currently it's "just" a dylib, created with the same configuration as for windows. I saw a framework option in CMAKE, is that what it's for?