-
Notifications
You must be signed in to change notification settings - Fork 39
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sun CC compiler generates warnings about linkage #6
Comments
Comment by ladanyi created at 2006-12-10 04:50:14 Will fix it later when we figure out how to do it properly. For now, let's live with the warnings... --Laci |
Comment by ladanyi created at 2006-12-10 04:50:14 Changing assignee from somebody to ladanyi. |
Comment by ladanyi created at 2006-12-10 04:50:14 Changing status from new to assigned. |
The offending code had been changed to
in f209c9b (BSP 12 years ago). I'll assume that this fixed the issue. Please reopen if you can still reproduce with current code. |
Issue created by migration from Trac.
Original creator: @mjsaltzman
Original creation time: 2006-10-04 15:58:18
Assignee: somebody
Version:
During a make of CLP using the Solaris CC compiler (CC: Sun C++ 5.7 2005/01/07), the following warnings are generated:
The offending lines in CoinModelUseful2.cpp are:
See the discussion here: http://docs.sun.com/source/819-3689/Ch3.Std.html, Section 3.11.
The problem is that the standard C library functions are declared with "C" linkage in the Sun libraries. The "anachronism" and the fact that they are warnings stem from the fact that "C" and "C++" linkage are binary-compatible in the Sun libs, but (a) they need not be (in which case, things are likely to break), and (b) the C++ standard permits standard C lib functions to have either "C" or "C++" linkage.
The warning can be eliminated in this case by enclosing the declaration of struct init in
extern "C" {...} (and similarly enclosing the declaration of struct symrec in CoinModelUseful.hpp), but for systems where the standard C functions have C++ linkage, that won't work. I can't think of a completely portable way to handle this other than to define in BuildTools a preprocessor symbol such as STD_C_FUNCTION_LINKAGE, which is defined to be C or C++ depending on the compiler and define the structs inside extern "STD_C_FUNCTION_LINKAGE" {...}. Even that's not quite ideal, as the structs could then only be used to hold pointers to standard C functions.
The text was updated successfully, but these errors were encountered: