The default bug view has changed. See this FAQ.

OS/2 sign.cmd doesn't find sqlite3.dll

VERIFIED FIXED in 3.12

Status

NSS
Build
P2
normal
VERIFIED FIXED
10 years ago
10 years ago

People

(Reporter: Walter Meinl, Assigned: Julien Pierre)

Tracking

unspecified
3.12
Other
OS/2

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

10 years ago
User-Agent:       Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.9a7pre) Gecko/2007072922 Minefield/3.0a7pre
Build Identifier: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.9a7pre) Gecko/2007072922 Minefield/3.0a7pre

Now that sqlite3 is separated as a dll, security/nss/cmd/shlibsign/sign.cmd doesn't find sqlite3.dll.

Reproducible: Always

Steps to Reproduce:
1. build Minefield/3.0a7pre
2. overcome every other build breake (bugs will be filed)
3. sign.cmd fails
Actual Results:  
[E:\mozbuild\nss]echo E:\MOZBUILD\DIST 
E:\MOZBUILD\DIST

[E:\mozbuild\nss]echo E:\MOZBUILD\NSS 
E:\MOZBUILD\NSS

[E:\mozbuild\nss]echo E:\MOZBUILD\DIST\LIB 
E:\MOZBUILD\DIST\LIB

[E:\mozbuild\nss]set BEGINLIBPATH=E:\MOZBUILD\DIST\lib;E:\MOZBUILD\DIST\LIB;E:\usr\lib;E:\GLIBIDL\gcc335\lib;E:\PERL\lib;E:\MOZTOOLS;D:\EMX\dll;E:\PYTHON244; 

[E:\mozbuild\nss]set LIBPATHSTRICT=T 

[E:\mozbuild\nss]E:\MOZBUILD\NSS\shlibsign -v -i E:/mozbuild/dist/lib/softokn3.DLL 
SYS1804: The system cannot find the file SQLITE3.

[E:\mozbuild\nss]echo E:\MOZBUILD\DIST 
E:\MOZBUILD\DIST

[E:\mozbuild\nss]echo E:\MOZBUILD\NSS 
E:\MOZBUILD\NSS

[E:\mozbuild\nss]echo E:\MOZBUILD\DIST\LIB 
E:\MOZBUILD\DIST\LIB

[E:\mozbuild\nss]set BEGINLIBPATH=E:\MOZBUILD\DIST\lib;E:\MOZBUILD\DIST\LIB;E:\usr\lib;E:\GLIBIDL\gcc335\lib;E:\PERL\lib;E:\MOZTOOLS;D:\EMX\dll;E:\PYTHON244; 

[E:\mozbuild\nss]set LIBPATHSTRICT=T 

[E:\mozbuild\nss]E:\MOZBUILD\NSS\shlibsign -v -i E:/mozbuild/dist/lib/freebl3.DLL 
SYS1804: The system cannot find the file SQLITE3.
nsinstall: ..\..\dist\lib\softokn3.chk: No such file or directory
make.exe[4]: *** [libs] Error 3


Expected Results:  
should find sqlite3.dll
(Reporter)

Comment 1

10 years ago
Created attachment 274397 [details] [diff] [review]
include dist\bin where sqlite3.dll resides now

As you can see, the sign.cmd is not logic, as it adds $objdir\dist\lib twice. When we include also dist\bin where now sqlite3.dll is exported (Peters patch for bug 306907 has to be applied of course), sqlite3 is found and everything builds as expected

Updated

10 years ago
Assignee: nobody → nobody
Component: Security → Build
Product: Firefox → NSS
QA Contact: firefox → build

Comment 2

10 years ago
Yes, this is indeed a problem. Walter's solution works here.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 3

10 years ago
Comment on attachment 274397 [details] [diff] [review]
include dist\bin where sqlite3.dll resides now

I hope Julien can review this and perhaps also check in.
Attachment #274397 - Flags: superreview?(julien.pierre.boogz)
Attachment #274397 - Flags: review?(julien.pierre.boogz)
(Assignee)

Comment 4

10 years ago
Why is sqlite in dist/bin and not dist/lib ? That seems like a mistake.

Comment 5

