Compiling libopenshot-audio using vs2017
francescoBLT opened this issue · 4 comments
I have attempt to compile libopenshot audio library following instructions at
https://docs.google.com/document/d/1V6nq-IuS9zxqO1-OSt8iTS_cw_HMCpsUNofHLYtUNjM/pub#h.ghqtfouqkkkd
it seems all ok but compiling the test program openashot-audio-test-sound, compiler reports
that is unable to find library libopenshot-audio.lib. I've attempt to create it starting from the
dll (libopenshot-audio.dll) but it seems that this dll haven't any exported function. Using implib
result is:
Digital Mars Import Library Manager Version 7.6B1n
Copyright (C) Digital Mars 2000. All Rights Reserved.
Error(3): No exported functions. Library not created
And if I use the classic dumpbin result is:
Microsoft (R) COFF/PE Dumper Version 14.13.26131.1
Copyright (C) Microsoft Corporation. All rights reserved.
Dump of file openshot-audio.dll
File Type: DLL
Summary
1000 .00cfg
D000 .data
5000 .idata
A6000 .rdata
32000 .reloc
1000 .rsrc
53B000 .text
1000 .tls
Can you help please ?
Regards
[Windows 10 Pro ]
Sorry, up to now no, I haven't. The dll is unusable due to lack of entry point.
I suspect the basic issue here is that we build with gcc, which by default generates ELF shared libraries — an object format where all symbols are marked public by default. There's no need to export anything. (Presumably MinGW gcc builds DLLs in a similar fashion, so that source code intended for building with Linux GCC will still work when compiled to MinGW DLL.) Our ProJucer configuration similarly uses a generator that targets Linux Makefiles in setting up the JuceLibraryCode directory.
Other compilers/formats require explicit export annotations, or other methods of indicating what symbols should be exported. ProJucer has a completely separate exporter for Visual Studio, which we're of course not running.
I'll transfer this issue to libopenshot-audio since that's what it was about (openshot-qt doesn't have any compiled components at all), but given that this is something we don't support and are unlikely to have the resources to support, anyone looking to build with a compiler other than gcc would be pretty much on their own for getting it to work. We might be able to offer some input, but it's not anything we've made work or have plans to make work.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.