NSS and NSPR libs can't be found in mingw builds.

RESOLVED FIXED

Status

defect
RESOLVED FIXED
5 years ago
2 years ago

People

(Reporter: jacek, Assigned: jacek)

Tracking

Trunk
x86_64
Windows 7

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 3 obsolete attachments)

Posted patch patch (obsolete) — Splinter Review
Here is an example of the error:

0:07.91 i686-w64-mingw32-g++: error: ../../security/nss/lib/nss/libnss3.dll.a: No such file or directory
 0:07.91 i686-w64-mingw32-g++: error: ../../security/nss/lib/smime/libsmime3.dll.a: No such file or directory
 0:07.91 i686-w64-mingw32-g++: error: ../../security/nss/lib/ssl/libssl3.dll.a: No such file or directory
 0:07.91 i686-w64-mingw32-g++: error: ../../security/nss/lib/util/libnssutil3.dll.a: No such file or directory
 0:07.91 i686-w64-mingw32-g++: error: ../../nsprpub/lib/ds/libplds4.dll.a: No such file or directory
 0:07.91 i686-w64-mingw32-g++: error: ../../nsprpub/lib/libc/src/libplc4.dll.a: No such file or directory
 0:07.91 i686-w64-mingw32-g++: error: ../../nsprpub/pr/src/libnspr4.dll.a: No such file or directory

Note that files passed to linker have .dll.a suffix, but those file really have just .a suffixes. The attached patch is a bit hackish, but works. I'm open for suggestions how to solve it better.
Attachment #8481343 - Flags: review?(mh+mozilla)
Are there actually import libraries with mingw?
Yes, for example libnss3.a is an import lib. ld accepts both .a and .dll.a files. The problem is that we pass full file name, which uses wrong suffix.
So, why are we using .dll.a as import lib suffix in gecko and .a in nspr and nss?
Put differently, why not change gecko to use .a as import lib suffix?
Because my patch to change that was rejected 5 years ago:
https://bugzilla.mozilla.org/show_bug.cgi?id=505736#c5

I'm happy to revisit it. It already caused more problems since then.
Yes, please just change the import suffix in gecko.
Attachment #8481343 - Flags: review?(mh+mozilla)
Posted patch change IMPORT_LIB_SUFFIX (obsolete) — Splinter Review
The attached one-line patch just works for NSS. With it, we could consider removing IMPORT_LIB_SUFFIX and use LIB_SUFFIX instead.

NSPR linking is a bit more tricky, which I didn't notice earlier:

$ ls nsprpub/pr/src/
Makefile  _pr_bld.h  io  linking  malloc  md  memory  misc  nspr.res  nspr4.a  nspr4.dll  nspr4_s.a  prvrsion.o  threads

