275112 - build fails when old version of nsldap is installed in %systemroot%\system32 - shlibsign.exe - Entry Point Not Found PK11_ProtectedAuthenticationPath

Status: RESOLVED WONTFIX

(NSS :: Build, defect, P3)

Description

[timeless]

standard search order (from dependency walker 2.1 documentation):
The seven predefined locations include the following:

Side-by-Side Components (Windows XP only)

Starting with Windows XP, applications can override the operating system’s
default search order by providing instructions about the versions and/or
locations of modules it requires.  These instructions can be stored in a special
XML file or as an RT_MANIFEST resource in the main executable itself.

The system's known DLLs list.

These are known modules like KERNEL32.DLL.  When the operating system encounters
a known DLL, it skips all rules and loads it from a known place.

The application directory.

This is the directory that the main module of your application lives in.

The 32-bit system directory.

This is your 32-bit system directory.  On Windows NT/2000, it is usually
something like C:\WinNT\System32\.  On Windows XP, it is usually something like
C:\Windows\System32\.  On Windows 95/98/Me, it is usually something like
C:\Windows\System\.

The 16-bit system directory (Windows NT/2000/XP only).

This is your 16-bit Windows directory and only exists on Windows NT/2000/XP.  It
is usually located at C:\WinNT\System\.

The system's root OS directory.

This is the directory that your operating system is installed to.  It is usually
something like C:\WinNT\ on Windows NT/2000 and C:\Windows\ on Windows 95/98/Me/XP.

The application's registered "App Paths" directories.

This is a set of directories that an application can register for itself in the
"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\"
section of the registry.  If an application has registered one or more
directories, then those directories will be searched for dependent files.  This
feature is actually provided by the Shell and not by the core operating system.
 When an application is started by calling a Shell function (like ShellExecute
or ShellExecuteEx), the Shell checks the registry to see if the application has
registered a path in the "App Paths" section.  If so, that path is inserted into
the head of the PATH variable for the application about to be started.  Most
newer applications use the Shell functions to start other applications, but for
applications that call CreateProcess, the applications started will not receive
their "App Paths" path as part of their search order.

The system's "PATH" environment variable directories.

The last item in a module's search order is usually the PATH variable.  This is
a user-definable system variable that is seen by all applications running on a
given computer.  It usually contains one or more directories where common
modules can be found.

---
since a third party product has dumped its nss3.dll (ver 3.3.2.0), nspr4.dll
(ver 4.1.2.0) and related stuff into system32 and the build system is supposed
to run on things other than wXP, the only options available are having the dll
in the application directory or in known dlls. known dlls has essentially the
same problem as application directory (except it's worse!). so the only option
is to copy the required dlls into the application directory.

Comment 1

[timeless]

Attachment: the unhappy libraries

Comment 2

[timeless]

Attachment: copy required libraries locally

Comment 3

[Wan-Teh Chang]

Comment on attachment 168996 [details] [diff] [review]
copy required libraries locally

Timeless, thanks for the bug report and patch.
Your idea is right on, but this patch still needs
work.  For one, it needs to support MKS Toolkit,
which doesn't have cygpath.

I'm wondering if NSPR and NSS should simply publish
their *.dll to dist/bin instead of dist/lib.  This
would solve the problem.

Comment 4

[timeless]

this would *not* solve the problem. unless shlibsign runs from dist/bin, which
it does not. it runs from nss/

i do sympathize with mks, but i haven't setup nss w/ it yet (not quite on my
priority list).

for my reference, the error is:
shlibsign.exe - Entry Point Not Found
The procedure entry point PK11_ProtectedAuthenticationPath could not be located
in the dynamic link library nss3.dll

Comment 5

[David G King]

As near as I can tell, this problem has returned for me due to an install of
Netscape v8 beta (or an install of NVU v0.9). Both use nss.dll v3.9.3.0 rather
than nss.dll v3.9.6.0

Comment 6

[Wan-Teh Chang]

Attachment: Fix #1: search for DLLs in the executable's directory

I worked on this bug two weeks ago but forgot to
attach my patches.

There are two strategies to fix this bug.  This
patch is the first strategy: put the .exe and the
.dll's in the same directory.

Comment 7

[Wan-Teh Chang]

Attachment: Fix #2: search for DLLs in the current working directory

