Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.rc > #404878 > unrolled thread

Bug#1096811: hipblas: ftbfs with GCC-15

Back to article view | Back to linux.debian.bugs.rc

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#1096811: hipblas: ftbfs with GCC-15 Cordell Bloor <cgmb@slerp.xyz> - 2025-11-19 13:00 +0100
    Bug#1096811: hipblas: ftbfs with GCC-15 Santiago Vila <sanvila@debian.org> - 2025-11-19 13:50 +0100
      Bug#1096811: hipblas: ftbfs with GCC-15 Cordell Bloor <cgmb@slerp.xyz> - 2025-11-19 20:40 +0100

#404878 — Bug#1096811: hipblas: ftbfs with GCC-15

[Multipart message — attachments visible in raw view] — view raw

Hi Santiago,

On 2025-11-19 03:44, Santiago Vila wrote:
> I believe this bug ("FTBFS with GCC 15") is fixed in the above
> version, so I'm closing it by hand now.

I don't know how I screwed up twice, but 6.4.1-2 FTBFS as well. I'll do 
a third upload after triple-checking my work and then this should be fixed.

> While we are at it, I noticed a very significant raise in the amount
> of memory allocated while building the package, from 2GB in trixie to
> 14GB in current unstable (using machines with 2 CPUs).
>
> Is this normal/expected?

The hipblas tests have adopted a structure more similar to rocblas and 
they're also building two binaries now instead of one. I think the new 
upstream design is just more resource intensive to build and run.

I guess it's normal.

Sincerely,
Cory Bloor

[toc] | [next] | [standalone]

#404881

> > I believe this bug ("FTBFS with GCC 15") is fixed in the above
> > version, so I'm closing it by hand now.
> 
> I don't know how I screwed up twice, but 6.4.1-2 FTBFS as well.

Yes, but for an unrelated reason, that's why I filed that as a different bug.

> [...]
> > While we are at it, I noticed a very significant raise in the amount
> > of memory allocated while building the package, from 2GB in trixie to
> > 14GB in current unstable (using machines with 2 CPUs).
> > 
> > Is this normal/expected?
> 
> The hipblas tests have adopted a structure more similar to rocblas and
> they're also building two binaries now instead of one. I think the new
> upstream design is just more resource intensive to build and run.
> 
> I guess it's normal.

Well, the problem now is not just "requiring a lot of memory" in a generic sense
but more like requiring a lot of memory *per* CPU.

In fact, I can build the package on machines with 16 GB of RAM having
1 CPU but not on machines with 16 GB having 2 CPUs, where I get this:

c++: fatal error: Killed signal terminated program cc1plus
compilation terminated.

Could you please adjust the number of CPUs to be used according
to available memory?

I did something like that in graph-tool for the same reason:

https://salsa.debian.org/python-team/packages/graph-tool/-/commit/315bc676236d997573ccdda8d820376755744dab

but I believe now there are more advanced ways to achieve the same.

(Sorry for my flaky memory, Cc: Helmut who will probably remember it)

Thanks.

[toc] | [prev] | [next] | [standalone]

#404912

[Multipart message — attachments visible in raw view] — view raw

Hi Santiago,

On 2025-11-19 05:40, Santiago Vila wrote:
> Well, the problem now is not just "requiring a lot of memory" in a generic sense
> but more like requiring a lot of memory *per* CPU.
>
> In fact, I can build the package on machines with 16 GB of RAM having
> 1 CPU but not on machines with 16 GB having 2 CPUs, where I get this:
>
> c++: fatal error: Killed signal terminated program cc1plus
> compilation terminated.
>
> Could you please adjust the number of CPUs to be used according
> to available memory?
>
> I did something like that in graph-tool for the same reason:
>
> https://salsa.debian.org/python-team/packages/graph-tool/-/commit/315bc676236d997573ccdda8d820376755744dab
>
> but I believe now there are more advanced ways to achieve the same.

I was preparing to integrate your solution, but I realized that I 
typically build with -j32 on my 64GB workstation. I probably still could 
use this solution but it seems like it would be very conservative for 
users with more memory available. We should open a new bug to discuss 
further, as I'm afraid this is a problem that is going to be very common 
in the ROCm stack and we will need a robust solution.

Sincerely,
Cory Bloor

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.rc

csiph-web