Public methods are not exported to DLL/LIB

Question

Public methods are not exported to DLL/LIB

KrzysFR opened this issue 8 years ago · comments

Christophe Chevalier commented 8 years ago

As stated in facebook/zstd#472, I would like to use FSE and HUFF0 methods from .NET which requires having a Windows DLL with public method marked as exported.

As was done for zstd, we just need to add a macro that does the same thing as here: https://github.com/facebook/zstd/blob/426a9d4b7128ef54d79627cff346173e833f733a/lib/zstd.h#L21

I can try putting a PR together for this, but I have a few questions:

Should there be a single PUBLIC_API macro used in all the fse.h, huf.h error_public.h? Or should there be multiple FSE_API, HUF_API macros to opt-in/out of each module?
Can we consider all methods declared in fse.h, huf.h and error_public.h as public, and everything else as private? What about bitstream.h and mem.h ?
the VC2012 project does not seem to provide a name for the generated dll (so it's probably . Would there be objections to updating the project to generate libfse.dll instead? Though if it can contains huff0 as well, many libfse.dll is too specific, and there should be another name for this library? (the repo is named FiniteStateEntropy but the title says "New Generation Entropy coders"...)

Christophe Chevalier commented 8 years ago

see #75

Yann Collet · Answer 1 · Tue Dec 13 2016 21:43:24 GMT+0800 (China Standard Time)

Yes on all points.
Let me first ensure latest synchronisation with zstd project.

I have no idea about a correct dll name and scope.
There is no plan to deliver stand-alone libraries for fse or huff0.
So it could be any.
Just note that huff0 depends on fse for encoding its own header.

Yann Collet · Answer 2 · Tue Dec 13 2016 22:34:24 GMT+0800 (China Standard Time)

sync completed.
ready to update for Windows DLL

Christophe Chevalier · Answer 3 · Tue Dec 13 2016 22:35:05 GMT+0800 (China Standard Time)

So we can go with a PUBLIC_API macro, that would be set only on methods exposed in fse.h and huf.h, and nothing else (for the moment). For the dll, can I suggest libfse.dll ?

Yann Collet · Answer 4 · Tue Dec 13 2016 22:35:31 GMT+0800 (China Standard Time)

yes, good to go

Christophe Chevalier · Answer 5 · Tue Dec 13 2016 22:59:41 GMT+0800 (China Standard Time)

Quick question: what about the #ifdef FSE_STATIC_LINKING_ONLY in fse.h? It looks like it defines a bunch of very internal methods that would probably not be used with Windows dll directly, so maybe they should be exported? (such as FSE_count_wksp, FSE_countFast_wksp, FSE_buildCTable_rle, FSE_encodeSymbol, ...)

Edit: same with with HUF_STATIC_LINKING_ONLY in huf.h

Yann Collet · Answer 6 · Tue Dec 13 2016 23:35:10 GMT+0800 (China Standard Time)

It's up to you.
I would suggest to not expose them if you don't need them.

btw : that's the purpose of calling the unlocking macro FSE_STATIC_LINKING_ONLY...

Christophe Chevalier · Answer 7 · Tue Dec 13 2016 23:45:15 GMT+0800 (China Standard Time)

I'm writing the .rc files (adds descriptions, copyright and file versions to .exe and .dll) and I was not able to find any version information in the .h files .... so... what is the current version of FSE ? :)

I can add FSE_VERSION_MAJOR and cie, so that I can reuse the same trick in zstd.rc (includes zstd.h directory and use the the ZSTD_VERSION_xxx macros)

Yann Collet · Answer 8 · Wed Dec 14 2016 00:03:30 GMT+0800 (China Standard Time)

There is no version number on fse yet.
Reason is, it was not forecasted to be a stand-alone library.
But if now it is, then it indeed requires a version number

No clear idea about best version number.
Maybe 1.0.0, since it's part of zstd >= 1.0.0, hence is supposed to be stable.
Or 0.9.0 if there is a need to test all this before moving to 1.0.0.