search

dbry / WavPack

WavPack encode/decode library, command-line programs, and several plugins
BSD 3-Clause "New" or "Revised" License
371 stars 67 forks source link

CMakeLists.txt: fix dependency on libgcc when building shared Windows libs (wavpackdll.dll) #181

Closed dbry closed 7 months ago

dbry commented 7 months ago

Hi @sezero and @madebr !

One of the artifacts that I generate for WavPack releases is Windows binaries and Windows DLLs (which are not used by my executables, but can be used by other applications).

For this latest release I tested performance and found that MinGW builds were enough faster than MSVC builds to be worthwhile, so I switched to them. However, on the cmake build I found that the generated DLL did not work because it depended on libgcc. A little Googling revealed the -static-libgcc option and I noticed that you guys included that with the Cool Edit and Winamp plugins, but not elsewhere. I figured out where to put it in the CMakeLists.txt file and it works great; the libwavpack-1.dll can drop in for my MSVC-generated wavpackdll.dll and work fine (once it's renamed).

So my first question is did I do this right (the CmakeLists.txt change)?

The other thing I noticed is that even though I rename the DLL and it drops in fine, it still shows the libwavpack-1.dll name internally, for example if I do a dumpbin /EXPORTS or objdump -x. Is that something I should worry about, or is just cosmetic? Like I said, it works fine.

Thanks in advance for any advice!

madebr commented 7 months ago

I don't think we need to worry about the name. What you're seeing is the name of the original DLL name in the export directory table. It's not used by the loader or LoadLibraryA.

We're currently giving the dll another name when building a mingw dll or when building a MSVC dll here. Do you perhaps want to have both dlls to have the same name?

dbry commented 7 months ago

I don't think we need to worry about the name. What you're seeing is the name of the original DLL name in the export directory table. It's not used by the loader or LoadLibraryA.

Great, that's what I hoped.

We're currently giving the dll another name when building a mingw dll or when building a MSVC dll here. Do you perhaps want to have both dlls to have the same name?

No, I think everything is fine as long as they can be manually renamed. And I realize that my DLL name is redundant and kind of stupid, and we certainly don't want to switch to that. It was a long time ago and I never was a Visual Studio guru, but what I remember was not being able to give it the obvious name wavpack.dll because the project name collided with the wavpack.exe project name. What I chose to do was better than wavpackexe.exe; in hindsight there probably was a way to do it, but that's its name now.

Thanks for you guys' ongoing support!

sezero commented 7 months ago

Will this go in ?

dbry commented 7 months ago

Will this go in ?

Yes.