On 07/01/2012 04:48 AM, Dean Mao wrote:
Yeah, I fixed this by compiling qt with node's ssl library. Of course, this will be more troublesome for people so I guess I may have to include binary libraries inside the npm package or get complaints from everyone who can't "node-gyp rebuild" it on their systems. And when I use this newly compiled qt library with node v0.6, it segfaults somewhere inside ssl, so I guess it requires separate qt libraries depending on node version.
The problem here is that you're effectively loading two different version of the openssl libraries into the same address and they haven't been designed to handle this as opposed to libz. libz sovles this problem by designing itself to be embeddable and thus all the external symbols use a specific prefix and this results in the version inside of node not conflicting .
By default node 0.6 and QT linked against the openssl provided by your system. With 0.8 you then had system ssl + node's builtin openssl which conflicted and leads to a blow up.
From this it makes sense that the other way around, having the qt library be node 0.8 based and then going to launch node 0.6 which has the system ssl would fail.
There are a few ways out of this beyond having separate versions. The first is never use the built in node openssl and always use the system ssl which was the previous default and can be changed based on configure. Since you're distributing an add-on, this may not be tenable as the majority of people will end up using node's default and the built in openssl is almost always a different version from a distributions.
Another option is to look into using a linker feature called Direct Binding. It solves some of the problems of pre-binding symbols, but you'll have to do some research to see if you can make it work for the multiple-openssl case. It comes from the SunOS ld, but I'm fairly certain GNU ld has it, not sure about OS X, the BSDs, and Windows.
Robert
