Closed
Bug 113152
Opened 24 years ago
Closed 1 year ago
Cleanup -DLINUX mess in makefiles
Categories
(Directory Graveyard :: LDAP C SDK, defect, P3)
Tracking
(Not tracked)
RESOLVED
INCOMPLETE
People
(Reporter: david, Assigned: mcs)
Details
Attachments
(1 file)
This patch cleans up much of the mess regarding the Linux kernel versioning and
#define dependancies. As was evidenced by the new 2.2 kernel, 2.3, 2.4, and now
the 2.5 version of kernel, we had to duplicate the previous Linux.2.n.mk files
when a new kernel minor was introduced. The forthcoming patch removes this
hassle by making -DLINUX a boolean use. (patch follows)
a) No more kernel versioning. There isn't any code that relies on a kernel
version and Mozilla shouldn't worry about the kernel version in the first place
b) Changes all #define pragmas to only use -DLINUX instead of the previous
myriad of uses. Frankly there is only one use sofar that makes a distinct use
of the define and that is the CTIME macro. That should be handled with the
./configure toolset and removed from the makefile includes and et cetera.
c) Although not part of this patch, the files in mozilla/security/coreconf/
named Linux*2.*mk can now be deleted, they are extraneous. Only Linux.mk is used.
Side note, there are actually two uses of the #define, one for the CTIME macro
and one for some string comparison functions. Both should be handled by ./configure
Comment 4•24 years ago
|
||
Confirming bug.
Comment 5•24 years ago
|
||
I'll see if I can get this reviewed and checked in in NSS 3.4.
Status: NEW → ASSIGNED
Priority: -- → P2
Target Milestone: --- → 3.4
Comment 6•24 years ago
|
||
Question: which macros are guaranteed to be defined by
all compilers on Linux: linux, __linux, or __linux__?
$ gcc -v -E -
Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.0.2/specs
Configured with: ../configure --prefix=/usr
--with-gxx-include-dir=/usr/include/g++ --enable-cpp --enable-languages=c,c++
Thread model: single
gcc version 3.0.2
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.0.2/cpp0 -lang-c -v -D__GNUC__=3
-D__GNUC_MINOR__=0 -D__GNUC_PATCHLEVEL__=2 -D__ELF__ -Dunix -Dlinux -D__ELF__
-D__unix__ -D__linux__ -D__unix -D__linux -Asystem=posix -D__NO_INLINE__
-D__STDC_HOSTED__=1 -Acpu=i386 -Amachine=i386 -Di386 -D__i386 -D__i386__
-D__tune_i686__ -D__tune_pentiumpro__ -
GNU CPP version 3.0.2 (cpplib) (i386 Linux/ELF)
ignoring nonexistent directory "/usr/i686-pc-linux-gnu/include"
ignoring duplicate directory "/usr/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/include
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.0.2/include
End of search list.
# gcc -v -E -
Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/specs
gcc version 2.95.3 20010315 (release)
/usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/cpp0 -lang-c -v -D__GNUC__=2
-D__GNUC_MINOR__=95 -D__ELF__ -Dunix -D__i386__ -Dlinux -D__ELF__ -D__unix__
-D__i386__ -D__linux__ -D__unix -D__linux -Asystem(posix) -Acpu(i386)
-Amachine(i386) -Di386 -D__i386 -D__i386__ -Di686 -Dpentiumpro -D__i686
-D__i686__ -D__pentiumpro -D__pentiumpro__ -
GNU CPP version 2.95.3 20010315 (release) (i386 Linux/ELF)
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../i686-pc-linux-gnu/include
/usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/include
/usr/include
End of search list.
The following default directories have been omitted from the search path:
/usr/include/g++
End of omitted list.
If we're gonna use the compiler's idea of defines, then everything should be
converted to (IMO) -D__linux__, code and makefiles. Right now, the code is
pretty simple, but the makefiles are a mishmash of defines.
-D__xxxx__ is consistent with common usage.
Comment 8•24 years ago
|
||
Comment on attachment 60083 [details] [diff] [review]
This patch cleans up much of the mess regarding the Linux kernel versioning and #define dependancies.
I checked in the NSPR part of this patch.
Updated•23 years ago
|
Priority: P2 → P1
Target Milestone: 3.5 → 3.7
Comment 10•23 years ago
|
||
Moved to target milestone 3.8 because the original
NSS 3.7 release has been renamed 3.8.
Target Milestone: 3.7 → 3.8
Updated•23 years ago
|
Priority: P1 → P2
Target Milestone: 3.8 → 3.9
Updated•22 years ago
|
Priority: P2 → P3
Version: 4.0 → 3.7
Updated•21 years ago
|
Target Milestone: 3.9 → 3.10
Updated•20 years ago
|
Target Milestone: 3.10 → 3.12
Updated•20 years ago
|
QA Contact: wtchang → build
Comment 11•19 years ago
|
||
http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&file=Makefile&branch=&root=/cvsroot&subdir=/mozilla/security/nss/lib/freebl/mpi&command=DIFF_FRAMESET&rev1=1.19&rev2=1.20
removed the nss traces
Assignee: wtchang → mcs
Status: ASSIGNED → NEW
Component: Build → LDAP C SDK
Product: NSS → Directory
QA Contact: build
Target Milestone: 3.12 → ---
Version: 3.7 → other
Comment 12•19 years ago
|
||
Timeless,
The makefile security/nss/lib/freebl/mpi/Makefile was & is irrelevant to this
bug, because that Makefile is not used in NSS builds. It is used when building
mpi as a stand-alone math library. When mpi is built as part of NSS, the
Makefile in its parent directory, nss/lib/freebl, does all the building for the
code in nss/lib/freebl/mpi.
The checkin to mpi's Makefile which you cited probably broke those standalone
builds, but it definitely had no impact on this bug.
What is the motivation for this bug? In what sense is this a "bug"?
Does NSS or NSPR or mozilla or even libLDAP not build on one of the
supported Linux platforms?
It takes a lot of work to vet a patch like this on all the relevant
platforms (versions of Linux), and unless there's a compelling reason to
so, it's not going to receive high (read: any) priority.
Note: someone's sense of aesthetics is not a compelling reason.
Updated•1 year ago
|
Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•