Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Meson does not add objects from not-installed static libraries while creating static libraries #3937

Closed
nirbheek opened this issue Jul 25, 2018 · 4 comments
Closed

Meson does not add objects from not-installed static libraries while creating static libraries #3937

nirbheek opened this issue Jul 25, 2018 · 4 comments
Labels
bug gnome gstreamer

Comments

@nirbheek
Copy link
Member

nirbheek commented Jul 25, 2018 •
edited
Loading

Projects often have internal (not-installed) static libraries which are linked into the installed library (f.ex., libcharset.a, libgnulib.a, and libpcre.a into libglib-2.0). These static libraries are always correctly linked into the shared library, but not into the static library, because Meson assumes that all static libraries that we link_with: are available after installation, and must be linked via the pkg-config file.

However, the aforementioned libraries must NOT be link_whole: because when you're doing a shared link, you don't want all the objects from them, only those that are actually used.

Solution: add the objects from not-installed static library that a static library links with.

This is also what autotools does: it tracks noinst_LTLIBRARIES and transparently adds the objects from libraries in LIBADD when generating a static librari.
@nirbheek nirbheek mentioned this issue Jul 25, 2018
Closed
@nirbheek
Copy link
Member Author

Actually, it's worse, even objects from link_whole: static libraries don't get added.

@nirbheek nirbheek changed the title Meson assumes only link_whole: static libraries are internal static libraries Meson does not add objects from not-installed static libraries while creating static libraries Jul 25, 2018
@nirbheek
Copy link
Member Author

As a crutch for this bug, we had another bad behaviour: we were always transitively adding static libraries when linking to a static library, even with link_whole:. This actually hid the fact that our built static libraries were unusable because executables using that static library would work just fine.

As a side-effect of this, we were also incorrectly adding internal static library dependencies of shared libraries while linking to shared libraries.

nirbheek added a commit that referenced this issue Jul 25, 2018
@nirbheek
Fix linking of shared/static libs with static libs
110e3ed 
This commit contains the following fixes:

1. When a shared library A does `link_with:` to static library B, the
   parts of B used by A will be added to A, and so we don't need to
   return B in A.get_dependencies() for targets that link to A. This
   already is the behaviour when a shared library A does `link_whole:`
   on B.

2. In situation (1), when generating a pkg-config file for A, we must
   also not add B to Libs.private for A. This already is the behaviour
   when a shared library A does `link_whole:` on B.

3. When a static library A does `link_whole:` to static library B, we
   must add the objects in B to A.

4. When a static library A does `link_with:` to static library B, and
   B is not installed (which makes it an internal static library), we
   must add the objects in B to A, otherwise nothing can use A.

5. In situation (4), when generating a pkg-config file for A, we must
   also not add B to Libs.private for A.

All these situations are tested by the unit test added in this commit.

Closes #3934
Closes #3937
@nirbheek nirbheek mentioned this issue Jul 25, 2018
Closed
nirbheek added a commit that referenced this issue Aug 7, 2018
@nirbheek
Fix linking of shared/static libs with static libs
3da7d29 
This commit contains the following fixes:

1. When a shared library A does `link_with:` to static library B, the
   parts of B used by A will be added to A, and so we don't need to
   return B in A.get_dependencies() for targets that link to A. This
   already is the behaviour when a shared library A does `link_whole:`
   on B.

2. In situation (1), when generating a pkg-config file for A, we must
   also not add B to Libs.private for A. This already is the behaviour
   when a shared library A does `link_whole:` on B.

3. When a static library A does `link_whole:` to static library B, we
   must add the objects in B to A.

4. When a static library A does `link_with:` to static library B, and
   B is not installed (which makes it an internal static library), we
   must add the objects in B to A, otherwise nothing can use A.

5. In situation (4), when generating a pkg-config file for A, we must
   also not add B to Libs.private for A.

All these situations are tested by the unit test added in this commit.

Closes #3934
Closes #3937
nirbheek added a commit that referenced this issue Aug 14, 2018
@nirbheek
Fix linking of shared/static libs with static libs
e6f6814 
This commit contains the following fixes:

1. When a shared library A does `link_with:` to static library B, the
   parts of B used by A will be added to A, and so we don't need to
   return B in A.get_dependencies() for targets that link to A. This
   already is the behaviour when a shared library A does `link_whole:`
   on B.

2. In situation (1), when generating a pkg-config file for A, we must
   also not add B to Libs.private for A. This already is the behaviour
   when a shared library A does `link_whole:` on B.

3. When a static library A does `link_whole:` to static library B, we
   must add the objects in B to A.

4. When a static library A does `link_with:` to static library B, and
   B is not installed (which makes it an internal static library), we
   must add the objects in B to A, otherwise nothing can use A.

5. In situation (4), when generating a pkg-config file for A, we must
   also not add B to Libs.private for A.

All these situations are tested by the unit test added in this commit.

Closes #3934
Closes #3937
nirbheek added a commit that referenced this issue Aug 19, 2018
@nirbheek
Fix linking of shared/static libs with static libs
ec98d22 
This commit contains the following fixes:

1. When a shared library A does `link_with:` to static library B, the
   parts of B used by A will be added to A, and so we don't need to
   return B in A.get_dependencies() for targets that link to A. This
   already is the behaviour when a shared library A does `link_whole:`
   on B.

2. In situation (1), when generating a pkg-config file for A, we must
   also not add B to Libs.private for A. This already is the behaviour
   when a shared library A does `link_whole:` on B.

3. When a static library A does `link_whole:` to static library B, we
   must add the objects in B to A.

4. When a static library A does `link_with:` to static library B, and
   B is not installed (which makes it an internal static library), we
   must add the objects in B to A, otherwise nothing can use A.

5. In situation (4), when generating a pkg-config file for A, we must
   also not add B to Libs.private for A.

All these situations are tested by the unit test added in this commit.

Closes #3934
Closes #3937
nirbheek added a commit that referenced this issue Sep 14, 2018
@nirbheek
Fix linking of shared/static libs with static libs
de5f972 
This commit contains the following fixes:

1. When a shared library A does `link_with:` to static library B, the
   parts of B used by A will be added to A, and so we don't need to
   return B in A.get_dependencies() for targets that link to A. This
   already is the behaviour when a shared library A does `link_whole:`
   on B.

2. In situation (1), when generating a pkg-config file for A, we must
   also not add B to Libs.private for A. This already is the behaviour
   when a shared library A does `link_whole:` on B.

3. When a static library A does `link_whole:` to static library B, we
   must add the objects in B to A.

4. When a static library A does `link_with:` to static library B, and
   B is not installed (which makes it an internal static library), we
   must add the objects in B to A, otherwise nothing can use A.

5. In situation (4), when generating a pkg-config file for A, we must
   also not add B to Libs.private for A.

All these situations are tested by the unit test added in this commit.

Closes #3934
Closes #3937
nirbheek added a commit that referenced this issue Sep 14, 2018
@nirbheek
Fix linking of shared/static libs with static libs
a5c4a17 
This commit contains the following fixes:

1. When a shared library A does `link_with:` to static library B, the
   parts of B used by A will be added to A, and so we don't need to
   return B in A.get_dependencies() for targets that link to A. This
   already is the behaviour when a shared library A does `link_whole:`
   on B.

2. In situation (1), when generating a pkg-config file for A, we must
   also not add B to Libs.private for A. This already is the behaviour
   when a shared library A does `link_whole:` on B.

3. When a static library A does `link_whole:` to static library B, we
   must add the objects in B to A.

4. When a static library A does `link_with:` to static library B, and
   B is not installed (which makes it an internal static library), we
   must add the objects in B to A, otherwise nothing can use A.

5. In situation (4), when generating a pkg-config file for A, we must
   also not add B to Libs.private for A.

All these situations are tested by the unit test added in this commit.

Closes #3934
Closes #3937
nirbheek added a commit that referenced this issue Sep 14, 2018
@nirbheek
Fix linking of shared/static libs with static libs
2d370c2 
This commit contains the following fixes:

1. When a shared library A does `link_with:` to static library B, the
   parts of B used by A will be added to A, and so we don't need to
   return B in A.get_dependencies() for targets that link to A. This
   already is the behaviour when a shared library A does `link_whole:`
   on B.

2. In situation (1), when generating a pkg-config file for A, we must
   also not add B to Libs.private for A. This already is the behaviour
   when a shared library A does `link_whole:` on B.

3. When a static library A does `link_whole:` to static library B, we
   must add the objects in B to A.

4. When a static library A does `link_with:` to static library B, and
   B is not installed (which makes it an internal static library), we
   must add the objects in B to A, otherwise nothing can use A.

5. In situation (4), when generating a pkg-config file for A, we must
   also not add B to Libs.private for A.

All these situations are tested by the unit test added in this commit.

Closes #3934
Closes #3937
@ernestask
Copy link
Contributor

As a side note, https://github.com/swaywm/wlroots seems to be affected as well when built with -Ddefault_library=static. An eight-byte file only is generated in the end.

@haasn haasn mentioned this issue Dec 7, 2018
Closed
@whot whot mentioned this issue Feb 8, 2019
Closed
whot added a commit to whot/libxkbcommon that referenced this issue Feb 8, 2019
@whot
meson.build: manually link all sources into the libraryo
6110946 
This works around meson bug 3937, 'link_whole' arguments don't get added into
the final static library and we end up with a virtually empty 8-byte
libxkbcommon.a file, see mesonbuild/meson#3937

Woraround is simply by adding all sources to both libraries we need them in.
This obioviously compiles them twice but this year's winter was cold and
bit of extra warmth will be appreciated.

Fixes xkbcommon#84

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
whot added a commit to whot/libxkbcommon that referenced this issue Feb 8, 2019
@whot
meson.build: manually link all sources into the libraryo
9f581a2 
This works around meson bug 3937, 'link_whole' arguments don't get added into
the final static library and we end up with a virtually empty 8-byte
libxkbcommon.a file, see mesonbuild/meson#3937

Woraround is simply by adding all sources to both libraries we need them in.
This obioviously compiles them twice but this year's winter was cold and
bit of extra warmth will be appreciated.

Fixes xkbcommon#84

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
whot added a commit to whot/libxkbcommon that referenced this issue Feb 8, 2019
@whot
meson.build: manually link all sources into the library
916eaed 
This works around meson bug 3937, 'link_whole' arguments don't get added into
the final static library and we end up with a virtually empty 8-byte
libxkbcommon.a file, see mesonbuild/meson#3937

Woraround is simply by adding all sources to both libraries we need them in.
This obioviously compiles them twice but this year's winter was cold and
bit of extra warmth will be appreciated.

Fixes xkbcommon#84

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
whot added a commit to whot/libxkbcommon that referenced this issue Feb 8, 2019
@whot
meson.build: manually link all sources into the library
4d5031b 
This works around meson bug 3937, 'link_whole' arguments don't get added into
the final static library and we end up with a virtually empty 8-byte
libxkbcommon.a file, see mesonbuild/meson#3937

Workaround is simply by adding all sources to both libraries we need them in.
This obioviously compiles them twice but this year's winter was cold and
bit of extra warmth will be appreciated.

Fixes xkbcommon#84

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
whot added a commit to whot/libxkbcommon that referenced this issue Feb 8, 2019
@whot
meson.build: manually link all sources into the library
75ce741 
This works around meson bug 3937, 'link_whole' arguments don't get added into
the final static library and we end up with a virtually empty 8-byte
libxkbcommon.a file, see mesonbuild/meson#3937

