Closed
Bug 384832
Opened 17 years ago
Closed 6 months ago
winxp msvc8 build fails to build security if source directory is read-only.
Categories
(NSS :: Build, defect, P5)
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: vladimir.sukhoy, Unassigned)
Details
Attachments
(1 file)
1.44 KB,
patch
|
nelson
:
review-
|
Details | Diff | Splinter Review |
PDB:NONE option is used for linker which requires write access on the current directory (the linker wants to create a file named "NONE" in srcdir which was readonly in my case). Somehow this seems to be wrong.
Comment 1•17 years ago
|
||
Comment on attachment 268730 [details] [diff] [review] comment PDB:NONE out so that the build is successful Vladimir, wasn't it obvious that the solution is to define MOZ_DEBUG_SYMBOLS ?? That's what that symbol is for.
Attachment #268730 -
Flags: review-
Reporter | ||
Comment 2•17 years ago
|
||
Yes, but as I understand, from http://developer.mozilla.org/en/docs/Building_Firefox_with_Debug_Symbols MOZ_DEBUG_SYMBOLS is for debug symbols in breakpad format. It seems that, PDB:NONE was used to (long ago) specify that debug symbols should be embedded into the executable. I do not want breakpad symbols, nor do I think that it is appropriate to require the generation of breakpad debug symbols in order to build the source with a readonly source directory (which is implied by using objdir) to workaround regression from PDB:NONE being disabled in modern versions of msvc.
Reporter | ||
Comment 3•17 years ago
|
||
The patch just illustrated the issue... If PDB:NONE is to be removed or substituted by a modern equivalent, then it should, probably, be consistently fixed throughout all the build rules with appropriate checks performed for a newer versions of msvc..
Reporter | ||
Comment 4•17 years ago
|
||
Correction: MOZ_DEBUG_SYMBOLS actually specifies that debug symbols should be placed in separate PDB files. PDB:NONE used to specify that debug symbols should be put within executable, and is no longer supported since MSVS 2002. Instead, the symbols are put in the file "NONE" in the current (respectively to linker/compiler) directory which is obviously not what was intended by using PDB:NONE in the makefile. So, it seems that, usage of PDB:NONE should either be eliminated as such or become conditional on the cases when the compiler which supports it (msvc5, msvc6?) is used.
Reporter | ||
Comment 5•17 years ago
|
||
I think I gained enough confidence that this is a bug to set the status to "NEW".
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 6•17 years ago
|
||
In reply to comment 2, MSVC produces PDB files in one format. It doesn't produce a different format for breakpad. If you want MSVC PDB files, you know what to do. In reply to comment 4: When used in NSS, MOZ_DEBUG_SYMBOLS specifies that debug symbols should be placed in separate PDB files. In the rest of FireFox, when used with non-DEBUG builds, MOZ_DEBUG_SYMBOLS specifies tht PDB files are to be generated anyway (they are typically not generated for non-DEBUG builds). Note that unlike the rest of FireFox, NSS is still backwards compatible with old MSVC compilers, all the way to MSVC 5. Yes, MSVC5 and MSVC6 use PDB:NONE to mean "put debug information into the .exe or .dll files".
Reporter | ||
Comment 7•17 years ago
|
||
Agreed. Since the configuration when MOZ_DEBUG_SYMBOLS is not set for a debug build is possible, it follows that this configuration should exhibit correct behavior. PDB:NONE option is triggered whenever above is the case and it breaks the build if using readonly source directory (which is pretty common, it seems). So, it seems that the right way to fix this is to specify PDB:NONE on MSVC5 and MSVC6 and avoid using it for anything newer than MSVC5 and MSVC6. This way the compatibility will be maintained while the potential build error on newer compilers will be eliminated.
Updated•2 years ago
|
Severity: minor → S4
Updated•6 months ago
|
Status: NEW → RESOLVED
Closed: 6 months ago
Priority: -- → P5
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•