Bruce Ashfield <bruce.ashfi...@gmail.com> escreveu no dia domingo, 23/04/2023 à(s) 20:55:
> On Sat, Apr 22, 2023 at 9:06 AM Christoph Lauer > <christoph.la...@email.de> wrote: > > > > Am 21.04.23 um 22:28 schrieb Bruce Ashfield: > > > On Wed, Apr 19, 2023 at 11:03 PM Bruce Ashfield via > > > lists.openembedded.org > > > <bruce.ashfield=gmail....@lists.openembedded.org> wrote: > > >> > > >> On Wed, Apr 19, 2023 at 6:54 PM Richard Purdie > > >> <richard.pur...@linuxfoundation.org> wrote: > > >>> > > >>> On Wed, 2023-04-19 at 23:34 +0100, Jose Quaresma wrote: > > >>>> Hi, > > >>>> > > >>>> Not related with the previous discussion but just for > > >>>> your information. > > >>>> The rm_work.bbclass has an exception for the kernel recipes [1]. > > >>>> So I don't understand why we can't do the same for the make-mod- > > >>>> scripts > > >>>> who is the twin brother of all these kernel recipes. > > >>>> > > >>>> [1] > > >>>> > https://git.openembedded.org/openembedded-core/tree/meta/classes/rm_work.bbclass#n168 > > >>> > > >>> Ideally we wouldn't be doing this for the kernel recipes. > > >>> > > >>> There is also a big difference to that and the proposed patch. The > > >>> proposed patch was preserving a specific directory rather than an > > >>> entire recipe. Removing the task stamps but leaving a small piece of > > >>> WORKDIR is quite different to preserving WORKDIR and STAMPS for a > > >>> specific recipe. The former is not tested and will break things. The > > >>> latter is better tolerated by bitbake. > > >> > > >> Agreed. > > >> > > >> Plus, I am working on this now. > > >> > > >> I have static linking of the scripts/tools working, but what I haven't > > >> figured out is how to do that without patching the Makefiles. > > >> > > > > > > It turned out to be quite the battle to get older kernels what was > > > required for static linking of the tools. > > > > > > Attached is my WIP patch. I'm out of the office early next week, but > > > will revisit it once I'm back. > > > > > > Bruce > > > > > >> Next up will be some rpath trickery. > > >> > > >> Bruce > > >> > > >>> > > >>> So yes, we could do the same. I'm sure there will be other recipes > > >>> people want to preserve for other reasons. Where do we draw the line? > > >>> We could preserve everything and drop rm_work, then we wouldn't have > > >>> these problems? :) > > >>> > > >>> Cheers, > > >>> > > >>> Richard > > >> > > >> > > >> > > >> -- > > >> - Thou shalt not follow the NULL pointer, for chaos and madness await > > >> thee at its end > > >> - "Use the force Harry" - Gandalf, Star Trek II > > >> > > >> > > >> > > > > > > > > > > Thank you for your work, I see you put some time and effort into it. > > HOSTPKG_CONFIG is, as you mentioned, available since kernel version 5.19 > > Yes, I realize that and documented it in the patch ... but I also > tested on pre-5.19 kernels and what I have in the patch works. Did it > not work in your testing ? > I will test the patch on a couple of kernel versions with some of them pre-5.19 but all in 5 major versions. I will say something about my results later this week. Thanks for working on this one. Jose > > > (see kernel patch [1]), so we need a way to call 'pkg-config --static' > > with pre-5.19 kernels. A way without modifying the Makefile would be to > > modify openssls pkg-config in recipe-sysroot-native of make-mod-script, > > so 'pkg-config --libs' actually shows the dependencies of 'pkg-config > > --static --libs', but it's a bit hacky. > > Already considered, and discarded. That's not going to fly. > > > > > Also fully-static executables still need the same glibc during runtime > > that they were built with, which makes them error-prone and is generally > > discouraged. As an alternative, we could build dynamic executables that > > use the static libcrypto library. The linker links by default against > > the shared library, so we could remove them from recipe-sysroot-native > > to force linking against the static library (again, somewhat hacky). > > Also considered and discarded. > > As do the dynamically linked ones for the c runtime. We aren't talking > about using these outside of a single build and they are generated on > the fly, so again, there's very little concern about runtimes changing > after linking.. There's less risk in static than in the alternatives. > > Bruce > > > > > > [1] > > > https://github.com/torvalds/linux/commit/d5ea4fece4508bf8e72b659cd22fa4840d8d61e5 > > > > -- > - Thou shalt not follow the NULL pointer, for chaos and madness await > thee at its end > - "Use the force Harry" - Gandalf, Star Trek II > -- Best regards, José Quaresma
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#180349): https://lists.openembedded.org/g/openembedded-core/message/180349 Mute This Topic: https://lists.openembedded.org/mt/98296212/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