The second strategy is to change the current working
directory of the executable to the directory where
the .dll's are.  This requires argument 2 and argument
4 to the sign.sh script be absolute pathnames.	NSS's
coreconf makefiles have a convenient 'abspath' function
that converts a pathname to an absolute pathname, so we
do the conversions in the makefile rather than in the
shell script.

Comment 8

[Wan-Teh Chang]

Attachment: Alternate fix #2: search for DLLs in the current working directory

This is the second strategy with the conversions
to absolute pathnames done in the shell script.

Comment 9

[Wan-Teh Chang]

I like fix #1 the best.  Its only problem is that
it copies a file to another directory temporarily
and removes the copy when done.

I've tested all three fixes under both MKS and
Cygwin.

Let me know which fix you like the best, and I'll
seek code review on that fix.

Comment 10

[timeless]

unfortunately i don't favor #1, i worry about locked files and
concurrency/parallelism issues

Comment 11

[Julien Pierre]

I think alternate fix #2 (attachment 177709 [details] [diff] [review]) is the preferable one, if we want to fix this bug.

However, I think that the applications that installed NSS/NSPR DLLs in windows\system32 are clearly broken. They create problems not just for the NSS build system, but for potentially all other NSS applications running on Windows. Some applications (eg. windows services) require access to the libraries in a shared location. We should come up with a generic solution that causes only the latest NSPR/NSS version to be installed to a shared location, perhaps one other than system32, which could be in the user's path, but would not automatically override the PATH set in the NSS build system scripts.

Failing that, there are many more things in NSS than shlibsign execution during the build that will fail due to the wrong libraries being loaded. For example, the NSS QA scripts would also fail, since they use varied execution paths, and changing all of them would be a huge task. I'm sure NSPR and JSS QA suffer from the same problem. So, I wonder if we want to support building and running tests at all on a machine that has existing NSS/NSPR libraries in windows\system32. A more appropriate fix IMO would be to try to detect that condition by running an NSS program without setting the PATH, and if it runs, fail the build with an informative message to the user telling him he can't build/test NSS if some NSS libraries are already in system32.

Comment 12

[Julien Pierre]

Note that I'm working on bug 315793, which will change shlibsign runpath to $OBJDIR, by virtue of a Makefile change. Doing that will not resolve this windows XP issue, but I thought I would still mention it since it is closely related.

Comment 13

[timeless]

Comment on attachment 177709 [details] [diff] [review]
Alternate fix #2: search for DLLs in the current working directory

yes they're clearly broken, and you're welcome to call crystal and tell them that crystal reports is broken. i'm no longer working for cenzic but they weren't going to listen to me anyway. (crystal includes netscape ldap which includes nss, so here you are)

i'd suggest that you bump the filename and include a *bigger* warning telling consumers to *never* stick it in system32 upon penalty of lawsuit for something or other. while you're at it, tell them not to dump the ldap files into system32, thanks :)

Comment 14

[Julien Pierre]

Comment on attachment 177709 [details] [diff] [review]
Alternate fix #2: search for DLLs in the current working directory

You need to patch the current version of sign.sh, which is 1.17 (tip). Also update the Makefile to rev 1.16.

The main reason this gets r- is that NSS may not be built with the cygwin toolkit. At Sun we do our NSS builds with the MKS toolkit. Thus, cygpath is not available nor needed. If you are going to use cygpat,h your patch must make sure this is done conditionally only when using cygwin.

Comment 15

[Wan-Teh Chang]

Comment on attachment 177709 [details] [diff] [review]
Alternate fix #2: search for DLLs in the current working directory

sign.sh works with both MKS Korn Shell and Cygwin's bash.
The if statement under the "WIN*" case is supposed to
tell MKS from Cygwin.  However, since we also support
MSYS now, this patch may need to be updated to handle
MSYS, which may not have cygpath.

Comment 16

[Christophe Ravel]

The target milestone is already released. Resetting target milestone.

Comment 17

[Marcus Burghardt]

Hi,

This is a very old bug and a long time without update.
As many things changed in 12 years, could some stakeholder confirm if this problem is still relevant in the current versions, please?
If not, we can close this bug. If yes, lets update what is missing here.

Thanks,

Comment 18

[Marcus Burghardt]

No answer received. Changing to WONTFIX.
Please, feel free to reopen necessary.

Comment 19

[timeless]

I'm not sure about the current status.
looks like :glandium is the last person to touch one of the files:
https://hg.mozilla.org/projects/nss/file/e955ece90b050e9da67528f09648945156d2bcea/cmd/shlibsign/Makefile