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

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[Jacek Caban]

Attachment: patch

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.

Comment 1

[Mike Hommey [:glandium]]

Are there actually import libraries with mingw?

Comment 2

[Jacek Caban]

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.

Comment 3

[Mike Hommey [:glandium]]

So, why are we using .dll.a as import lib suffix in gecko and .a in nspr and nss?

Comment 4

[Mike Hommey [:glandium]]

Put differently, why not change gecko to use .a as import lib suffix?

Comment 5

[Jacek Caban]

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.

Comment 6

[Mike Hommey [:glandium]]

Yes, please just change the import suffix in gecko.

Comment 7

[Jacek Caban]

Attachment: change IMPORT_LIB_SUFFIX

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?

Comment 8

[Jacek Caban]

Attachment: change IMPORT_LIB_SUFFIX

I forgot to include js/src/configure.in change in previous patch.

Comment 9

[Mike Hommey [:glandium]]

empty LIB_PREFIX on mingw, then. There's actually no reason DLL_PREFIX is empty and LIB_PREFIX is not.

Comment 10

[Jacek Caban]

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.

Comment 11

[Mike Hommey [:glandium]]

(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.

Comment 12

[Jacek Caban]

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.

Comment 13

[Mike Hommey [:glandium]]

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.

Comment 14

[Jacek Caban]

(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?

Comment 15

[Jacek Caban]

(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.

Comment 16

[Jacek Caban]

Attachment: nspr part

Comment 17

[Jacek Caban]

Attachment: patch

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

Comment 18

[Jacek Caban]

Thanks for the review. I landed non-NSPR part:

https://hg.mozilla.org/integration/mozilla-inbound/rev/cff7e89f35c0

Comment 19

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/cff7e89f35c0

Comment 20

[Jacek Caban]

Thanks for the review.

Comment 21

[Ryan VanderMeulen [:RyanVM]]

Needs rebasing...

Comment 22

[(not currently active) Ted Mielczarek]

The NSPR bit needs to land in the NSPR repo anyway.

Comment 23

[Jacek Caban]

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.

Comment 24

[Ryan VanderMeulen [:RyanVM]]

Ted, can you please assist with the NSPR checkin? :)

Comment 25

[(not currently active) Ted Mielczarek]

http://hg.mozilla.org/projects/nspr/rev/133b835b9ad9

Comment 26

[Andrew McCreight [:mccr8]]

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