Re: x32: mariadb: if defined __ILP32__ and __x86_64__ ?

2024-07-03 Thread наб 
Hi!

On Tue, Jul 02, 2024 at 09:05:14PM -0700, Otto Kekäläinen wrote:
> tests/mysql_client_fw.c
> @@ -1442
> 
> #if defined __x86_64__
>   compile_time_assert(sizeof(MYSQL) == 1272);
> #elif defined __i386__
>   compile_time_assert(sizeof(MYSQL) == 964);
> #endif
> 
> How should I fix this for x32? What is the preprocessor if clause and
> can I safely assume the size is 964?
The comment before this reads
/*
  this limited check is enough, if sizeof(MYSQL) changes, it changes
  everywhere
*/
so this looks like an ABI stability check,
validating not that MYSQL should be Some Specific Size,
but that it's The Size It Was Last Time.

IMO turn the first line into
  #if defined(__x86_64__) && !defined(__ILP32__)
since they did actually just want to check
if the size is the same they measured on amd64 and i386.

And if it were to change on either of these two,
it would change everywhere (apparently).

Best,


signature.asc
Description: PGP signature

LLVM toolchain on x32? (v2)

2020-05-22 Thread наб 
Hi!

I've been porting zfsutils-linux to x32, with moderate success[1]
so far, but had wanted to also test my patches on clang, what with the
potential for funny compiler-specific behaviour; thing is ‒ I haven't
been able to get my hands on an x32 clang build.

So far I've tried:
  * getting it from the archive, but a quick survey of packages.d.o
revealed that llvm-toolchain-9 FTBFS[2] on x32
(and has been that way since l-t-7);
  * building the package from source, which failed in the same exact way
as it did on x32-do-01[3] after running for a full day on
my underpowered machine; this proved to be another dead end,
as debugging an arcane cmake build failure with such unusable
iteration times is a bit out of reach for me;
  * building a clean upstream clang-10, which was partially successful,
in that it *built*, but failed cryptically on the link step
(I've re-tried this later in an x32 chroot on a different machine
 with 8G of RAM, and it OOMed nicely when it ran out of address space,
 not sure why it'd fail weirdly when the host has only 4G?);
it cross-linked from amd64 but never worked when executed,
segfaulting somewhere within the STL allocator during argument
parsing (cf. here[4] (warning: language));
  * similarly with clang-9, but it never linked.

And so, after three or four days, I've temporarily given up;
however I may've missed something obvious (though a look through the
x32-tagged bugs on b.d.o and a search of this mailing list for x32
haven't turned anything up), so here I am in hopes someone here
has tried this before and has arrived at some sort of conclusion,
be it that clang/llvm simply Does Not Work on x32, or otherwise?

Thanks in advance,
наб

[1]: https://github.com/openzfs/zfs/issues/844#issuecomment-629909893
[2]: https://buildd.debian.org/status/package.php?p=llvm-toolchain-9
[3]: 
https://buildd.debian.org/status/fetch.php?pkg=llvm-toolchain-9&arch=x32&ver=1%3A9.0.1-12&stamp=1586606773&raw=0
[4]: https://twitter.com/nabijaczleweli/status/1263176311356428288

(I have sent a different version of this message to the list yesterday,
 but it has not appeared in the archive since, so I'd assumed this means
 that the list software did not like it, for some reason. If, however,
 the list /has/ accepted it but the archive has not: sorry!)


signature.asc
Description: PGP signature