Add GCC_GNU_SHORT_TRIPLET for packages that use -solaris2 instead of -solaris2.11

[Bill-Sommerfeld]

Python would like to use this in installed pathnames. Inspired by omniosorg/omnios-build#3492

[mtelka]

Isn't this (-solaris2 instead of -solaris2.11) just a bug? For example here? If not, could you please share a pointer where this issue is visible? I'm asking because I failed to find -solaris2 (without .11) in installed path names.

Thank you.

[mtelka]

Why is this needed twice?

[Bill-Sommerfeld]

Editing error. Will be fixed shortly.

[Bill-Sommerfeld]

Isn't this (-solaris2 instead of -solaris2.11) just a bug? For example here? If not, could you please share a pointer where this issue is visible? I'm asking because I failed to find -solaris2 (without .11) in installed path names.

Thank you.

Python needs a variant triple without a . in it.

See 16a665b - we've evidently been building python without a proper target triple.
This is from @citrus-it's work for omnios, cross-compiling for ARM.

[mtelka]

Isn't this (-solaris2 instead of -solaris2.11) just a bug? For example here? If not, could you please share a pointer where this issue is visible? I'm asking because I failed to find -solaris2 (without .11) in installed path names.
Thank you.

Python needs a variant triple without a . in it.

Why it needs a variant triple?

See 16a665b - we've evidently been building python without a proper target triple. This is from @citrus-it's work for omnios, cross-compiling for ARM.

I'm not sure about this. So far Python dynamic libraries were named according to PEP 3149. This change seems to violate the PEP.

[Bill-Sommerfeld]

Isn't this (-solaris2 instead of -solaris2.11) just a bug? For example here? If not, could you please share a pointer where this issue is visible? I'm asking because I failed to find -solaris2 (without .11) in installed path names.
Thank you.

Python needs a variant triple without a . in it.

Why it needs a variant triple?

See 16a665b - we've evidently been building python without a proper target triple. This is from @citrus-it's work for omnios, cross-compiling for ARM.

I'm not sure about this. So far Python dynamic libraries were named according to PEP 3149. This change seems to violate the PEP.

surveying a few systems available to me, I see quite a bit of variation

• macos: ./lib-dynload/_socket.cpython-39-darwin.so (just the OS but I believe they have fat binaries..)
• debian: ./lib-dynload/mmap.cpython-311-x86_64-linux-gnu.so (much like what I'm proposing)
• freebsd: ./lib-dynload/_socket.cpython-39.so (what happens when you don't define a triple).

@citrus-it I assume that cross-building python packages is the prime motivation for this?

[mtelka]

@citrus-it I assume that cross-building python packages is the prime motivation for this?

If the cross-building is a motivation for this, does it mean that we will rename all dynamic libraries on the whole system to contain the triplet? If not, then why Python libs yes, but others not? If yes, then: really?

[mtelka]

And also: Why the cross-building requires the triplet in the file name?

[citrus-it]

@citrus-it I assume that cross-building python packages is the prime motivation for this?

I suppose that's a fair summary of the situation in that, with python 3.12, one cannot cross compile (without hacking Makefiles) unless the triplet is known. There is a cross-compiled OmniOS aarch64 distribution, and that's what showed this up.

Here's the best summary of the Python change, introduced in 3.5 that I have found, and it explicitly notes that On all other platforms, extension module filenames are the same as they were with Python 3.4. - I don't seem to be able to find a corresponding PEP reference.

In OmniOS, we are most likely going to move to including the triple in extension filenames, it is probably not necessary to make this change in OpenIndiana.

[mtelka]

@citrus-it I assume that cross-building python packages is the prime motivation for this?

I suppose that's a fair summary of the situation in that, with python 3.12, one cannot cross compile (without hacking Makefiles) unless the triplet is known. There is a cross-compiled OmniOS aarch64 distribution, and that's what showed this up.

I'm sorry, but I'm trying to understand the situation so please bear with me...

Known triplet and triplet incorporated into file names is different thing, isn't?
While looking at other OI packages I see filenames (or paths in general) with triplet in gcc, emacs, binutils, and ruby packages only.

Here's the best summary of the Python change, introduced in 3.5 that I have found, and it explicitly notes that On all other platforms, extension module filenames are the same as they were with Python 3.4. - I don't seem to be able to find a corresponding PEP reference.

Thanks for the pointer. The whatsnew document does not say anything about the motivation, so it is unclear how it is related to cross-compilation.

BTW, It looks like the related PEP is PEP 720, but it is fairly new and still draft.

In OmniOS, we are most likely going to move to including the triple in extension filenames, it is probably not necessary to make this change in OpenIndiana.

I'm not against it if it proves useful and/or necessary, but so far I do not see any pro, only cons.

[mtelka]

Known triplet and triplet incorporated into file names is different thing, isn't? While looking at other OI packages I see filenames (or paths in general) with triplet in gcc, emacs, binutils, and ruby packages only.

While actually ruby uses pair only instead of triplet.

[AndWac]

How shall we proceed?

[Bill-Sommerfeld]

currently on a brief vacation, will respond with a proposal next week.

[AndWac]

Any news?