Allow static library definitions to depend on shared libraries

RESOLVED FIXED in mozilla34

Status

defect
RESOLVED FIXED
5 years ago
Last year

People

(Reporter: glandium, Assigned: glandium)

Tracking

(Blocks 2 bugs)

unspecified
mozilla34
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

From https://bugzilla.mozilla.org/show_bug.cgi?id=1036894#c55:

There are, however, one or two things I want to add that would alleviate this:
- allow intermediate static libs to have shared library dependencies, which would be linked to the final lib (and throw errors if the static lib is linked nowhere where those shared library deps are going to be used)
- define types of programs/shared libraries. Something to say "this is something for gecko", "this is independent", "this is a program with xpcom standalone linkage", etc. which would also replace e.g. resetting MOZ_GLUE_LDFLAGS and/or setting DISABLE_STL_WRAPPING
but I haven't formalized anything yet.


This is for the first of these two points.
Blocks: 1041941
Blocks: 1041943
(In reply to Mike Hommey [:glandium] from comment #0)
> - define types of programs/shared libraries. Something to say "this is
> something for gecko", "this is independent", "this is a program with xpcom
> standalone linkage", etc. which would also replace e.g. resetting
> MOZ_GLUE_LDFLAGS and/or setting DISABLE_STL_WRAPPING
> but I haven't formalized anything yet.

This would be fantastic, as 99% of the usage in the tree is cargo-culted. Defining things in straightforward terms would be a huge improvement.
(In reply to Ted Mielczarek [:ted.mielczarek] from comment #4)
> (In reply to Mike Hommey [:glandium] from comment #0)
> > - define types of programs/shared libraries. Something to say "this is
> > something for gecko", "this is independent", "this is a program with xpcom
> > standalone linkage", etc. which would also replace e.g. resetting
> > MOZ_GLUE_LDFLAGS and/or setting DISABLE_STL_WRAPPING
> > but I haven't formalized anything yet.
> 
> This would be fantastic, as 99% of the usage in the tree is cargo-culted.
> Defining things in straightforward terms would be a huge improvement.

That's now bug 1041941.
Comment on attachment 8460152 [details] [diff] [review]
Allow static library definitions to depend on shared libraries

Review of attachment 8460152 [details] [diff] [review]:
-----------------------------------------------------------------

::: build/docs/defining-binaries.rst
@@ +67,5 @@
>  Note that currently, the build system may not create an actual library for
>  static libraries. It is an implementation detail that shouldn't need to be
>  worried about.
>  
> +As a special rule, USE_LIBS is allowed to contain reference to shared

"contain references"

::: python/mozbuild/mozbuild/frontend/emitter.py
@@ +174,5 @@
> +            for o in lib.refs:
> +                yield o
> +                if isinstance(o, StaticLibrary):
> +                    for q in recurse_refs(o):
> +                        yield q

Could we get into an infinite loop here? Shouldn't be a big deal (it will just blow out the stack in milliseconds). But the error message won't be helpful.
Attachment #8460152 - Flags: review?(gps) → review+
Comment on attachment 8460153 [details] [diff] [review]
part 2 - Directly use the static library "xul" to link into "xul-gtest" instead of having an intermediate library "xul" used by "xul-shared" and "xul-gtest"

Review of attachment 8460153 [details] [diff] [review]:
-----------------------------------------------------------------

Mere mortals can almost understand how libxul is linked now. So nice.
Attachment #8460153 - Flags: review?(gps) → review+
(In reply to Gregory Szorc [:gps] from comment #6)
> Could we get into an infinite loop here? Shouldn't be a big deal (it will
> just blow out the stack in milliseconds). But the error message won't be
> helpful.

Theoretically yes, because there's no guard for cycles, but I wouldn't worry too much about that. I'll file a followup.
Blocks: 1042503
And a followup for --enable-shared-js standalone builds running make check:
https://hg.mozilla.org/integration/mozilla-inbound/rev/f5f7cf07eef6
Blocks: 1043019
Depends on: 1043448
QA Whiteboard: [qa-]
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.