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 0.47.1 breaks cross builds using Boost Python #3881

Closed
mtp401 opened this issue Jul 12, 2018 · 16 comments · Fixed by #3894
Closed

Meson 0.47.1 breaks cross builds using Boost Python #3881

mtp401 opened this issue Jul 12, 2018 · 16 comments · Fixed by #3894
Labels
boost compilers cross regression
Milestone
0.47.2

Comments

@mtp401
Copy link

mtp401 commented Jul 12, 2018

I've bisected between master and 0.46.1 and found that the changeset in #3792 has broken cross builds that utilize Boost Python. The issue is that there is an additional link dependency (libpythonX.Y) that is required to successfully link with --whole-archive. Meson ends up cycling through all of the cross binaries, failing along the way and then falls back and ends up incorrectly picking the host libboost_python.so which causes link errors later on in the build after dependency resolution is complete.
@nirbheek nirbheek added this to the 0.47.2 milestone Jul 13, 2018
@nirbheek
Copy link
Member

CCing @bruce-richardson

There are three possible ways to fix this:

  1. Find a way to prune the linker search path to match the host machine
  2. Find a way to link to the library for the arch check, but not fail on undefined symbols
  3. Find another way to check whether a library matches the host machine's architecture

@bruce-richardson
Copy link
Contributor

I was looking at 1, and made some progress. - need to get back to it However, I still think a test link is needed before we return a result to the app. Perhaps we can try with whole-archive only for static libs.

@nirbheek
Copy link
Member

@mtp401 the cross boost python library you're talking about is a static library or a shared library?

@mtp401
Copy link
Author

mtp401 commented Jul 13, 2018

The library I'm using is a shared library. I dropped by the meson IRC channel to discuss a solution yesterday but no one was available. I think an acceptable middle ground (if I understand the intent of #3792) would be to only pass --whole-archive for static libriaries as @bruce-richardson stated above. I can easily test any fixes that are developed.

@nirbheek
Copy link
Member

Actually, what's really confusing is that this should not be happening at all. Boost uses the dirs: argument to find_library, and we don't run the link check against libraries in those dirs at all. Only for libraries in the system dirs. Can you please paste the relevant part of the build file and a log file for the failure?

@bruce-richardson
Copy link
Contributor

if the appropriate lib is not found in the dirs argument, there is still a check for system dirs. That should still be fixed.

@nirbheek
Copy link
Member

nirbheek commented Jul 13, 2018 •
edited
Loading

if the appropriate lib is not found in the dirs argument, there is still a check for system dirs. That should still be fixed.

That's #3758, and we need to add new API to handle that.

We changed the implementation to not do the link check against non-system libraries because of #3833, so linking against Boost Python should not fail because of the link check.

@asavah
Copy link

asavah commented Jul 13, 2018

And not only boost-python is broken.

0.47.1 breaks crosscompiling sshfs:

[7/7] Linking target sshfs.
FAILED: sshfs
ccache aarch64-rock64-linux-gnu-gcc  -o sshfs 'sshfs@exe/sshfs.c.o' 'sshfs@exe/cache.c.o' -Wl,--no-undefined -Wl,--as-needed -Wl,--start-group /home/asavah/kross/build/rock64/rootfs/usr/lib/libfuse3.so /home/asavah/kross/build/rock64/rootfs/usr/lib/libpthread.so /home/asavah/kross/build/rock64/rootfs/usr/lib/libglib-2.0.so /home/asavah/kross/build/rock64/rootfs/usr/lib/libgthread-2.0.so -Wl,--end-group -pthread -mcpu=cortex-a53+crc+fp+simd+crypto -ftree-vectorize -O2 -Wl,-O2 -Wl,--as-needed -fuse-linker-plugin -flto=8 -Wl,-flto=8 -fno-fat-lto-objects -fuse-ld=gold
/home/asavah/kross/host/rock64/lib/gcc/aarch64-rock64-linux-gnu/8.1.1/../../../../aarch64-rock64-linux-gnu/bin/ld.gold: error: cannot open /usr/lib/libpthread.so.0: No such file or directory
/home/asavah/kross/host/rock64/lib/gcc/aarch64-rock64-linux-gnu/8.1.1/../../../../aarch64-rock64-linux-gnu/bin/ld.gold: error: cannot open /usr/lib/libpthread_nonshared.a: No such file or directory

