Gecko SDK does not include NSPR import libs

VERIFIED FIXED in mozilla1.8beta1

Status

--
major
VERIFIED FIXED
14 years ago
3 years ago

People

(Reporter: darin.moz, Assigned: darin.moz)

Tracking

({fixed1.7.5})

Trunk
mozilla1.8beta1
x86
Windows XP
fixed1.7.5

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 2 obsolete attachments)

(Assignee)

Description

14 years ago
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.
(Assignee)

Comment 1

14 years ago
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
(Assignee)

Comment 2

14 years ago
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 :-(
(Assignee)

Comment 3

14 years ago
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.
(Assignee)

Comment 4

14 years ago
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)
(Assignee)

Comment 5

14 years ago
i'd like to see this corrected in the next 1.7 release since this makes our SDK
nearly useless on win32 platforms.
Flags: blocking1.7.x?

Comment 6

14 years ago
On Windows it makes sense to put DLLs under "bin".
But the import libraries for DLLs should be put
under "lib".
(Assignee)

Comment 7

14 years ago
> 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.
(Assignee)

Comment 8

14 years ago
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.

Updated

14 years ago
Attachment #163477 - Flags: review?(bsmedberg) → review+

Comment 9

14 years ago
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.
(Assignee)

Comment 10

14 years ago
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
(Assignee)

Comment 11

14 years ago
fixed-on-trunk w/ r=bsmedberg over irc
Status: ASSIGNED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
(Assignee)

Updated

14 years ago
Attachment #163753 - Flags: approval1.7.x?
(Assignee)

Comment 12

14 years ago
Created attachment 163761 [details] [diff] [review]
v1.2 patch

Ok, do the right thing for OS/2 :-)
Attachment #163753 - Attachment is obsolete: true
(Assignee)

Updated

14 years ago
Attachment #163753 - Flags: approval1.7.x?
(Assignee)

Updated

14 years ago
Attachment #163761 - Flags: approval1.7.x?
Comment on attachment 163761 [details] [diff] [review]
v1.2 patch

a=mkaply for 1.7
Attachment #163761 - Flags: approval1.7.x? → approval1.7.x+
(Assignee)

Comment 14

14 years ago
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.
(Assignee)

Comment 15

14 years ago
fixed1.7.x
Keywords: fixed1.7.x

Comment 16

14 years ago
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.
(Assignee)

Comment 17

14 years ago
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! ;-)

Updated

14 years ago
Flags: blocking1.7.5?
(Assignee)

Comment 19

13 years ago
> 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

13 years ago
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

13 years ago
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
(Assignee)

Comment 22

13 years ago
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.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.