Hi Robert, On Tuesday, 6. July 2010 00:07:48 you wrote:

Jürgen Hunold wrote:

...

BOOST_HAS_DECLSPEC is the interesting one. Please find a patch adding two more "#define BOOST_SERIALIZATION_SOURCE" to the sources. This fixed compilation for me when using gcc's symbol visibility and might help here as mingw uses symbol visibility "under the hood" for __declspec(dllimport/-export).

I'm aware of this "fix". I'm very reluctant to just do it because I don't understand why it works or should work.

It works because gcc and msvc have different symbol visibility rules. It seems to me that msvc works by "accident" or compiler "feature" right now. I've not taken the time to dig into the MS knowledge base to verify this, though.

So it's almost certain that if I just do this, It will come back to torture me some time just after the next version is released.

Well, I discovered this behaviour when trying to fix the now famous #2114 https://svn.boost.org/trac/boost/ticket/2114 As soons as symbol visibility support is added to the serialization library, gcc will fail on _all_ platforms without those extra "#defines" I'm quite short on time, but please find the whole patch adding symbols visibility support (and fixing #2114 for Boost.Serialization) attached. This already work for Boost.Test and Beman patched some more libs... Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold@ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

Hi Robert, On Tuesday, 6. July 2010 10:12:38 you wrote:

All this looks like a refinement of the auto-liink stuff which we've had for MSVC and Borland for years.

As John has already mentioned, this is a pure symbol visibility issue.

So it's OK. I would like to see this stuff checked into the release branch before I make these changes in the serialization library.

Just checked again, all patches are already merged to release. I merged Boost.Test myself ;-)) I still have to find some time to address the other libraries...

With the last change I made in the serialization library, the only missing symbols are void_upcast and void_downcast. the *.cpp files which defiine these functions to indeed define BOOST_SERIALIZATION_SOURCE so these symbols should be exported. I'm trying go figure out why this is not happening. Including define BOOST_SERIALIZATION_SOURCE in a different file can't be the solution - the fact that it seems to work can only be a hint as to what the problem is. Still thanks for the insight.

If you got gcc-4.x around, the easiest solution would be to apply the visibility patch and then compile with "<cxxflags>>-fvisibility=hidden". You should then get the same linker errors as mingw. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold@ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

be a hint as to what the problem is. Still thanks for the insight.

...

If you got gcc-4.x around, the easiest solution would be to apply the visibility patch and then compile with "<cxxflags>>-fvisibility=hidden". You should then get the same linker errors as mingw.

That would seem to be the missing magic. I use cygwin with gcc 4.3.4 to test here so I can try that. So I guess that the explanation of this instance might be that all the gcc compilers in the test matrix don't use -fvisibility=hidden while the MingW one does? and this couples with my usage of BOOST_HAS_DECL in some unexpected way?.

anyway, I have something to work with for now.

Actually I don't think any will be using that flag right now. My guess as to what's happening here is that one source file is seeing symbol X with a __declspec(dllexport) attribute because BOOST_SERIALIZATION_SOURCE is defined for that source, where as another source file is seeing the same symbol without the __declspec() attribute because BOOST_SERIALIZATION_SOURCE is not defined for it. The result is that the two source files end up looking for different mangled names for that symbol and hence the error. The most consistent way to deal with this is to set BOOST_SERIALIZATION_SOURCE for all source the files. HTH, John.

With the last change I made in the serialization library, the only missing symbols are void_upcast and void_downcast. the *.cpp files which defiine these functions to indeed define BOOST_SERIALIZATION_SOURCE so these symbols should be exported. I'm trying go figure out why this is not happening. Including define BOOST_SERIALIZATION_SOURCE in a different file can't be the solution - the fact that it seems to work can only be a hint as to what the problem is. Still thanks for the insight.

Which compiler/platform is this? I just tried Trunk with Mingw-gcc-4.5.0 and everything that should pass did. John.

It looks to me that there are only a couple of undefined symbols because the serialization autolink code is being enabled by BOOST_HAS_DECL which is now being used to enable "visibility". This is likely even more confused as I believe I've used this or something like it to trick the compiler/linker into suppressing code stripping of code not otherwise explicitly referred to.

GCC's visibility feature is actually very similar to msvc's import/export feature - just a different name. Using it to prevent code being stripped will continue as before for msvc, and probably have no effect (as before) for gcc. Cheers, John.

On 7/6/2010 2:58 PM, Robert Ramey wrote:

John Maddock wrote:

...

...

autolink code is being enabled by BOOST_HAS_DECL which is now now being used to enable "visibility". This is likely even more confused as I believe I've used this or something like it to trick the compiler/linker into suppressing code stripping of code not otherwise explicitly referred to.

GCC's visibility feature is actually very similar to msvc's import/export feature - just a different name. Using it to prevent code being stripped will continue as before for msvc, and probably have no effect (as before) for gcc.

GCC's visibility varies from MSVC's dllexport/import in subtle ways, but is largely the same in effect, but only with -fvisibility=hidden.

Hmmm - now I'm wondering about code stripping in gcc. Why is this not a problem for this compiler? Does it never strip code? Does it depend on compile time switches that we don't user or ???.

Without that switch, GCC exposes all symbols. That would be the same as if declspec(dllexport) were applied to every symbol when using MSVC.

To my mind, the problem is that the library depends on behavior outside the scope of the C++ standard so we sort of end up addressing these issues by trial and error. It seems the whole subject of runtime linking is basically undefined.