The library does not have lib prefix. -lnspr4 works only because ld uses .dll file then. What would be prefered fix? Change nspr?
Attachment #8482681 - Flags: review?(mh+mozilla)
Posted patch change IMPORT_LIB_SUFFIX (obsolete) — Splinter Review
I forgot to include js/src/configure.in change in previous patch.
Attachment #8482681 - Attachment is obsolete: true
Attachment #8482681 - Flags: review?(mh+mozilla)
Attachment #8482683 - Flags: review?(mh+mozilla)
empty LIB_PREFIX on mingw, then. There's actually no reason DLL_PREFIX is empty and LIB_PREFIX is not.
This would break -lXXX linking. AFAIK, -l options looks for files libXXX.a, libXXX.dll.a and XXX.dll, so we'd lose the ability to link our libraries without specifying full file name.
(In reply to Jacek Caban from comment #10)
> This would break -lXXX linking. AFAIK, -l options looks for files libXXX.a,
> libXXX.dll.a and XXX.dll, so we'd lose the ability to link our libraries
> without specifying full file name.

... which is not a problem since the build system does that.
I tried that, the first problem I ran into was:

Exception: File not found: ../../../js/src/ctypes/libffi/.libs/ffi.a

I sense that there may be more similar problems, I'd really much rather do things more 'standard' way.
Depends what you call 'standard'. We're not using -lfoo when linking libraries internally anymore, on any platform. So from that point of view, it's 'standard'.

That being said, ffi is special, because it creates a library *with* lib in its name. And guess what, we have the same problem with msvc, and it's taken care of in config/external/ffi/moz.build. You just need to make that a windows test instead of a msvc test.
(In reply to Mike Hommey [:glandium] (out from Sep 6 to Sep 22) from comment #13)
> Depends what you call 'standard'. We're not using -lfoo when linking
> libraries internally anymore, on any platform. So from that point of view,
> it's 'standard'.

I mean the way tools are designed to work and common way of using them. Do you consider removing it for other GCC-based targets as well? If not, then we have a choice between assumptions "GCC targets have lib prefix" and "non-Windows targets have lib prefix". Currently the first assumption is true and I don't see how the second one is better. It's a problematic change (see bellow) that doesn't really make things easier IMHO. Also, NSPR and NSS still use -lXXX linking for their code.

> That being said, ffi is special, because it creates a library *with* lib in
> its name. And guess what, we have the same problem with msvc, and it's taken
> care of in config/external/ffi/moz.build. You just need to make that a
> windows test instead of a msvc test.

I tried that. Then I ran into a problem with linking mozglue (easy to fix), then mozsqlite3 linked by NSS using -lXXX method. I didn't investigate that yet, but this we already know that there will be another problem with linking to NSS, which uses libXXX.a import liraries.

That said, would you please reconsider taking NSPR part of my first hackish patch and change to IMPORT_LIB_SUFFIX?
(In reply to Jacek Caban from comment #14)
> That said, would you please reconsider taking NSPR part of my first hackish
> patch and change to IMPORT_LIB_SUFFIX?

I have a better solution that I think is the right way to fix it. I will attach it as soon as I'm done with testing.
Attachment #8482683 - Flags: review?(mh+mozilla)
Posted patch nspr partSplinter Review
Attachment #8481343 - Attachment is obsolete: true
Attachment #8482683 - Attachment is obsolete: true
Attachment #8484916 - Flags: feedback?(mh+mozilla)
Posted patch patchSplinter Review
This version depends on nspr part and it:

- Changes IMPORT_LIB_SUFFIX to .a, so it's consistent with nspr and nss
- Changes MOZ_GLUE_LDFLAGS to use full file name on mingw. It's not really needed for this patch, but it seems nice for consistency.
- Passes NSPR31_LIB_PREFIX to NSS build system, so it finds nspr with lib prefix
Attachment #8484917 - Flags: review?(mh+mozilla)
Attachment #8484917 - Flags: review?(mh+mozilla) → review+
Attachment #8484916 - Flags: feedback?(mh+mozilla) → feedback+
Thanks for the review. I landed non-NSPR part:

https://hg.mozilla.org/integration/mozilla-inbound/rev/cff7e89f35c0
Whiteboard: [leave open]
Attachment #8484916 - Flags: review?(ted)
Attachment #8484916 - Flags: review?(ted) → review+
Thanks for the review.
Keywords: checkin-needed
Needs rebasing...
Keywords: checkin-needed
Whiteboard: [leave open]
The NSPR bit needs to land in the NSPR repo anyway.
Yes, and I just verified that it applies fine there. What's the procedure in this case? I used checkin-needed because (at least before mogration to hg), only nspr peers could do the commit.
Keywords: checkin-needed
Whiteboard: [checkin to NSPR]
Ted, can you please assist with the NSPR checkin? :)
Flags: needinfo?(ted)
It looks like this is landed on m-c and in the NSPR repo, so I'm going to go ahead and close it so it doesn't show up on my [checkin query. ;)
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Whiteboard: [checkin to NSPR]
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.