Hi Justin, On Thu, 2020-12-31 at 12:19 -0500, Justin Erenkrantz wrote: > On Tue, Dec 29, 2020 at 5:00 AM Tristan Van Berkom < > [email protected]> wrote: > [...] > Yup, it was the lack of resolv.conf - thanks! I'll incorporate some of > these tricks into serf-bst's project.conf. Does it make sense to have > slightly saner defaults in buildstream?
Not really. BuildStream itself is only a build tool and is as decoupled as possible from the product being built with the tool. As such, it is a goal for us to remove as much as we can from the default project.conf settings before 2.0: https://github.com/apache/buildstream/blob/master/src/buildstream/data/projectconfig.yaml As you can see, most of the settings already present you are building a GNU/Linux system, or something that will run on such a system. We are hoping to remove anything that is payload specific from such settings, so that these can be built from the ground up for any given project and any OS we might support. That said, this does not preclude sharing of default settings across projects, for instance one could share defaults using cross junction includes: https://docs.buildstream.build/1.93.5/junctions/junction-includes.html [...] > > Well, the issue is that there is a vicious cycle between gdb's source > dependencies. > Cyclic dependencies are an unfortunate fact of life indeed :) > I tried creating elements for gdb - but, it requires makeinfo to build due > to this issue: > > https://sourceware.org/bugzilla/show_bug.cgi?id=14678 > > Texinfo requires gettext which requires wget...which requires makeinfo to > build. > > So, I can't technically define an upstream element for gdb from source. > So, it must be injected outside Buildstream (which we have via our platform > Docker image)...unless there's another trick to break these dependencies > somehow? With your current approach, you would want a gdb that is built for the runtime which you are using, in which case indeed it would be best to take the gdb which corresponds to the docker image you are based on. This could be done with an additional import/filter element to select only the gdb bits from your "platform Docker image". Alternatively, you might consider basing your project on freedesktop-sdk instead of an opaque docker image, or try building it in a similar way as freedesktop-sdk is doing it: https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/blob/master/elements/components/gdb.bst Interestingly, we do not build makeinfo with freedesktop-sdk, but we also build it directly from git rather than a dist tarball. That said, no matter how you fry the cat you still run into the issue #422 I mentioned earlier. I.e. you will have to either have the end result actually depend on gdb or not, until we add a way to stage multiple elements/targets into the same sandbox at `bst shell` time. > Related to the above, is the still unresolved issue #413: > > https://gitlab.com/BuildStream/buildstream/-/issues/413 > > > > This pertains to adding build directories to sandbox for `bst shell`, > > at the same locations where they were originally built, so that > > debuggers can easily find the sources for the binaries they were built > > for. > > > > Also, it doesn't look like we're keeping the debug symbols around - so, > even if I inject gdb into the platform, I don't have the debug symbols. > I'll hunt around to figure out if there's an obvious approach. So, I'm not > even getting to the point of having the symbols linking to the > (non-existent) source files... > In your case, it may just be how the toolchain is configured in the docker image you are extracting your runtime from. Given that you are using a Docker base, I would not expect that base to include debug symbols for the dependencies, but that does not necessarily mean you would not have them for the libraries/apps which you are building. More details ~~~~~~~~~~~~ If "strip-binaries" is not defined at all (which is default), then compiled binaries do not have their debug info forcefully stripped from them. With fdsdk, it seems that they have baked something pretty custom for some reason or another, but essentially the base toolchain is generating output with debug information included, and this debug information gets stripped out of the binaries and installed separately, via the "%{strip-binaries}" variable declaration: https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/blob/master/include/strip.yml The "freedesktop-sdk-stripper" program is built manually from the files at: https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/tree/master/files/stripper Normally this is done with a `find "%{install-root}" -exec ..` loop which invokes `objdump` and puts the debug info into corresponding files in "%{libdir}/debug". > > Of course, when we start talking about graphical debuggers and IDEs > > then this becomes a much more complex discussion. > > > > One point Sander mentioned is that some of the IDEs support remote symbol > serving - so, perhaps something we can explore that might ease the barrier > to entry. > Exactly, this one line of progress we discussed, which is still quite complex, as the symbols are inside the sandbox and need to be served from the sandbox in such a way that the IDE can discover it. It is a lot of legwork to come up with a design which makes it (fairly) easy enough for projects to setup and work with, I suppose the first step would be to create a hacky prototype for discovery purposes and then design around that. Cheers, -Tristan
