auto-link and comeau?
I've made source changes to accommodate Comeau. Now even static libraries fail to compile on with this compiler. Is this the intention or am I missing something. Robert Ramey
Robert Ramey wrote:
I've made source changes to accommodate Comeau.
Now even static libraries fail to compile on with this compiler.
Is this the intention or am I missing something.
Robert, There's so little context in this message that it's almost impossible to imagine anybody giving a useful answer. Whose intention? Which libraries fail to compile? What kind of failures do you see? I'm sure you understand that nobody at Boost intends for all library compilations to fail, so it's hard to even understand your question. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
OK - a) The document re:auto-link indicates that not all platforms support it. That leaves me wondering what happens when the macros are included in the library source code an its compiiled? Is there an error message. Does everything work with the same as w/o auto-linking macros? b) I notice that Comeau doesn't show up in the test matrix. This made me wonder if the configuration for the comeau compiler has been updated to consider the auto-link idea. In fact, since Commeau is a "pre-compiler" its not even clear to me that can be fit in. c) When I build with comeau. The auto-link macros seem to be undefined. This makes me wonder if the config files ro comeau need to be altered to take this into account. d) The above makes me wonder if comeau config files have not been kept up. So my question is: Have comeau config files been kept up with changes required to support auto-link. If so, why is not comeau appearing in the test matrix? Robert Ramey David Abrahams wrote:
Robert Ramey wrote:
I've made source changes to accommodate Comeau.
Now even static libraries fail to compile on with this compiler.
Is this the intention or am I missing something.
Robert,
There's so little context in this message that it's almost impossible to imagine anybody giving a useful answer. Whose intention? Which libraries fail to compile? What kind of failures do you see?
I'm sure you understand that nobody at Boost intends for all library compilations to fail, so it's hard to even understand your question.
After some investigation, I've concluded that the addition of auto-link macros doesn't break normal static library builds. So that's OK. I'm still investigating the other questions. Robert Ramey wrote:
OK -
a) The document re:auto-link indicates that not all platforms support it. That leaves me wondering what happens when the macros are included in the library source code an its compiiled? Is there an error message. Does everything work with the same as w/o auto-linking macros?
b) I notice that Comeau doesn't show up in the test matrix. This made me wonder if the configuration for the comeau compiler has been updated to consider the auto-link idea. In fact, since Commeau is a "pre-compiler" its not even clear to me that can be fit in.
c) When I build with comeau. The auto-link macros seem to be undefined. This makes me wonder if the config files ro comeau need to be altered to take this into account.
d) The above makes me wonder if comeau config files have not been kept up. So my question is:
Have comeau config files been kept up with changes required to support auto-link. If so, why is not comeau appearing in the test matrix?
Robert Ramey
David Abrahams wrote:
Robert Ramey wrote:
I've made source changes to accommodate Comeau.
Now even static libraries fail to compile on with this compiler.
Is this the intention or am I missing something.
Robert,
There's so little context in this message that it's almost impossible to imagine anybody giving a useful answer. Whose intention? Which libraries fail to compile? What kind of failures do you see?
I'm sure you understand that nobody at Boost intends for all library compilations to fail, so it's hard to even understand your question.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Robert Ramey wrote:
a) The document re:auto-link indicates that not all platforms support it. That leaves me wondering what happens when the macros are included in the library source code an its compiiled? Is there an error message. Does everything work with the same as w/o auto-linking macros?
I believe I can anser this. (If not someone will surely let me know ;-) como does not do its own linking; it uses the linker associated with the backend compiler. Therefore, if it is used in conjunction with a compiler that does not support auto link, there's no way it can support auto link. So the question is whether it supports auto link when used with a backend that supports auto link. To test this, I compiled the following program on como with VC7.1: #pragma comment(lib, "asfdhjkalsdflkjhsadf") int main() { } and got an 'unrecognized pragma' warning. Since auto link relies on pragma comment, I conclude that it doesn't work with como. Jonathan
Jonathan Turkanis wrote:
Robert Ramey wrote:
a) The document re:auto-link indicates that not all platforms support it. That leaves me wondering what happens when the macros are included in the library source code an its compiiled? Is there an error message. Does everything work with the same as w/o auto-linking macros?
I believe I can anser this. (If not someone will surely let me know ;-)
como does not do its own linking; it uses the linker associated with the backend compiler. Therefore, if it is used in conjunction with a compiler that does not support auto link, there's no way it can support auto link. So the question is whether it supports auto link when used with a backend that supports auto link. To test this, I compiled the following program on como with VC7.1:
#pragma comment(lib, "asfdhjkalsdflkjhsadf")
int main() { }
and got an 'unrecognized pragma' warning. Since auto link relies on pragma comment, I conclude that it doesn't work with como.
Comeau may have a mode that passes (unrecognized) pragmas through to the back-end compiler. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
Jonathan Turkanis wrote:
Robert Ramey wrote:
#pragma comment(lib, "asfdhjkalsdflkjhsadf")
int main() { }
and got an 'unrecognized pragma' warning. Since auto link relies on pragma comment, I conclude that it doesn't work with como.
Comeau may have a mode that passes (unrecognized) pragmas through to the back-end compiler.
True. I looked on the Comeau website and couldn't find any such option, but it may be undocumented (or I may be blind). Jonathan
David Abrahams wrote:
Jonathan Turkanis wrote:
when used with a backend that supports auto link. To test this, I compiled the following program on como with VC7.1:
#pragma comment(lib, "asfdhjkalsdflkjhsadf")
int main() { }
and got an 'unrecognized pragma' warning. Since auto link relies on pragma comment, I conclude that it doesn't work with como.
Comeau may have a mode that passes (unrecognized) pragmas through to the back-end compiler.
FWIW, I contacted Comeau support about this issue and was told that there is no such option. Jonathan
a) The document re:auto-link indicates that not all platforms support it. That leaves me wondering what happens when the macros are included in the library source code an its compiiled? Is there an error message. Does everything work with the same as w/o auto-linking macros?
The header auto_link.hpp has internal guards, so that it only emits the necessary #pragma if the compiler actually supports it, otherwise nothing happens except that the auto-link macros you defined will get #undef'ed. Even if these guards weren't present there will still be no errors, just a warning about an unrecognised #pragma.
b) I notice that Comeau doesn't show up in the test matrix. This made me wonder if the configuration for the comeau compiler has been updated to consider the auto-link idea. In fact, since Commeau is a "pre-compiler" its not even clear to me that can be fit in.
We've always had problems testing Commeau, in particular knowing what configuration to test: in the past we've tested it in strict mode - which seemed to be the most useful option - but then several perfectly good libraries were failing because Commeau in strict mode can't handle <windows.h>, so any library that wraps platform services would fail.
c) When I build with comeau. The auto-link macros seem to be undefined. This makes me wonder if the config files ro comeau need to be altered to take this into account.
What's undefined that should be? Are you sure that Commeau supports those #pragma's anyway?
d) The above makes me wonder if comeau config files have not been kept up. So my question is:
Have comeau config files been kept up with changes required to support auto-link. If so, why is not comeau appearing in the test matrix?
No one is running it, if no one is running it then it's config will not get updated, if you want to run the Commeau regression tests and keep it's config up to date then I'm sure it would be appreciated. John.
John Maddock wrote:
The header auto_link.hpp has internal guards, so that it only emits the necessary #pragma if the compiler actually supports it, otherwise nothing happens except that the auto-link macros you defined will get #undef'ed. Even if these guards weren't present there will still be no errors, just a warning about an unrecognised #pragma.
While we're on this subject, I'd like to know what you think about adding a no-name-mangling option to auto link. I would use it as follows: The Iostreams library contains several components which depend the external libraries zlib and libbzip2. I'd like to allow users to choose whether to build these libraries with bjam, in which case I'll use the current auto-linking mechanizm with the runtime library options encoded in the library name, or to link to pre-built versions of the library, in which case I'll use pragma comment (where available) together with the name of the external library file, passed as a preprocessor define. Currently I have code which looks like this (borrowed from auto_link.hpp): #if defined(BOOST_BZIP2_BINARY) # if defined(BOOST_MSVC) || \ defined(__BORLANDC__) || \ (defined(__MWERKS__) && defined(_WIN32) && (__MWERKS__ >= 0x3000)) || \ (defined(__ICL) && defined(_MSC_EXTENSIONS) && (_MSC_VER >= 1200)) \ /**/ # pragma comment(lib, BOOST_STRINGIZE(BOOST_BZIP2_BINARY)) # endif #endif I'd rather do something like this: #if defined(BOOST_BZIP2_BINARY) # define BOOST_LIB_NAME BOOST_BZIP2_BINARY # define BOOST_AUTO_LINK_NOMANGLE # include <boost/config/auto_link.hpp> #endif That way I won't have to keep repeating the guard for the compilers which support pragma comment. Another option would be to add a macro HAS_PRAGMA_COMMENT, but this is not as general, since a compiler could conceivably support auto linking in some other manner. Jonathan
I'd rather do something like this:
#if defined(BOOST_BZIP2_BINARY) # define BOOST_LIB_NAME BOOST_BZIP2_BINARY # define BOOST_AUTO_LINK_NOMANGLE # include <boost/config/auto_link.hpp> #endif
Sounds reasonable to me, there's a first cut at this in mainline cvs now, note that you don't specify a trailing ".lib" to the library name, so something like: #define BOOST_LIB_NAME zlib #define BOOST_AUTO_LINK_NOMANGLE # include <boost/config/auto_link.hpp> would link to "zlib.lib". John.
John Maddock wrote:
I'd rather do something like this:
#if defined(BOOST_BZIP2_BINARY) # define BOOST_LIB_NAME BOOST_BZIP2_BINARY # define BOOST_AUTO_LINK_NOMANGLE # include <boost/config/auto_link.hpp> #endif
Sounds reasonable to me, there's a first cut at this in mainline cvs now, note that you don't specify a trailing ".lib" to the library name, so something like:
#define BOOST_LIB_NAME zlib
Can we have something more explicit, and without abbrevs, like BOOST_AUTO_LINK_LIBRARY_NAME ??
#define BOOST_AUTO_LINK_NOMANGLE # include <boost/config/auto_link.hpp>
would link to "zlib.lib".
John.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams writes:
John Maddock wrote:
I'd rather do something like this:
#if defined(BOOST_BZIP2_BINARY) # define BOOST_LIB_NAME BOOST_BZIP2_BINARY # define BOOST_AUTO_LINK_NOMANGLE # include <boost/config/auto_link.hpp> #endif
Sounds reasonable to me, there's a first cut at this in mainline cvs now, note that you don't specify a trailing ".lib" to the library name, so something like:
#define BOOST_LIB_NAME zlib
Can we have something more explicit, and without abbrevs, like
BOOST_AUTO_LINK_LIBRARY_NAME
??
I second Dave's request here. -- Aleksey Gurtovoy MetaCommunications Engineering
Can we have something more explicit, and without abbrevs, like
BOOST_AUTO_LINK_LIBRARY_NAME
??
I second Dave's request here.
Apologies for not catching up with this, I will try to tidy up these macro names at some point, but these macros are currently scattered all over Boost - so it's not just a simple change - and may be a while coming... John.
John Maddock wrote:
I'd rather do something like this:
#if defined(BOOST_BZIP2_BINARY) # define BOOST_LIB_NAME BOOST_BZIP2_BINARY # define BOOST_AUTO_LINK_NOMANGLE # include <boost/config/auto_link.hpp> #endif
Sounds reasonable to me, there's a first cut at this in mainline cvs now
Great! Thanks. BTW, Comeau support says that adding a Windows auto-link facility is on their agenda for 2005. Jonathan
Jonathan Turkanis wrote:
BTW, Comeau support says that adding a Windows auto-link facility is on their agenda for 2005.
They could probably save a lot of time by just using the boost one. I was a mixing auto-link questions with dll questions. A more careful investigation is that the Comeau doesn't recognize dllexport . It seems that they went to extra effort to permit compilation of winnt.h but that doesn't include dllexport. So I don't see any way to build a windows DLL library version with this compiler. I'll tweak the serialiation test/build Jamfile accordingly. Robert Ramey
Robert Ramey wrote:
Jonathan Turkanis wrote:
BTW, Comeau support says that adding a Windows auto-link facility is on their agenda for 2005.
They could probably save a lot of time by just using the boost one.
I think there's a missunderstanding here. Boost auto_link relies on #pragma comment, which is not supported by Comeau. Therefore the current boost auto_link simply can't be made to work with Comeau. (The header compiles, but it has no effect.)
I was a mixing auto-link questions with dll questions. A more careful investigation is that the Comeau doesn't recognize dllexport . It seems that they went to extra effort to permit compilation of winnt.h but that doesn't include dllexport. So I don't see any way to build a windows DLL library version with this compiler.
I'm hoping this is one of the things they're planning to add in 2005. Jonathan
I've investigated what it takes to compile auto-link with commeau. It seems that the following in config/platform/win32.hpp contains: #if !defined(__GNUC__) && !defined(BOOST_HAS_DECLSPEC) \ # define BOOST_HAS_DECLSPEC #endif which results in BOOST_HAS_DECSPEC being defined. However, I get a compile error when BOOST_???_DECL is expanded to _decl(dllimport) or _decl(dllexport) . So my proposed solution is: to replace the above with: // Comeau seems to recognize declspec but doesn't recognize // dllexport and dllimport. So we can't use it #if !defined(__GNUC__) && !defined(BOOST_HAS_DECLSPEC) \ && !defined(__COMO__) # define BOOST_HAS_DECLSPEC #endif This will suppress auto-link stuff for this compiler. I would like to check in this change. Does anyone know of a reason why this is not a good idea? Robert Ramey
What's undefined that should be? Are you sure that Commeau supports those #pragma's anyway?
d) The above makes me wonder if comeau config files have not been kept up. So my question is:
Have comeau config files been kept up with changes required to support auto-link. If so, why is not comeau appearing in the test matrix?
No one is running it, if no one is running it then it's config will not get updated, if you want to run the Commeau regression tests and keep it's config up to date then I'm sure it would be appreciated.
John.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Robert Ramey wrote:
I've investigated what it takes to compile auto-link with commeau.
It seems that the following in config/platform/win32.hpp contains:
#if !defined(__GNUC__) && !defined(BOOST_HAS_DECLSPEC) \ # define BOOST_HAS_DECLSPEC #endif
which results in BOOST_HAS_DECSPEC being defined. However, I get a compile error when BOOST_???_DECL is expanded to _decl(dllimport) or _decl(dllexport) . So my proposed solution is: to replace the above with:
// Comeau seems to recognize declspec but doesn't recognize // dllexport and dllimport. So we can't use it #if !defined(__GNUC__) && !defined(BOOST_HAS_DECLSPEC) \ && !defined(__COMO__) # define BOOST_HAS_DECLSPEC #endif
This will suppress auto-link stuff for this compiler.
I would like to check in this change. Does anyone know of a reason why this is not a good idea?
Maybe. IIUC whether Comeau supports declspec on Windows depends on whether it's being used in its "strict ANSI" mode or its "ANSI plus extensions specific to the platform" mode. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
I've investigated what it takes to compile auto-link with commeau.
It seems that the following in config/platform/win32.hpp contains:
#if !defined(__GNUC__) && !defined(BOOST_HAS_DECLSPEC) \ # define BOOST_HAS_DECLSPEC #endif
which results in BOOST_HAS_DECSPEC being defined. However, I get a compile error when BOOST_???_DECL is expanded to _decl(dllimport) or _decl(dllexport) . So my proposed solution is: to replace the above with:
// Comeau seems to recognize declspec but doesn't recognize // dllexport and dllimport. So we can't use it #if !defined(__GNUC__) && !defined(BOOST_HAS_DECLSPEC) \ && !defined(__COMO__) # define BOOST_HAS_DECLSPEC #endif
This will suppress auto-link stuff for this compiler.
I would like to check in this change. Does anyone know of a reason why this is not a good idea?
Looks good to me, but this is a dll-build issue, not an auto-linking one ;-) In fact the question then becomes if commeau doesn't support __declspec(dllexport) then how does one build dll's with that compiler? Is it possible at all, or does it require special command line options (maybe we really just need to fix the commeau bjam toolset)? Thanks for looking into this, John.
John Maddock wrote:
In fact the question then becomes if commeau doesn't support __declspec(dllexport) then how does one build dll's with that compiler? Is it possible at all, or does it require special command line options (maybe
AFAIR como does not currently support building DLL at all; and it only partly supports consuming them (partly = in "relaxed" mode). I remember exchanging some emails with Greg Comeau about this, and he was going to improve support for dynamic libraries in forthcoming version of como. I do not have these emails handy and I do not remember very well, but maybe you can find them in your archive. B.
I've made source changes to accommodate Comeau.
Now even static libraries fail to compile on with this compiler.
Is this the intention or am I missing something.
You're missing something - including the auto-link code with commeau will *have no effect* - so whatever the problem is, it's unlikely to be auto-linking. John.
participants (6)
-
Aleksey Gurtovoy -
Bronek Kozicki -
David Abrahams -
John Maddock -
Jonathan Turkanis -
Robert Ramey