Workaround is simply to add all sources to both libraries we need them in.
This obviously compiles them twice but this year's winter was cold and
bit of extra warmth will be appreciated.

Fixes xkbcommon#84

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
@whot whot mentioned this issue Feb 8, 2019
Merged
whot added a commit to whot/libxkbcommon that referenced this issue Feb 10, 2019
@whot
meson.build: link the sources directly into libxkbcommon-x11
bcb2497 
Similar to 75ce741, just for the -x11
sublibrary.

This works around meson bug 3937, 'link_whole' arguments don't get added into
the final static library and we end up with a virtually empty 8-byte
libxkbcommon-x11.a file, see mesonbuild/meson#3937

The internal lib is still built for the one test case that requires it.

Fixes xkbcommon#86

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
bluetech pushed a commit to xkbcommon/libxkbcommon that referenced this issue Feb 11, 2019
@whot @bluetech
meson.build: link the sources directly into libxkbcommon-x11
3f50953 
Similar to 75ce741, just for the -x11
sublibrary.

This works around meson bug 3937, 'link_whole' arguments don't get added into
the final static library and we end up with a virtually empty 8-byte
libxkbcommon-x11.a file, see mesonbuild/meson#3937

The internal lib is still built for the one test case that requires it.

Fixes #86

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
buildroot-auto-update pushed a commit to buildroot/buildroot that referenced this issue Aug 15, 2019
@ffontaine @tpetazzoni
package/gupnp: switch back to autotools
d597d5a 
Switch back to autotools to fix static build with rygel (and so reverts
partially commit 66a3fbb
"package/gupnp: bump to version 1.0.4").

Indeed gupnp uses meson's subproject feature for guul which is just
plainly broken on static build with meson, see:
mesonbuild/meson#3934
mesonbuild/meson#3937
mesonbuild/meson#3939

This will fix a build failure with rygel

Fixes:
 - http://autobuild.buildroot.org/results/ebbf96a1be5547e416feb1e96e55986890d0a1de

Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
eli-schwartz added a commit to eli-schwartz/pacman that referenced this issue Sep 19, 2019
@eli-schwartz
meson: fix libcommon being publicly exposed as a static link dependency
7e70ff1 
libcommon isn't even installed, so that means libalpm.a (if installed)
is fatally broken as it misses objects. The problem is that meson
doesn't handle this case correctly:

mesonbuild/meson#3934
mesonbuild/meson#3937
mesonbuild/meson#3939

Work around this by manually extracting libcommon's .o files into the
list of objects used to create libalpm.
@xclaesse
Copy link
Member

xclaesse commented Oct 1, 2019

Should be fixed by #5936

@xclaesse xclaesse closed this as completed Oct 1, 2019
eworm-de pushed a commit to eworm-de/pacman that referenced this issue Oct 7, 2019
@eli-schwartz @allanmcrae
meson: fix libcommon being publicly exposed as a static link dependency
c0da1ba 
libcommon isn't even installed, so that means libalpm.a (if installed)
is fatally broken as it misses objects. The problem is that meson
doesn't handle this case correctly:

mesonbuild/meson#3934
mesonbuild/meson#3937
mesonbuild/meson#3939

Work around this by manually extracting libcommon's .o files into the
list of objects used to create libalpm.

Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
Taeril added a commit to Taeril/mkd that referenced this issue Dec 6, 2019
@Taeril
Install libmd4c.a as workaround on meson bugs 3937 and 3934
9337b0c 
mesonbuild/meson#3937
mesonbuild/meson#3934
@eli-schwartz eli-schwartz mentioned this issue Jan 26, 2021
Closed
@eli-schwartz eli-schwartz mentioned this issue Aug 31, 2021
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug gnome gstreamer
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Fix linking of shared/static libs with static libs mesonbuild/meson
3 participants
@nirbheek @xclaesse @ernestask