It is undefined WRT the C++ Standard, but it is well defined for MSVC and GCC. The issue is one of understanding the behavior of those two platforms, not trial and error. To further clarify GCC's visibility, note that once -fvisibility=hidden is used, GCC will expose no symbols by default. That's equivalent to MSVC's default behavior, which is why declspec(dllexport)/import is needed with MSVC. However, just changing the dllexport/import macros to make things visible for GCC isn't sufficient. There are some symbols that MSVC automagically exports that GCC does not. That means there are some symbols that must be marked visible for GCC that needn't been exported for MSVC, such as exception classes and types that are used in dynamic_casts. Whether those are an issue for Boost.Serialization, I couldn't say. HTH, Rob

On 7/6/2010 7:11 PM, Robert Ramey wrote:

Let me expand a little bit on the issue of code-stripping which cost me a huge amount of hassle to find a way around.

a) build and test seriialization library in debug mode. b) everything works great c) build and test in release mode - uh oh - tests using exported pointers fail. But only with MSVC. d) After some investigation, it's determined that code not explicitly referred to is being stripped. e) After lot's of experimentation, it's found we can mark the functions as dll_export to be sure they are not dropped. These are not functions in the library, but rather templates instantiated inside the user's code. MSVC uses this to implement Automation where one application can use COM to call into one application from another. f) This workaround was "codified" in boost/serialization/force_include.hpp" g) This problem never arose with gcc. I'm not sure whether this is because gcc doesn't do any code stripping or what.

By default, GCC exposes all symbols, so it wouldn't have stripped anything.

Now I'm wondering if one builds with gcc in release mode with visibility=hidden, if we'll get a whole rash of test failures.

It is certainly possible as there may well be things that must be marked visible that don't need to be exported for MSVC. That is, you've identified everything that must be exported to make MSVC happy, but there may yet be other things to mark visible when using GCC's -fvisibility=hidden. Note that GCC's visibility applies to class templates, too, because static data members of class templates must be marked visible to avoid multiple definitions in shared objects and referenced separately (violating the ODR, of course).

I'm not sure I really have a point here. It just seems that this is going to take more time than one would expect to play itself out.

Perhaps, but it shouldn't be too significant. There may be some help in comparing the exports from the DLL with the strong symbols visible in the DSO. Finally, I should have mentioned, in case you weren't aware of it, that BOOST_SYMBOL_VISIBLE is available for marking things visible that needn't (or shouldn't) be marked with __declspec(dllexport). ___ Rob

Hi, Can someone help me on, where can I get the source .cpp files for the following libraries? 1. Boost.Interprocess 2. Boost.signals(2) I installed the boost package in linux. I can see the source files for thread library, but not for the above and some more. Do I have to do additional steps to get source files for all libraries? Thanks in advance. Regards, Alap This Email may contain confidential or privileged information for the intended recipient (s) If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system. ______________________________________________________________________

Hi, Thanks for the response. I was interested in the actual implementation of these libraries. In this case, is there a way? Regards, Alap -----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Andrey Semashev Sent: Wednesday, July 07, 2010 5:10 PM To: boost@lists.boost.org Subject: Re: [boost] Query on Boost IPC On 07/07/2010 01:33 PM, Alapkumar Sinha wrote:

Hi,

Can someone help me on, where can I get the source .cpp files for the following libraries?

1. Boost.Interprocess

2. Boost.signals(2)

I installed the boost package in linux. I can see the source files for thread library, but not for the above and some more.

Do I have to do additional steps to get source files for all libraries?

These libraries are header-only. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ______________________________________________________________________ This Email may contain confidential or privileged information for the intended recipient (s) If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system. ______________________________________________________________________

On 7/7/2010 1:19 AM, Robert Ramey wrote:

All this really caught me by surprise. Is there any documentation on this?

On BOOST_SYMBOL_VISIBLE or on GCC's visibility? For the former, I don't think so. For the latter, here's the closest thing I know of that offers useful details: <http://gcc.gnu.org/wiki/Visibility>.

Is there a comprehensive set of tests to verify how this works in different compilers? Seems to me there are a number of interrelated facets.

I doubt it.

a) visibility b) code stripping

Those two are, really, the same thing, if I understand your terminology correctly. The point of visibility is to determine what must be exposed to clients of a DSO/DLL by GCC. What isn't visible isn't exported, may be optimized away, recognized as unused so discarded, etc.

c) handling of the same instantiated code in different modules

That's necessarily platform dependent as the Standard doesn't recognize dynamic libraries.

d) interaction with auto-linking (through shared macro names)

I don't know how that maps into this space, unfortunately.

e) at least 3 different compilers which have at least slight differences (MSVC, gcc, Borland, and ?)

Since this isn't Standard specified behavior, platform differences are de rigueur.

f) at least as far as I know - no guidence from the C++ standard.

As noted.

g) our testing regimen doesn't really test all combinations - debug/release dll/lib, auto-lib/no-autolib, in a comprehensive and systematic way. So we can't know when we've really got it right.

No doubt true.

I've had to spend a lot of time on all of the above. It was in an ad hoc / piecemeal fashion which was not at all satisfactory. So sorting all this out is a very worthwhile task. But I can't help thinking that the scope of this issue and size of the task has been underestimated.

The only thing I suppose to be difficult is the corner cases such as GCC requiring things to be marked visible that MSVC doesn't require be exported. Discovering those, most likely, will require trial and error, though one can apply the known rules (dynamic_cast, user-defined exception types, class template static data members) to find an initial set. ___ Rob

AMDG Alapkumar Sinha wrote:

I have a situation where I have some part of the code is in C++ and some part in native C.

For C++ part, I can use the Boost directly. But for c part, is there a way to use the boost library as well.

One way I think of is to provide a c wrapper?

Can anyone suggest a better way?

I don't see how else you could use a C++ library from C. In Christ, Steven Watanabe P.S. Please start a new thread instead of replying to an unrelated thread.