sorry.. kind of getting off-topic in the RC-1 thread, starting a new one.
Steve Huston wrote:
Hi David,
Steve Huston wrote:
Hi David,
From: David Rennalls [mailto:drenna...@gmail.com]
..snip..
I have to use Visual Studio 2005.
You are probably going to have problems... I originally started
with
VS2005 ono the original port - it couldn't deal with some
of the Boost
usage and I had to go up to VS2008. I don't recall if the
problem area
was in client, broker, or common.
Hmm.. odd so far I haven't run into any troubles except for
the thread local storage variables (see
below). But then again I'd say my usage of qpid is pretty 'simple'.
It would have been a build-time issue, in the broker IIRC. That was
quite a while ago, and things may have changed.
..snip..
On a side note.. I need a static build for my purposes and it
seems the static project configs went
away with the QPID-1673 'Dynamic Library Build on Windows
(DLL)' changes. However I was able to use
the svn history of the client and common .vcproj files to
generate some working static libs. So
personally I'd be in favour of having those static build
configs added back.
The problem is that there's a common use case that doesn't work
with
the static libs. If there is a DLL that links with the static
client
libs, and that DLL is dynamically loaded from a running exe, the
process will crash. The underlying problem is
thread-specific storage
declared at compile time that needs the linker's help to
get properly
initialized at run time.
If you don't need to do this (if you are simply building an
executable
linked against the static libs) you'll be ok with just the client
side. You won't be ok with the broker side, if you end up
needing it.
If you do need the client-side problem resolved, it will require
allocating TSS at run time instead of at compile time as is
done now.
Funny you mention that :) I spent today debugging an issue
only to realize it was exactly what you
say. My static lib was being linked into a dynamically loaded
DLL. My test harness is as simple .exe
that links the lib so I never saw this. I was just about to
(literally) submit a bug report for this
exact problem when I saw this email, so guess it's a known
issue. I couldn't find anything in the
JIRA database but perhaps I was searching on the wrong keywords.
It never made it into JIRA since it was made moot by building DLLs.
I'm not so sure about that.
Were there any patches available for this ? For my purposes I
was to planning add a static
boost::asio::detail::tss_ptr (which uses the Tls* API calls)
to qpid::sys::AsyncIO (windows) and use
it allocate a struct to hold threadReadTotal,
threadReadCount, threadWriteTotal and threadWriteCount
(threadMaxRead and threadMaxReadTimeNs are unused). Thoughts ?
You don't need to do this if building DLLs. If you need static libs,
you'll have more work to do in the build system since only DLLs get
built now on Windows.
Hmm, I could be missing something but from what I understand you'd still have this issue if the
qpidcommon DLL is dynamically loaded (using LoadLibrary), no ? If an app is doing LoadLibrary on a
DLL it will have no knowledge of the static TLS requirements of that DLL.
I'm basing this on..
http://support.microsoft.com/kb/118816 and
http://msdn.microsoft.com/en-us/library/2s9wt68x(vs.71).aspx (note and the very
bottom of the page)
FWIW I made a small change using tss_ptr as mentioned above and it's working
fine now.
Starting next week I believe, the Windows builds will change to all
Cmake-based, so it will be easier to generate the needed VS projects
for static libs. However, you will need to do a couple days' worth of
testing and changes to make static libs buildable in the general case.
Doing it, say, just for the client libraries, won't take that much
time.
ok.
-Steve
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
