Re: libstdc++ link errors in support/links-dso-program

["Горбешко Богдан" <bodqhrohro@gmail.com>]

On 10/04/2024 16:22, Konstantin Kharlamov wrote:
> On Wed, 2024-04-10 at 15:50 +0300, Горбешко Богдан via Libc-help wrote:
>> On 10/04/2024 15:03, Florian Weimer wrote:
>>> * Горбешко Богдан:
>>>
>>>> We already have a solution to build this in Docker, though the
>>>> target
>>>> test VPS is tight on resources and I wouldn't really like to mess
>>>> with
>>>> Docker there.
>>> You don't have to build on the target system directly, you just
>>> need to
>>> use a container/chroot environment that matches the target
>>> distribution
>>> version.  These containers tend to be fairly lightweight, requiring
>>> less
>>> space and resources than a full glibc build.
>> An unpacked binary Glibc package takes just 12 MB. A minimal Debian
>> image is orders of magnitude larger.
>>
>> And the primary problem with Docker is that continuous rebuilds
>> occupy
>> the disk space rapidly fast, as it normally preserves old builds,
>> which
>> is not a case with builds on a host system.
> I am confused. Docker may or may not preserve something depending on
> how you use it. You're saying compilation on the host system is not
> preserved, which confuses me even further because why would it not.
> Unless you run `make clean && make distclean` sure you have all
> artifacts in place.
The primary difference is that artifacts overwrite the same files, while 
in Docker every difference involves creating new images (or new cache 
entries if BuildKit is used) for the whole chain after the layer where a 
change happened.
>
> Anyway. As far as I understand what you're saying you don't want Docker
> to preserve a build. I presume it's being "preserved" because you're
> building on a host directory that is mount-bound via `-v` option (there
> isn't many other ways you'd be getting that. Saving container state is
> another one but why would you do that if you don't want the state to be
> saved. So it is likely not that). You can solve that by using mount-
> bind in such way so that any changes the container does to the mound-
> bind will only be visible inside the container. Idk of any ways to do
> that in the vanilla Docker, but in Podman it's supported by `:O`
> option, i.e. `-v my_host_dir:/mnt:O`.

I already added a lot of bind mounts and cache mounts to minimize the 
redundancy. Cache mounts are reused between builds, at least.