Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Draft
wants to merge 1 commit into
base: oi/hipster
Choose a base branch
from

Conversation

Bill-Sommerfeld
Copy link
Contributor

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

Copy link
Contributor

@mtelka mtelka left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@@ -650,6 +650,9 @@ FC.gcc.64 = $(GCC_ROOT)/bin/gfortran
GCC_FULL_VERSION = $(shell $(GCC_ROOT)/bin/gcc -dumpversion)
# Since gcc-9 the GNU triplet is x86_64-pc-solaris2.11 instead of i386-pc-solaris2.11
GCC_GNU_TRIPLET = $(shell $(GCC_ROOT)/bin/gcc -dumpmachine)
GCC_GNU_TRIPLET = $(shell $(GCC_ROOT)/bin/gcc -dumpmachine)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this needed twice?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Editing error. Will be fixed shortly.

@Bill-Sommerfeld
Copy link
Contributor Author

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.

…of ...-solaris2.11

Python would like to use this in installed pathnames.  Inspired by
omniosorg/omnios-build#3492
@mtelka
Copy link
Contributor

mtelka commented Feb 21, 2024

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
Copy link
Contributor Author

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
Copy link
Contributor

mtelka commented Feb 21, 2024

@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
Copy link
Contributor

mtelka commented Feb 21, 2024

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

@citrus-it
Copy link
Contributor

@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
Copy link
Contributor

mtelka commented Feb 21, 2024

@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
Copy link
Contributor

mtelka commented Feb 21, 2024

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
Copy link
Contributor

AndWac commented Feb 23, 2024

How shall we proceed?

@Bill-Sommerfeld Bill-Sommerfeld marked this pull request as draft February 23, 2024 17:12
@Bill-Sommerfeld
Copy link
Contributor Author

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

@AndWac
Copy link
Contributor

AndWac commented Mar 26, 2024

Any news?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants