Gecko SDK does not include NSPR import libs. The Gecko SDK (version 1.7 and what's built on the trunk) does not include the import libs for NSPR. This makes it very difficult to use NSPR from Windows given only the Gecko SDK ;-) For some reason, the full static version of NSPR is included, but I don't think we intend for component authors to link against that.
it's also odd that we install the NSPR static libs into the bin/ directory. if we are going to include those in the Gecko SDK, then they should live in the lib/ directory. i actually think that the DLLs should live there too. though i'm not really sure why the Gecko SDK includes any DLLs under Linux since component builders only need to link to the import libs. the Gecko SDK isn't a usable runtime in and of itself, nor is that its goal (or else it has a very long way to go!).
Severity: normal → major
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.8beta
WOW... combined with bug 266006, this bug makes the Gecko SDK completely useless under Windows for component development. Without the NSPR import libraries, it is not possible to link a component that links with the full glue library :-(
Created attachment 163477 [details] [diff] [review] v1 patch fix nspr exporting into dist/sdk it seems that the patch for bug 236101 caused this problem because it deleted all of the import libraries while maintaining the static NSPR libs. i suspect that was not intentional.
Comment on attachment 163477 [details] [diff] [review] v1 patch i also think it is bogus that we put our libraries in a directory named "bin" .. that may make sense for "dist/bin", but when it comes to the SDK, the "lib" directory is much more appropriate. note: we currently export xpcom import libs into "lib", and i intend to fix xpcom to export its DLLs into "lib" as well. "bin" should only have the XPT and XPIDL tools.
Attachment #163477 - Flags: review?(bsmedberg)
i'd like to see this corrected in the next 1.7 release since this makes our SDK nearly useless on win32 platforms.
On Windows it makes sense to put DLLs under "bin". But the import libraries for DLLs should be put under "lib".
> On Windows it makes sense to put DLLs under "bin". > But the import libraries for DLLs should be put > under "lib". under windows it makes little to no sense to include xpcom.dll in our SDK actually since our SDK does not include a runtime :) but, yeah... you make a good point.
Wan-Teh, So, NSPR's real_install make target does not seem to make a distinction between files ending with .dll and .lib on Windows. It puts them all in $(libdir). Should it be fixed to install DLLs into $(bindir) instead? Otherwise, to implement what you suggest, I need to add commands to mozilla/config/Makefile.in to move the DLLs into sdk/bin after NSPR puts them in sdk/lib. Again, I'd probably rather just not include the DLLs in the SDK.
That change will break people who use the real_install make target. It is a good change though. We can do that on the NSPR trunk for the next NSPR release (4.6). For the Gecko SDK I suggest you add the commands you described and write them in a way so that they won't break when NSPR's real_install target is fixed.
Created attachment 163753 [details] [diff] [review] v1.1 patch slightly revised version of the previous patch. now, after installing the NSPR DLLs into the dist/gre location, we delete the NSPR DLLs from the SDK. they aren't need, and this makes it so. but, i only do this on Windows. it might make sense to do this on other platforms, like OS/2, but we don't currently ship a SDK on OS/2, and well... if someone cares, we can fix the problem.
Attachment #163477 - Attachment is obsolete: true
fixed-on-trunk w/ r=bsmedberg over irc
Status: ASSIGNED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
Created attachment 163761 [details] [diff] [review] v1.2 patch Ok, do the right thing for OS/2 :-)
Attachment #163753 - Attachment is obsolete: true
Comment on attachment 163761 [details] [diff] [review] v1.2 patch a=mkaply for 1.7
Attachment #163761 - Flags: approval1.7.x? → approval1.7.x+
Created attachment 164201 [details] [diff] [review] additional tweak the previous patch actually caused the static libs to be output into the gecko sdk under linux. i'm not sure why, but for some reason the static libs under linux are not named with "_s" :-( so, i went ahead and applied this tweak to Makefile.in to fix the problem.
Darin, Linux: static library: libnspr4.a shared library: libnspr4.so Windows: static library: nspr4_s.lib import library: nspr4.lib DLL: nspr4.dll Hope this helps.
Thanks Wan-Teh... yeah, my recent patch takes that into account. I had expected the static lib to end with "_s" on all platforms. Silly me! ;-)
The DLLs no longer appear in the Windows build, since this patch was applied. See http://ftp.mozilla.org/pub/mozilla.org/mozilla/releases/mozilla1.7.5/gecko-sdk-i586-pc-msvc-1.7.5.zip http://ftp.mozilla.org/pub/mozilla.org/mozilla/releases/mozilla1.7.12/gecko-sdk-i586-pc-msvc-1.7.12.zip http://ftp.mozilla.org/pub/mozilla.org/mozilla/releases/mozilla1.8b1/gecko-sdk-i586-pc-msvc-1.8b1.zip Please reopen this bug. Thanks.
> The DLLs no longer appear in the Windows build, since this patch was applied. ... > Please reopen this bug. Thanks. The DLLs are not supposed to be in the Gecko SDK. That's the whole point of this bug. Only the import libraries (.lib files) are needed. If you need the DLLs, then you should download the corresponding Firefox release.
At the very least, NSPR4.DLL, PLC4.DLL, GLIB-1.2.DLL, and LIBIDL-0.6.DLL should be included, because regxpom.exe depends on the first two, and xpidl.exe depends on the last two. It would be expected that these executables would run out of the box, without having to go hunting around to find their DLL dependencies. This would explain why the DLLs were originally placed in the bin directory, as opposed the lib: they would be automatically found by the executables. Of course, you might be lucky enough to have a compatible Mozilla build installed which happens to have these DLLs located within the PATH environment variable directories. However, if you are unlucky, the DLLs are not compatible and crash during execution, and you have no idea why. Ideally, the PLDS4.DLL and XPCOM.DLL would be included, since these are needed by any application that is built using the Gecko SDK. This would support development of Stand-Alone XPCOM applications, in addition to just supporting embedding into gecko-based products.
1) The SDK is not really meant to support standalone anything; it is an additional download which should be used in conjunction with a binary release. 2) libidl/glib dlls are already available for download: http://developer.mozilla.org/en/docs/Windows_Build_Prerequisites#Netscape_wintools
Status: RESOLVED → VERIFIED
regxpcom probably should not be included in the Gecko SDK. it's a tool that only makes sense in the world of the old mozilla suite.
You need to log in before you can comment on or make changes to this bug.