1041936 - Allow static library definitions to depend on shared libraries

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[Mike Hommey [:glandium]]

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.

Comment 1

[Mike Hommey [:glandium]]

Attachment: Allow static library definitions to depend on shared libraries

Comment 2

[Mike Hommey [:glandium]]

Attachment: 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"

Comment 3

[Mike Hommey [:glandium]]

https://tbpl.mozilla.org/?tree=Try&rev=f496b902bf88

Comment 4

[(not currently active) Ted Mielczarek]

(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.

Comment 5

[Mike Hommey [:glandium]]

(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 6

[Gregory Szorc [:gps]]

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.

Comment 7

[Gregory Szorc [:gps]]

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.

Comment 8

[Mike Hommey [:glandium]]

(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.

Comment 9

[Mike Hommey [:glandium]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/cd98f0ea7fd9
https://hg.mozilla.org/integration/mozilla-inbound/rev/c71f854e6358

Comment 10

[Mike Hommey [:glandium]]

And a followup for --enable-shared-js standalone builds running make check:
https://hg.mozilla.org/integration/mozilla-inbound/rev/f5f7cf07eef6

Comment 11

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/cd98f0ea7fd9
https://hg.mozilla.org/mozilla-central/rev/c71f854e6358
https://hg.mozilla.org/mozilla-central/rev/f5f7cf07eef6