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

[glibc]: Specify locale-archive search path #1486

Closed
wants to merge 1 commit into from

Conversation

mga-sc
Copy link
Contributor

@mga-sc mga-sc commented Jun 5, 2024

According to glibc documentation
locale-archive which is generally installed as /usr/lib/locale/locale-archive

For new glibc versions (2.38+) you can face with problem: locale-archive are searched for in /usr/lib64/lp64d/locale folder

To reproduce: compile test.c with call to setlocale(LC_ALL, "") and run strace

Finally, to search for locale-archive in default folder we need to extra specify libc_cv_complocaledir in order to overwrite Makeconfig:complocaledir=${libdir}/locale.

According to glibc documentation
"locale-archive which is generally installed as /usr/lib/locale/locale-archive"

For new glibc versions (2.38+) you can face with problem:
locale-archive are searched for in /usr/lib64/lp64d/locale folder

To reproduce: compile test.c with call to setlocale(LC_ALL, "") and run strace

Finally, to search for locale-archive in default folder
we need to extra specify libc_cv_complocaledir in order to
overwrite Makeconfig:complocaledir=${libdir}/locale.
@cmuellner
Copy link
Collaborator

glibc does libc_cv_complocaledir='${exec_prefix}/lib/locale' in sysdeps/unix/sysv/linux/riscv/configure (since the initial port).
In the riscv-gnu-toolchain repo, we don't set exec_prefix.
I could not find any change related to exec_prefix in glibc in the git log of recent years.
So, I don't see this being introduced with glibc 2.38 (let me know if I am missing something).

My understanding is that this is an issue in multilib toolchain builds.
In general, the set of libraries for each multilib flavor could be different.
So, there might be a need to have different locale data for different multilib flavors.

It might be, that in most cases the binary locale data is equal for all multilib flavors.
But, in general this is not the case.

Which leads to the question: why is /usr/lib64/lp64d/locale not a suitable locale directory?

@mga-sc
Copy link
Contributor Author

mga-sc commented Jun 5, 2024

I don't see this being introduced with glibc 2.38

Yes, it is my fault, this change doesn't correspond to glibc version.

why is /usr/lib64/lp64d/locale not a suitable locale directory?

Because we build standart gnu-toolchain and should correspond to official documentation (/usr/lib/locale).
Also, locale-archive are used during running binary only (not in compiling process). So, there is no need to generate locale-archive files for every configuration - just one for specific computer.

@cmuellner
Copy link
Collaborator

why is /usr/lib64/lp64d/locale not a suitable locale directory?

Because we build standart gnu-toolchain and should correspond to official documentation (/usr/lib/locale).
Also, locale-archive are used during running binary only (not in compiling process). So, there is no need to generate
locale-archive files for every configuration - just one for specific computer.

But on a multilib system, you have multiple bin directories.
There is no requirement that the binaries for different multilib-flavors need to be from same sources or require the same locale data files.

The default in glibc for libc_cv_complocaledir was not accidental but intentionally chosen.
All other architectures in glibc do the same, so this is not even a RISC-V specific thing.

I see two possible solutions for you:

  • if you don't need a multilib toolchain, then build for one multilib target (then exec_prefix and prefix will be the same)
  • create a PR that introduces GLIBC_EXTRA_CONFIGURE_FLAGS (similar like GCC_EXTRA_CONFIGURE_FLAGS) and do the rest in your build script

@cmuellner
Copy link
Collaborator

  • create a PR that introduces GLIBC_EXTRA_CONFIGURE_FLAGS (similar like GCC_EXTRA_CONFIGURE_FLAGS) and do the rest in your build script

I just realized that we already have that with GLIBC_TARGET_FLAGS_EXTRA (you are probably aware of that).

So the following should work (untested): GLIBC_TARGET_FLAGS_EXTRA="libc_cv_complocaledir=/usr/lib/locale" ./configure ....

@mga-sc
Copy link
Contributor Author

mga-sc commented Jun 6, 2024

@cmuellner , yes, I'm aware of GLIBC_TARGET_FLAGS_EXTRA and already defined it for my case.

My intension was to build locale-archive according to default location that was described in INSTALL manual.
If you are confident that default folder for RISC-V should be lib{bit}/{abi}, so, there is no need for this patch.

@TommyMurphyTM1234
Copy link
Collaborator

If you are confident that default folder for RISC-V should be lib{bit}/{abi}, so, there is no need for this patch.

Does this issue perhaps impinge on this discussion?

@cmuellner
Copy link
Collaborator

@cmuellner , yes, I'm aware of GLIBC_TARGET_FLAGS_EXTRA and already defined it for my case.

My intension was to build locale-archive according to default location that was described in INSTALL manual. If you are confident that default folder for RISC-V should be lib{bit}/{abi}, so, there is no need for this patch.

The default location is correct, but only for default (i.e., non-multilib) toolchains.
If a common locale directory (for all multilib-flavors) would be the right solution, this would have to be changed in the glibc repo.

I'll close this PR. Anyway, thanks for taking the time and preparing the PR.

@cmuellner cmuellner closed this Jun 6, 2024
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.

3 participants