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

[Горбешко Богдан]

On 10/04/2024 16:55, Konstantin Kharlamov wrote:
> On Wed, 2024-04-10 at 16:30 +0300, Горбешко Богдан wrote:
>> 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.
> Why are you re-building Glibc in CI in the first place? Are you doing
> some glibc development, or is it the same Glibc version built over and
> over?

It's not a CI and I don't need a patched Glibc actually.

I mentioned already that I'm just cross-compiling a Golang project to be 
run and tested during development frequently on an older distribution.

>
> In company I work at we have various 3rd party packages with
> customizations, and to avoid rebuilding them every time we just store
> them to a separate repo that is referred by the main project via git-
> submodule. Works very well.