Closed
Bug 298406
Opened 20 years ago
Closed 20 years ago
Link phase should reference Xcode objects, no hardcoded -l arguments
Categories
(Camino Graveyard :: General, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: mark, Assigned: mark)
Details
Attachments
(1 file)
31.30 KB,
patch
|
mikepinkerton
:
review+
sfraser_bugs
:
superreview+
asa
:
approval1.8b3+
|
Details | Diff | Splinter Review |
In the Camino project file, there are a few libraries that are linked by
appearing in OTHER_LDFLAGS in the target settings. Normally, in well-behaved
Xcode projects, the libraries are dragged into the link phase and Xcode turns
them into -l arguments for ld. An example is libnspr4.dylib, which is in
OTHER_LDFLAGS as -lnspr4. This is probably just leftover junk from the Project
Builder days. I note that only dynamic libraries get this treatment in the
project file, static archives are handled more normally.
Keeping these guys in OTHER_LDFLAGS will cause problems with certain
configurations, because OTHER_LDFLAGS comes too late in the ld invocation, after
the system frameworks included by the link phase. (This is actually what caused
the most trouble when Panther was released, until Mozilla/Camino beefed up with
SDK support.)
The objects for these libraries already exist in the project file and are used
in copy phases. They should also be used in link phases.
Assignee | ||
Comment 1•20 years ago
|
||
This is another step toward using gcc 4 to produce usable Camino builds. SDK
>= 10.3.9 is required for gcc 4. Camino won't run when built against SDK
10.3.9 but run on 10.4 because the system libraries are being linked before
Mozilla's own libraries, and Apple saw fit to expose NSPR in 10.3.9's system
libraries and then remove it in 10.4.
This is really a transitional step. The 10.3.9 SDK is really useless for
official Camino PPC builds for the time being. Intel builds will need to use
the 10.4u SDK, and that still needs more work.
Tested with static and dynamic targets on both 10.4.1/2.1/SDK 10.3.9/gcc 4 and
10.3.9/1.1/SDK 10.2.7/gcc 3.3. Since the xcode project format is so
ridiculous, a list of changes follows.
Changes Camino targets to let Xcode handle linking the following libraries
instead of specifying -l arguments manually. In all targets: libxpcom.dylib
libxpcom_core.dylib libplds4.dylib libplc4.dylib libnspr4.dylib; in
CaminoStatic only: libsmime3.dylib libssl3.dylib libsoftokn3.dylib
libxpcom_compat.dylib libmozjs.dylib libmozjpeg.a libjsj.a libmozpng.a; in
Camino (non-static) only: libmozz.dylib. These libraries are linked as late as
possible, but before any system framework.
Some targets (Privacy, Security, and WebFeatures pref panes) already had most
of these libraries (except libxpcom_core.dylib) included in their link phase IN
ADDITION to having the -l arguments in OTHER_LDFLAGS. I added libxpcom_core to
the proper spot in these targets without reordering anything else.
File reference objects were added for the three static ar archives. They were
already present for the dylibs, and are being used in the copy phase.
While I was at it, I fixed the paths for the file references for libcomposer.a,
libhtmlpars.a, and libtransformiix.a. Their locations in the build tree had
moved, and were showing up as red when they should have been black.
Also, -framework Cocoa in libgfx_mac needed to move out of LDFLAGS and into
EXTRA_DSO_LDOPTS, because LDFLAGS comes before EXTRA_DSO_LDOPTS during the
link, but the system framework needs to be moved after the mozilla libs for the
same reason as above. This affects Camino only (for now).
Attachment #187054 -
Flags: superreview?(sfraser_bugs)
Attachment #187054 -
Flags: review?(pinkerton)
Updated•20 years ago
|
Attachment #187054 -
Flags: superreview?(sfraser_bugs) → superreview+
Comment 2•20 years ago
|
||
Comment on attachment 187054 [details] [diff] [review]
Link order fixes
r=pink
Attachment #187054 -
Flags: review?(pinkerton) → review+
Assignee | ||
Updated•20 years ago
|
Attachment #187054 -
Flags: approval1.8b3?
Updated•20 years ago
|
Attachment #187054 -
Flags: approval1.8b3? → approval1.8b3+
landed on trunk
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•