boost interprocess linking error

I also got the https://svn.boost.org/trac/boost/ticket/2992 bug. That's the one with the linking error caused by the functions get_file_name_from_handle_function and unlink_file. The functions are defined as static inline, they are however too big to be successfully inlined. One work around I found so far is to pass the /force:multiple switch to the linker. Far from being ideal as that may hide other linking issues. -- EA

Edouard A. wrote:
I also got the https://svn.boost.org/trac/boost/ticket/2992 bug. That's the one with the linking error caused by the functions get_file_name_from_handle_function and unlink_file.
The functions are defined as static inline, they are however too big to be successfully inlined.
One work around I found so far is to pass the /force:multiple switch to the linker. Far from being ideal as that may hide other linking issues.
Which compiler are you using? This seems a compiler bug, because even if it's too big, this shouldn't give any linking error. Ion

AMDG Ion Gaztañaga wrote:
Edouard A. wrote:
I also got the https://svn.boost.org/trac/boost/ticket/2992 bug. That's the one with the linking error caused by the functions get_file_name_from_handle_function and unlink_file. The functions are defined as static inline, they are however too big to be successfully inlined. One work around I found so far is to pass the /force:multiple switch to the linker. Far from being ideal as that may hide other linking issues.
Which compiler are you using? This seems a compiler bug, because even if it's too big, this shouldn't give any linking error.
According to the ticket, its msvc 8. In Christ, Steven Watanabe

AMDG Ion Gaztañaga wrote:
Edouard A. wrote:
I also got the https://svn.boost.org/trac/boost/ticket/2992 bug. That's the one with the linking error caused by the functions get_file_name_from_handle_function and unlink_file. The functions are defined as static inline, they are however too big to be successfully inlined. One work around I found so far is to pass the /force:multiple switch to the linker. Far from being ideal as that may hide other linking issues.
Which compiler are you using? This seems a compiler bug, because even if it's too big, this shouldn't give any linking error.
The problem has nothing to do with the size of the functions. The problem is the local classes. MSVC, does not like local classes in functions defined in headers. Also, why are you declaring these static? The inline should be enough, and adding static causes technical ODR violations, and may prevent the duplicate definitions from being stripped out by the linker (I haven't tested this however). In Christ, Steven Watanabe

The problem has nothing to do with the size of the functions. The problem is the local classes. MSVC, does not like local classes in functions defined in headers. Also, why are you declaring these static? The inline should be enough, and adding static causes technical ODR violations, and may prevent the duplicate definitions from being stripped out by the linker (I haven't tested this however).
I removed the static modifier, unfortunately it doesn't solve the problem. Other functions do not have the problem, only unlink and get_handle. But I agree with Steven, I don't understand the reason behind static inline and the problem is probably the local class. Maybe moving the class out of the function should fix things? I unfortunately cannot test with another compiler, this is a problem found by one present in one of my customer's source code, source code for which I have no external access. This was Visual Studio 2005 SP1, AKA VC8. I also don't understand why there is this: class auto_ptr { public: explicit auto_ptr(mem_t *ptr) : ptr_(ptr){} ~auto_ptr(){ delete ptr_; } mem_t *get() const{ return (ptr_); } mem_t *operator->() const{ return this->get(); } private: mem_t *ptr_; } pmem(new mem_t); Why not std::auto_ptr or boost::scoped_ptr? As for class handle_closer { void *handle_; public: handle_closer(void *handle) : handle_(handle){} ~handle_closer(){ close_handle(handle_); } } handle_closer(fh); and class library_unloader { void *lib_; public: library_unloader(void *module) : lib_(module){} ~library_unloader(){ free_library(lib_); } } unloader(hiPSAPI); You can write boost::shared_ptr<void> auto_handle(handle, close_handle) and boost::shared_ptr<void> auto_lib(module, free_library); Adding a dependency to boost::shared_ptr sounds reasonable to me, but you're the boss. ;) Regards. -- EA __________ Information from ESET NOD32 Antivirus, version of virus signature database 4098 (20090522) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com
participants (3)
-
Edouard A.
-
Ion Gaztañaga
-
Steven Watanabe