Closed Bug 1910760 Opened 2 years ago Closed 2 years ago

Unable to build static library during building

Categories

(Firefox Build System :: General, defect)

Firefox 128
defect

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: joseph.krejchi, Unassigned)

Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.0.0 Safari/537.36

Steps to reproduce:

I downloaded the latest version of the Firefox source code (128) and am working on a project where I need to statically compile the entire source code-- meaning no dynamic linking anywhere. According to the documentation, building a static library is as simple as appending "Library('LibName')" to the end of a moz.build file for a given library and then building the normal way (using mach build)

Actual results:

No static libraries ('.a' files) were generated, and the final executable and libraries are dynamically linked

Expected results:

A static library with the specified name should have been generated, presumably in the same directory as its associated moz.build file.

The severity field is not set for this bug.
:Sylvestre, could you have a look please?

For more information, please visit BugBot documentation.

Flags: needinfo?(sledru)
Component: Firefox Source Docs: Content → General
Flags: needinfo?(sledru)
Product: Developer Infrastructure → Firefox Build System

The severity field is not set for this bug.
:ahochheiden, could you have a look please?

For more information, please visit BugBot documentation.

Flags: needinfo?(ahochheiden)
Flags: needinfo?(ahochheiden) → needinfo?(mh+mozilla)

The build system has been avoiding to create static libraries since bug 584474. There's a way out with https://searchfox.org/mozilla-central/rev/1e8cec3727d6e09f4af41bb3d202b7a4c326ed84/python/mozbuild/mozbuild/frontend/context.py#2573-2578, the name of which is not intuitive for historical reasons, but I can't advise you do that, because many things are actually expected shared libraries. Some of the libraries under security/nss are expected to be loadable objects, which forces nspr to be loadable objects as well. Codecs are expected to be loadable objects as well, and for licensing reasons, the lgpllibs library is expected to be a shared library too. I think there are more cases like these.

Status: UNCONFIRMED → RESOLVED
Closed: 2 years ago
Flags: needinfo?(mh+mozilla)
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.