10 years ago
I think that is normal for Mozilla (Core) DLLs. Their import library is copied to dist/lib, the DLL itself isn't. Looking at that directory I only see NSPR, NSS, and LDAP DLLs. The XPCOM DLLs are also only in dist/bin not dist/lib. So I think this is correct.
(Assignee)

Comment 6

10 years ago
OK. The confusion is about who builds and ships sqlite3. When NSS is build standalone (gmake nss_build_all in mozilla/security/nss), the sqlite shared library should be in lib . And I bet that sign.cmd works in that case on OS/2 .
It's unfortunate that it is somewhat ambiguous who has the responsibility to build sqlite3 , sometimes the browser, sometimes NSS . 

Comment 7

10 years ago
... and sometimes it's the OS.

bob
I'm not a build guy - you'd be better off cc'ing luser or bsmedberg
(Assignee)

Comment 9

10 years ago
Comment on attachment 274397 [details] [diff] [review]
include dist\bin where sqlite3.dll resides now

dist\lib still needs to be in the LIBPATH, it shouldn't be removed . It's OK to add dist\bin .
Attachment #274397 - Flags: superreview?(julien.pierre.boogz)
Attachment #274397 - Flags: review?(julien.pierre.boogz)
Attachment #274397 - Flags: review-
(Reporter)

Comment 10

10 years ago
(In reply to comment #9)
> (From update of attachment 274397 [details] [diff] [review])
> dist\lib still needs to be in the LIBPATH, it shouldn't be removed . It's OK to
> add dist\bin .
> 
But in effect the patch does not remove dist\lib, as the variable nspr_lib_dir gets resolved to dist\lib, and at the moment we add dist\lib and nspr_lib_dir to the libpath, which results in Beginlibpath=\dist\lib;dist\lib as you can see in the error message (comment #0). When we hardcode dist\lib, should we then remove nspr_lib_dir?

Comment 11

10 years ago
I think what Julien tries to point us at is that nspr_lib_dir and dist\lib could be different directories depending on how you build NSS. I don't think many people build NSS outside the Mozilla environment for OS/2 but we should keep that possibility. In any case, having a duplicate directory on BEGINLIBPATH doesn't hurt, so just adding dist\bin should be fine...

Comment 12

10 years ago
Created attachment 274793 [details] [diff] [review]
add dist\bin as last dir

Like this. I think having dist\bin as the last added dir is the best as existing dirs in dist\lib take precedence.
Attachment #274397 - Attachment is obsolete: true
Attachment #274793 - Flags: superreview?(julien.pierre.boogz)
Attachment #274793 - Flags: review?(julien.pierre.boogz)
(Assignee)

Comment 13

10 years ago
Comment on attachment 274793 [details] [diff] [review]
add dist\bin as last dir

This looks fine.
Note that the NSS trunk rules are that only one review from one of the regular developers is required. For the 3.11 branch, 2 reviews are required. But they cannot be from the same person ;).
Attachment #274793 - Flags: superreview?(julien.pierre.boogz)
Attachment #274793 - Flags: review?(julien.pierre.boogz)
Attachment #274793 - Flags: review+
(Assignee)

Updated

10 years ago
Status: NEW → ASSIGNED
Priority: -- → P2
Target Milestone: --- → 3.12
(Assignee)

Comment 14

10 years ago
Checking in sign.cmd;
/cvsroot/mozilla/security/nss/cmd/shlibsign/sign.cmd,v  <--  sign.cmd
new revision: 1.6; previous revision: 1.5
done
Assignee: nobody → julien.pierre.boogz
Status: ASSIGNED → NEW
(Assignee)

Comment 15

10 years ago
I checked the patch in to the NSS trunk. This should be in the next alpha or beta tag of NSS 3.12 for the next Firefox 3 drop.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED

Comment 16

10 years ago
Thanks, Julien. Any idea why this didn't make it into the NSS_3_12_ALPHA1B tag that is now used by trunk since Aug 6th? Do we have to set some Bugzilla flag?

Comment 17

10 years ago
ALPHA1B was a single fix for an existing mozilla problem. The next cut of the whole trunk would probably be called ALPHA2 or BETA1.

bob

Comment 18

10 years ago
OK, so this made it into NSS_3_12_ALPHA_2 and so has been picked up by Mozilla trunk in the meantime.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.