linux/poky.git/meta/recipes-devtools/libtool, branch yocto-3.1.15

libtool: Allow libtool-cross to reproduce

2021-10-23T22:14:17+00:00

The hostname removal from the script is useful to make libtool-cross reproduce. Apply the patch everywhere as it doesn't cause any issues. (From OE-Core rev: f1cc4b8d7503331f04d3f217ae67d0fd4cc483c5) Signed-off-by: Richard Purdie (cherry picked from commit 3c61c6f20187154d677085fc9ccdcd762d4cdf3a) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

libtool: Fix lto option passing for reproducible builds

2021-10-23T22:14:17+00:00

If lto is enabled, we need the prefix-map variables to be passed to the linker. Add these to the list of options libtool passes through. (From OE-Core rev: 3dcc84e37ce7e94e746304ee2a4437251af0ae41) Signed-off-by: Richard Purdie (cherry picked from commit 2c26d2c00b47df856fb2d9c35486b135094d46ac) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

libtool: make sure autoheader run before automake

2021-04-30T13:37:37+00:00

When use automake to generate Makefile.in from Makefile.am, there comes below race: | configure.ac:45: error: required file 'config-h.in' not found It is because the file config-h.in in updating process by autoheader, so make automake run after autoheader to avoid the above race. (From OE-Core rev: 0d5dd68a07707f8b8428fe564414e2f5b7433ed5) Signed-off-by: Mingli Yu Signed-off-by: Richard Purdie (cherry picked from commit 1fc0a4a98e65db7efba8bb5cb835101ea5dd865b) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

libtool: make sure autoheader run before autoconf

2021-04-06T21:45:36+00:00

autoheader will update ../libtool-2.4.6/libltdl/config-h.in which autoconf needs, so there comes a race sometimes as below: | configure.ac:45: error: required file 'config-h.in' not found | touch '../libtool-2.4.6/libltdl/config-h.in' So make sure autoheader run before autoconf to avoid this race. (From OE-Core rev: ac63b30ac7dce558c9de5be985c153e4617157d5) Signed-off-by: Mingli Yu Signed-off-by: Richard Purdie (cherry picked from commit d8451cbef5906b67756582fdfc44eb01ed3512fc) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

libtools-cross/shadow-sysroot: Use nopackages inherit

2020-10-15T12:45:50+00:00

When testing pseudo changes I realised these recipes have packaging tasks but don't generate packages. Drop the packages tasks for cleanliness. (From OE-Core rev: 275d504b2f979901278141a4ba217d02a099f980) Signed-off-by: Richard Purdie (cherry picked from commit ef9c11797b5d626bdb40b4509d8b2b0d461ff9ea) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

libtool: remove host information from libtool

2019-07-22T16:31:04+00:00

Import patch from Debian. (From OE-Core rev: b2e0b383a17a3cd450adb3d86f7f818729438375) Signed-off-by: Joe Slater Signed-off-by: Richard Purdie

libtool: Fix ignoring compiler-rt libs

2019-01-27T13:05:17+00:00

This is a limitation of libtool where it is not aware of compiler-rt being a compiler internal library, this patch fixes it (From OE-Core rev: ebc96f2f612ebc1b7aefb06935bb308fc2e40cfd) Signed-off-by: Khem Raj Signed-off-by: Richard Purdie

libtool-cross: Handle ccache sstate 'infection' issues

2018-08-14T10:36:31+00:00

On a system without ccache, f you: INHERIT += "ccache" bitbake libtool-cross bitbake apmd then it fails due to being unable to find ccache. The references to ccache are coded into libtool-cross but the sstate checksum doesn't reflect this due to the way the class is coded (output should be the same regardless). The simplest solution is to remove references to ccache from the libtool script. The output then works regardless of whether ccache is present or not. The libtool-cross script is only used in a handful of cases (most of the time its dynamically generated by autoconf) so any performance issue is minor. (From OE-Core rev: ed550a49d2114c56e5bc033ecd0e83073d2d4067) Signed-off-by: Richard Purdie

libtool: Fix patch status tag

2018-08-01T09:28:05+00:00

(From OE-Core rev: 28fc470e5e10ee9cce893d037ed5e518bc5612f5) Signed-off-by: Richard Purdie

libtool: Fix problem with libtoolize in multilib installations

2018-07-31T21:47:35+00:00

Without this patch /usr/bin/libtoolize is different for each multilib since their host-triplets are different, despite there being no difference in the functionality of libtoolize itself. This change just patches out the problematic line since its just a comment for the user in help text. Ugly but solves the problem. This fixes issues where libtool and libXX-libtool couldn't be installed into the same system. (From OE-Core rev: f70040fd3ca3508d33ed24c749c0b8095b020dab) Signed-off-by: Richard Purdie