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. > 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. 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. -Steve --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
