Closed Bug 418687 Opened 12 years ago Closed 12 years ago

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

Categories

(NSPR :: NSPR, defect)

x86
Windows XP
defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: ted, Assigned: ted)

References

Details

Attachments

(1 file, 2 obsolete files)

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.
This makes DLLFLAGS work similarly to CFLAGS etc.
Assignee: wtc → ted.mielczarek
Status: NEW → ASSIGNED
Attachment #304617 - Flags: review?(wtc)
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*)
That would be fine with me.  I just want some way to get extra linker options into NSPR.
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?
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 on attachment 304617 [details] [diff] [review]
allow passing DLLFLAGS from environment

r=wtc.
Attachment #304617 - Flags: review?(wtc) → review+
Comment on attachment 304617 [details] [diff] [review]
allow passing DLLFLAGS from environment

a=beltzner
Attachment #304617 - Flags: approval1.9+
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
Attachment #304617 - Attachment is obsolete: true
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.
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → 4.7.1
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
Attachment #304865 - Attachment is obsolete: true
I accidentally checked in with this bug number for bug 481687

If anyone folows the pushlog link, it's for that bug. :)
You need to log in before you can comment on or make changes to this bug.