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

Status: VERIFIED FIXED

(NSS :: Build, defect, P2)

Description

[Walter Meinl]

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

Comment 1

[Walter Meinl]

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

Comment 2

[Peter Weilbacher]

Yes, this is indeed a problem. Walter's solution works here.

Comment 3

[Peter Weilbacher]

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.

Comment 4

[Julien Pierre]

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

Comment 5

[Peter Weilbacher]

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.

Comment 6

[Julien Pierre]

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

[Robert Relyea]

... and sometimes it's the OS.

bob

Comment 8

[Shawn Wilsher :sdwilsh]

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

Comment 9

[Julien Pierre]

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 .

Comment 10

[Walter Meinl]

(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

[Peter Weilbacher]

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

[Peter Weilbacher]

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

Comment 13

[Julien Pierre]

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

Comment 14

[Julien Pierre]

Checking in sign.cmd;
/cvsroot/mozilla/security/nss/cmd/shlibsign/sign.cmd,v  <--  sign.cmd
new revision: 1.6; previous revision: 1.5
done

Comment 15

[Julien Pierre]

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.

Comment 16

[Peter Weilbacher]

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

[Robert Relyea]

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

[Peter Weilbacher]

OK, so this made it into NSS_3_12_ALPHA_2 and so has been picked up by Mozilla trunk in the meantime.