We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 2026 - DECLSPEC macro for MSVC always on export
Summary: DECLSPEC macro for MSVC always on export
Status: RESOLVED WONTFIX
Alias: None
Product: SDL
Classification: Unclassified
Component: *don't know* (show other bugs)
Version: HG 2.0
Hardware: All Windows (All)
: P2 trivial
Assignee: Ryan C. Gordon
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-08-09 04:18 UTC by norfanin
Modified: 2017-09-21 02:56 UTC (History)
0 users

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description norfanin 2013-08-09 04:18:56 UTC 
When the Microsoft Visual C++ compiler is used, the current code in include/begin_code.h always defines DECLSPEC as __declspec(dllexport). It doesn't look like this is a problem as the linker seems to ignore the attribute when trying to resolve the symbol.

If the linking application would use __declspec(dllimport) instead, then the compiler can optimize one indirection away. However, this will cause errors when the linking application uses a static SDL library and a manual DECLSPEC override is necessary.

This may be a case where convenience wins, but I would like to suggest to drop the dllexport when an application includes the headers of SDL.

It could look similar to that borland part where BUILD_SDL is set by the Visual Studio projects.

#ifdef BUILD_SDL
# define DECLSPEC __declspec(dllexport)
#else
# define DECLSPEC
#endif
Comment 1 Ryan C. Gordon 2015-02-19 05:22:19 UTC 
Marking a large number of bugs with the "triage-2.0.4" keyword at once. Sorry if you got a lot of email from this. This is to help me sort through some bugs in regards to a 2.0.4 release. We may or may not fix this bug for 2.0.4, though!
Comment 2 Sam Lantinga 2017-08-15 06:59:01 UTC 
If the linker ignores the attribute when trying to resolve the symbol, what's the harm in leaving it as it is? Just clarity on what's happening?
Comment 3 norfanin 2017-09-21 01:37:54 UTC 
I don't remember why I suggested that.

If it ain't broke..., I guess.
Comment 4 Sam Lantinga 2017-09-21 02:56:32 UTC 
Okay, closing as "it ain't broke" :)

Thanks!