298032 - need to keep generated import libraries from clobbering static versions of components

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[Mike Shaver (:shaver emeritus)]

When a given build process needs to produce both dynamic and static versions of
the same component (calendar, storage, webdav, and xmlextras for the
sunbird+lightning combined build, for example), then we need to avoid having the
import library generated by msvc collide name-wise with the static component file.

Patch coming up.

Comment 1

[Mike Shaver (:shaver emeritus)]

Attachment: force the use of a dummy import lib, and nuke it afterwards

This also stops copying import libs or dynamic components to dist/lib, which
means that dist/lib only has static component libs in it.  Huzzah.

Comment 2

[Benjamin Smedberg]

Comment on attachment 186617 [details] [diff] [review]
force the use of a dummy import lib, and nuke it afterwards

elegant!

Comment 3

[Mike Shaver (:shaver emeritus)]

FIXED.

Comment 4

[cls]

That was slammed in awful quickly.  Did anyone verify that we don't need to
install those import libs for OS/2 any longer? The OS/2 tinderbox is missing.  I
recall that we removed that step once before only to have it added back.

Comment 5

[Mike Kaply [:mkaply]]

Yep, it would appear our static sunbird is failing now.

abwillis	weakld: error: Unresolved symbol (UNDEF EXPORT) '_NSGetModule'.
	abwillis	weakld: info: The symbol is referenced by:
	abwillis	E:/cvs/work/mozilla/sbobj/storage/build/strgcmps.def
	abwillis	Ignoring unresolved externals reported from weak prelinker.
	abwillis	ILink : error LNK2022: _NSGetModule (alias _NSGetModule) : export
undefined
	abwillis	but running make in build or storage works fine

abwillis	The build problem is because sunbird builds the xpi as well as building
itself... storage is being built static but the xpi is built dynamic...
_NSGetModule is in the dynamic mozStorageModule.o but not the static one

Comment 6

[Mike Shaver (:shaver emeritus)]

Why do we think taht's related to this checkin?  You were failing with that
before I committed this (indeed, before I finished with the patch, IIRC).

Can you file another bug on that, with the OS/2 platform set?

Comment 7

[Mike Kaply [:mkaply]]

My apologies. I got this third hand. I'm in the process of building things
static right now and I'll let you know the outcome.

Comment 8

[Christian :Biesinger (don't email me, ping me on IRC)]

so, I don't see that -IMPLIB thing in my linker flags, and I believe it's
because LDFLAGS is overwritten on line 540 of config.mk:
540 LDFLAGS		= $(OS_LDFLAGS)

http://lxr.mozilla.org/seamonkey/source/config/config.mk#540

Am I missing something?

Comment 9

[Mike Shaver (:shaver emeritus)]

No, I'm missing something; I moved that append lower in config.mk, but didn't
rediff after, and my revert-and-apply-diff defense against checking in
extraneous changes wasn't helpful here.

Update patch tomorrow, if I get a chance before I get sucked into errands.  Thanks.

Comment 10

[Mike Shaver (:shaver emeritus)]

Attachment: Move the -IMPLIB: LDFLAGS addition to after initial assignment.

Biesi: does this fix things for you, too?

Comment 11

[Christian :Biesinger (don't email me, ping me on IRC)]

yep, that patch works for me.

Comment 12

[Mike Shaver (:shaver emeritus)]

FIXED, encore.