As you can see it tries to link host libs, which is obviously very wrong.
/home/asavah/kross/build/rock64/rootfs/usr/lib/libpthread.so is a linker script (vanilla glibc 2.27)

/* GNU ld script
   Use the shared library, but some functions are only in
   the static library, so try that secondarily.  */
OUTPUT_FORMAT(elf64-littleaarch64)
GROUP ( /usr/lib/libpthread.so.0 /usr/lib/libpthread_nonshared.a )

meson 0.47.0 builds the same sources just fine.

@bruce-richardson
Copy link
Contributor

For sshfs, the root cause commit is likely different though, since the commit referenced that breaks boost is present in 0.47.0 as well as 0.47.1

@bruce-richardson bruce-richardson mentioned this issue Jul 16, 2018
Merged
@jpakkane
Copy link
Member

But the command line specifically points to /home/asavah/kross/build/rock64/rootfs/usr/lib/libpthread.so. Where does that system pthread come from?

@asavah
Copy link

asavah commented Jul 16, 2018 •
edited
Loading

@jpakkane

Where does that system pthread come from?

Probably from wrong $LINK_ARGS.

Notice that ld.gold is used, if ld.bfd is used meson succeeds in both versions.

meson 0.47.0 working

build sshfs: c_CROSS_LINKER sshfs@exe/sshfs.c.o sshfs@exe/cache.c.o | /home/asavah/kross/build/rock64/rootfs/usr/lib/libpthread.a /home/asavah/kross/build/rock64/rootfs/usr/lib/libgthread-2.0.so /home/asavah/kross/build/rock64/rootfs/usr/lib/libpthread.so /home/asavah/kross/build/rock64/rootfs/usr/lib/libglib-2.0.so /home/asavah/kross/build/rock64/rootfs/usr/lib/libfuse3.so
 LINK_ARGS = -Wl,--no-undefined -Wl,--as-needed -Wl,--start-group /home/asavah/kross/build/rock64/rootfs/usr/lib/libfuse3.so -lpthread /home/asavah/kross/build/rock64/rootfs/usr/lib/libglib-2.0.so /home/asavah/kross/build/rock64/rootfs/usr/lib/libgthread-2.0.so -Wl,--end-group -pthread

meson 0.47.1 FAILS

build sshfs: c_CROSS_LINKER sshfs@exe/sshfs.c.o sshfs@exe/cache.c.o | /home/asavah/kross/build/rock64/rootfs/usr/lib/libpthread.so /home/asavah/kross/build/rock64/rootfs/usr/lib/libgthread-2.0.so /home/asavah/kross/build/rock64/rootfs/usr/lib/libglib-2.0.so /home/asavah/kross/build/rock64/rootfs/usr/lib/libfuse3.so
 LINK_ARGS = -Wl,--no-undefined -Wl,--as-needed -Wl,--start-group /home/asavah/kross/build/rock64/rootfs/usr/lib/libfuse3.so /home/asavah/kross/build/rock64/rootfs/usr/lib/libpthread.so /home/asavah/kross/build/rock64/rootfs/usr/lib/libglib-2.0.so /home/asavah/kross/build/rock64/rootfs/usr/lib/libgthread-2.0.so -Wl,--end-group -pthread

The diference is -lpthread (ok) vs /home/asavah/kross/build/rock64/rootfs/usr/lib/libpthread.so (full path, NOT ok)

You can see the contents of libpthread.so (LD SCRIPT) in my post above.

