418687 - no way to pass linker flags to NSPR's DLL linking

Status: RESOLVED FIXED

(NSPR :: NSPR, defect)

Description

[(not currently active) Ted Mielczarek]

I'm trying to fix bug 415928.  When we build our own CRT from the Microsoft sources, we currently still need to tell the linker not to add a manifest requiring the Microsoft CRT.  We can do this by passing -MANIFEST:NO to the linker.  Unfortunately, I don't see any way to pass this to the NSPR DLL link line.  Both DLLFLAGS and OS_DLLFLAGS are assigned unconditionally in configure, and that link line doesn't use LDFLAGS at all.

I think it would be simple to make DLLFLAGS work like CFLAGS/LDFLAGS, and accept an initial value from the environment.

Comment 1

[(not currently active) Ted Mielczarek]

Attachment: allow passing DLLFLAGS from environment

This makes DLLFLAGS work similarly to CFLAGS etc.

Comment 2

[Wan-Teh Chang]

Comment on attachment 304617 [details] [diff] [review]
allow passing DLLFLAGS from environment

Ted, if DLLFLAGS is not a commonly used makefile
variable, does it make sense to use LDFLAGS as the
external interface for both Unix and Windows?  That is:

@@ -89,10 +89,11 @@
 dnl =
 dnl ========================================================
 CFLAGS="${CFLAGS=}"
 CXXFLAGS="${CXXFLAGS=}"
 LDFLAGS="${LDFLAGS=}"
+DLLFLAGS="${LDFLAGS=}"
 HOST_CFLAGS="${HOST_CFLAGS=}"
 HOST_LDFLAGS="${HOST_LDFLAGS=}"
 
 case "$target" in
 *-cygwin*|*-mingw*)

Comment 3

[(not currently active) Ted Mielczarek]

That would be fine with me.  I just want some way to get extra linker options into NSPR.

Comment 4

[Wan-Teh Chang]

Ted, it seems that LDFLAGS is the name of this variable in your (Mozilla's) makefiles, right?
If so, I'll use LDFLAGS.

How urgent is this patch?

Comment 5

[(not currently active) Ted Mielczarek]

I would like to get this in for beta 4, so I can fix bug 415928.  The code freeze for that is Tuesday night (Februrary 26th).  Right now we're shipping both our custom-built CRT and the Microsoft CRT DLLs.  With this patch and one more patch in that bug, we'll be able to ship just our custom CRT.

Thanks!

Comment 6

[Wan-Teh Chang]

Comment on attachment 304617 [details] [diff] [review]
allow passing DLLFLAGS from environment

r=wtc.

Comment 7

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 304617 [details] [diff] [review]
allow passing DLLFLAGS from environment

a=beltzner

Comment 8

[Wan-Teh Chang]

Attachment: allow passing DLLFLAGS from environment (as checked in)

I edited Ted's patch and checked it in on the NSPR
trunk for NSPR 4.7.1.

Checking in configure;
/cvsroot/mozilla/nsprpub/configure,v  <--  configure
new revision: 1.225; previous revision: 1.224
done
Checking in configure.in;
/cvsroot/mozilla/nsprpub/configure.in,v  <--  configure.in
new revision: 1.228; previous revision: 1.227
done

Comment 9

[Wan-Teh Chang]

Ted, you need to pass LDFLAGS (rather than DLLFLAGS) in
the environment to NSPR's configure script.  Hopefully
this is closer to the standard usage.

Kai Engert will update the NSPR tag in mozilla/client.mk
later today.

Comment 10

[Wan-Teh Chang]

Attachment: allow passing DLLFLAGS from environment (as checked in, again)

Sigh, we use LDFLAGS when building a utility program now.c,
so I still need to use DLLFLAGS.

Checking in configure;
/cvsroot/mozilla/nsprpub/configure,v  <--  configure
new revision: 1.226; previous revision: 1.225
done
Checking in configure.in;
/cvsroot/mozilla/nsprpub/configure.in,v  <--  configure.in
new revision: 1.229; previous revision: 1.228
done

Comment 11

[Mike Connor [:mconnor]]

I accidentally checked in with this bug number for bug 481687

If anyone folows the pushlog link, it's for that bug. :)