265998 - Gecko SDK does not include NSPR import libs

Status: VERIFIED FIXED

(Core Graveyard :: Embedding: Packaging, defect)

Description

[Darin Fisher]

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.

Comment 1

[Darin Fisher]

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!).

Comment 2

[Darin Fisher]

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 :-(

Comment 3

[Darin Fisher]

Attachment: 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 4

[Darin Fisher]

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.

Comment 5

[Darin Fisher]

i'd like to see this corrected in the next 1.7 release since this makes our SDK
nearly useless on win32 platforms.

Comment 6

[Wan-Teh Chang]

On Windows it makes sense to put DLLs under "bin".
But the import libraries for DLLs should be put
under "lib".

Comment 7

[Darin Fisher]

> 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.

Comment 8

[Darin Fisher]

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.

Comment 9

[Wan-Teh Chang]

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.

Comment 10

[Darin Fisher]

Attachment: 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.

Comment 11

[Darin Fisher]

fixed-on-trunk w/ r=bsmedberg over irc

Comment 12

[Darin Fisher]

Attachment: v1.2 patch

Ok, do the right thing for OS/2 :-)

Comment 13

[Mike Kaply [:mkaply]]

Comment on attachment 163761 [details] [diff] [review]
v1.2 patch

a=mkaply for 1.7

Comment 14

[Darin Fisher]

Attachment: 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.

Comment 15

[Darin Fisher]

fixed1.7.x

Comment 16

[Wan-Teh Chang]

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.

Comment 17

[Darin Fisher]

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! ;-)

Comment 18

[Phil]

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.

Comment 19

[Darin Fisher]

> 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.

Comment 20

[Phil]

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.

Comment 21

[Benjamin Smedberg]

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

Comment 22

[Darin Fisher]

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.