@jpakkane
Copy link
Member

This is a bug in Meson but you should note that GCC's documentation says you should use-pthread when compiling and linking. Not -lpthread.

@asavah
Copy link

asavah commented Jul 17, 2018

It comes from libfuse .pc
https://github.com/libfuse/libfuse/blob/master/lib/meson.build#L41

Now I'm not 100% sure than this is a bug in meson itself,
ld.bfd links as expected even with absolute paths in GROUP( )
ld.gold fails, binutils are correctly configured with --with-sysroot=
what should meson do with hardcoded absolute paths in linker scripts when crosscompiling?
Parse them and add absolute paths to LINK_ARGS?
Hacky and cumbersome.

I've made a quick hack and removed /usr/lib/ prefix from libpthread.so and libc.so (just in case) and now gold links as a champ too.

@nirbheek
Copy link
Member

@asavah your issue should be fixed with #3994, can you try meson master?

@mtp401 your issue will be fixed by #3894 when it's ready.

@nirbheek nirbheek mentioned this issue Aug 11, 2018
Closed
@asavah
Copy link

asavah commented Aug 11, 2018

@nirbheek yes, indeed this is fixed in master. Thank you!

On a side note: I've already migrated to glibc-2.28 in which libpthread.so is no longer a linker script but a symlink and libpthread_nonshared.a no longer exists, it's libpthread.a now. However I replaced the symllink with the linker script and copied libpthread.a => libpthread_nonshared.a in order recreate this.

All good, both ld.bfd and ld.gold link just fine. Thanks again.

nirbheek pushed a commit to bruce-richardson/meson that referenced this issue Aug 19, 2018
@bruce-richardson @nirbheek
find_library: Use _build_wrapper to get library dirs
148dc86 
This means that we will take into account all the flags set in the
cross file when fetching the list of library dirs, which means we
won't incorrectly look for 64-bit libraries when building for 32-bit.

Signed-off-by: Nirbheek Chauhan <nirbheek@centricular.com>

Closes mesonbuild#3881
nirbheek pushed a commit to bruce-richardson/meson that referenced this issue Aug 19, 2018
@bruce-richardson @nirbheek
find_library: Use _build_wrapper to get library dirs
ef1235f 
This means that we will take into account all the flags set in the
cross file when fetching the list of library dirs, which means we
won't incorrectly look for 64-bit libraries when building for 32-bit.

Signed-off-by: Nirbheek Chauhan <nirbheek@centricular.com>

Closes mesonbuild#3881
nirbheek pushed a commit that referenced this issue Aug 22, 2018
@bruce-richardson @nirbheek
find_library: Use _build_wrapper to get library dirs
8c9296e 
This means that we will take into account all the flags set in the
cross file when fetching the list of library dirs, which means we
won't incorrectly look for 64-bit libraries when building for 32-bit.

Signed-off-by: Nirbheek Chauhan <nirbheek@centricular.com>

Closes #3881
@mtp401
Copy link
Author

mtp401 commented Aug 23, 2018

@nirbheek @bruce-richardson just got a chance to test this out, sorry for the delay. This does fix the build issues I was having with Boost Python. Thanks!

nirbheek pushed a commit that referenced this issue Aug 23, 2018
@bruce-richardson @nirbheek
find_library: Use _build_wrapper to get library dirs
81b12a6 
This means that we will take into account all the flags set in the
cross file when fetching the list of library dirs, which means we
won't incorrectly look for 64-bit libraries when building for 32-bit.

Signed-off-by: Nirbheek Chauhan <nirbheek@centricular.com>

Closes #3881
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
boost compilers cross regression
Projects
None yet
Milestone
0.47.2
Development

Successfully merging a pull request may close this issue.

Use cross-compilation flags when checking for system directories bruce-richardson/meson
5 participants
@nirbheek @jpakkane @asavah @mtp401 @bruce-richardson