505736 - Wrong IMPORT_LIB_SUFFIX on MinGW.

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[Jacek Caban]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.1) Gecko/20090715 Firefox/3.5.1
Build Identifier: 

IMPORT_LIB_SUFFIX should be 'a' on MinGW. Its import library names have form of lib<name>.a.

Reproducible: Always

Comment 1

[Jacek Caban]

Attachment: Fix

Comment 2

[cls]

IIRC, using lib<name>.a for import libs conflicts with the static libs which have the same naming convention.  See bug 134113 comment 301 & 302.  

Also, see the "direct linking to a dll" section at http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/gnu-linker/win32.html .

Comment 3

[Jacek Caban]

I've looked deeper at this. Here are some facts that I found. First of all IMPORT_LIB_SUFFIX is used only by security module and compilation works fine for me with my patch. I cross compile on Linux using MinGW, but it looks like cross compiling doesn't change anything regardless this bug. Without this patch I get error:

/home/jacek/mozilla-build/mozilla-build/config/nsinstall -R -m 755 ../../dist/lib/libcrmf.a ../../dist/lib/libsmime3.dll.a ../../dist/lib/libssl3.dll.a ../../dist/lib/libnss3.dll.a ../../dist/lib/libnssutil3.dll.a ../../dist/lib/libsoftokn3.dll.a  ../../dist/sdk/lib
/home/jacek/mozilla-build/mozilla-build/config/nsinstall: cannot access ../../dist/lib/libsmime3.dll.a: No such file or directory

It's because most security makefiles don't take configure's IMPORT_LIB_SUFFIX into account and instead set it in WIN32.mk to .$(LIB_SUFFIX). Fixing it is not enough as I get other errors then.

The fact that compilation works with my patch and other parts of code don't take IMPORT_LIB_SUFFIX into account suggests me that one of two solutions seem to be the best:

- Keep configure's and security makefiles' IMPORT_LIB_SUFFIX in sync - that's what my patch does.

- Get rid of IMPORT_LIB_SUFFIX and always use LIB_SUFFIX.

Other option would be fixing security makefiles to properly use IMPORT_LIB_SUFFIX. That would mean that whole other code should be considered as buggy and should fixed as well, so we'd have to teach all other modules about it. It seems to be much more complication for no good point IMO.

I'd appreciate a comment about what's the prefered way to go.

Comment 4

[(not currently active) Ted Mielczarek]

Comment on attachment 389936 [details] [diff] [review]
Fix

Dropping review request per cls' comment. If you attach an updated patch, please r?cls directly.

Comment 5

[Jacek Caban]

Attachment: Always use LIB_SUFFIX instead of IMPORT_LIB_SUFFIX.

This patch removes IMPORT_LIB_SUFFIX. AFAICS it's different from LIB_SUFFIX only when compiling on MinGW and it only causes troubles in this case. Note that if static lib conflicts with import lib, it's already handled by using lib<name>_s.a schema in current build system, so IMPORT_LIB_SUFFIX is useless complication.

Comment 6

[cls]

Comment on attachment 392742 [details] [diff] [review]
Always use LIB_SUFFIX instead of IMPORT_LIB_SUFFIX.

We should not revert the use of IMPORT_LIB_SUFFIX just because of the known discrepancy between Mozilla's & NSS' naming conventions. 

It's been awhile since I've looked at this but I seem to recall that NSS didn't properly support mingw in their standalone builds and that we were expected to pass in the proper make variables to get it to work as part of Mozilla.  In this case, the problem is easily solved by passing in IMPORT_LIB_SUFFIX to DEFAULT_GMAKE_FLAGS in security/manager/Makefile.in .

Comment 7

[cls]

Attachment: Pass IMPORT_LIB_SUFFIX to NSS

Comment 8

[Jacek Caban]

Your patch works great, thanks. If we're not going to change IMPORT_LIB_SUFFIX, then there is another improper use of IMPORT_LIB_SUFFIX in browser/components/build/Makefile.in. I will attach a patch.

Comment 9

[Jacek Caban]

Attachment: Use IMPORT_LIB_SUFFIX for linking thebes library.

Comment 10

[cls]

Comment on attachment 392987 [details] [diff] [review]
Use IMPORT_LIB_SUFFIX for linking thebes library.

I'm not sure what tree you're using but I don't see thebes mentioned in browser/components/build/Makefile.in in either tree.  

The change looks correct though but it looks like the EXPAND_MOZLIBNAME macro/description is wrong in config/rules.mk.

Comment 11

[Jacek Caban]

It's in mozilla-central, see
http://hg.mozilla.org/mozilla-central/file/d9b5c7f26d63/browser/components/build/Makefile.in
line 98.

Comment 12

[cls]

Both patches have been checked into mozilla-central and the security/manager patch has been checked into CVS HEAD.

http://hg.mozilla.org/mozilla-central/rev/8ef666467a3b

Checking in security/manager/Makefile.in;
/cvsroot/mozilla/security/manager/Makefile.in,v  <--  Makefile.in
new revision: 1.84; previous revision: 1.83
done

http://hg.mozilla.org/mozilla-central/rev/546e369e6221