Re: Is there a chance to phase out `/lib64` directory?

[Tom Stellard]

On 6/30/23 07:45, Tulio Magno Quites Machado Filho wrote:

Kevin Kofler via devel  writes:


Carlos O'Donell wrote:

And assembling those sysroots is not straight forward.


The easiest way is to unpack a live image. If you are targeting an Arch-
based or similar distro, you will probably get away with just unpacking the
image, because it installs development files by default. But if you are
targeting Fedora or a similar distro, you will probably want to compose a
custom live image with a bunch of -devel packages. (You can also try to
install packages within the sysroot, but if you are cross-compiling to a
different architecture, that is not straightforward, you either need to use
host tools and point them to the sysroot, or to use CPU emulation to run the
tools within the sysroot, or as a last resort to unpack package contents
manually.)


Containers might also help, e.g.:

 podman run -it --rm \
   --mount=type=image,source=fedora:38-ppc64le,destination=/sysroot \
   fedora:38-x86_64 bash

The user still needs to compose both images with the required packages,
but it might be easier to keep them up-to-date.



I have been experimenting with creating sysroots with containers, and I
did something similar to this:

https://github.com/tstellar/fedora-cross-toolchain/blob/main/Dockerfile.cross

-Tom
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Is there a chance to phase out `/lib64` directory?

[Tulio Magno Quites Machado Filho]

Kevin Kofler via devel  writes:

> Carlos O'Donell wrote:
>> And assembling those sysroots is not straight forward.
>
> The easiest way is to unpack a live image. If you are targeting an Arch-
> based or similar distro, you will probably get away with just unpacking the 
> image, because it installs development files by default. But if you are 
> targeting Fedora or a similar distro, you will probably want to compose a 
> custom live image with a bunch of -devel packages. (You can also try to 
> install packages within the sysroot, but if you are cross-compiling to a 
> different architecture, that is not straightforward, you either need to use 
> host tools and point them to the sysroot, or to use CPU emulation to run the 
> tools within the sysroot, or as a last resort to unpack package contents 
> manually.)

Containers might also help, e.g.:

podman run -it --rm \
  --mount=type=image,source=fedora:38-ppc64le,destination=/sysroot \
  fedora:38-x86_64 bash

The user still needs to compose both images with the required packages,
but it might be easier to keep them up-to-date.

-- 
Tulio Magno
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Is there a chance to phase out `/lib64` directory?

[Kevin Kofler via devel]

Carlos O'Donell wrote:
> And assembling those sysroots is not straight forward.

The easiest way is to unpack a live image. If you are targeting an Arch-
based or similar distro, you will probably get away with just unpacking the 
image, because it installs development files by default. But if you are 
targeting Fedora or a similar distro, you will probably want to compose a 
custom live image with a bunch of -devel packages. (You can also try to 
install packages within the sysroot, but if you are cross-compiling to a 
different architecture, that is not straightforward, you either need to use 
host tools and point them to the sysroot, or to use CPU emulation to run the 
tools within the sysroot, or as a last resort to unpack package contents 
manually.)

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Is there a chance to phase out `/lib64` directory?

[Carlos O'Donell]

On 6/27/23 20:21, Kevin Kofler via devel wrote:
> Practical cross-compilation to a completely different architecture needs 
> sysroots anyway. That way, one can also easily target a different 
> distribution on a different (or even the same) architecture, not just Fedora 
> on a different architecture.

+100

And assembling those sysroots is not straight forward.

-- 
Cheers,
Carlos.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Is there a chance to phase out `/lib64` directory?

[David Abdurachmanov]

On Wed, Jun 28, 2023 at 3:22 AM Kevin Kofler via devel
 wrote:
>
> Kalev Lember wrote:
> > I would like to have a layout similar to what Debian is doing, so that
> > shared libraries would go in /usr/lib/x86_64-redhat-linux/ and /usr/lib64
> > would be a legacy symlink pointing to it.
>
> That layout is NOT compliant with the FHS.
>
> Which is particularly hilarious as Debian has long refused to use
> /usr/libexec (despite GNU having had it for ages, and Debian's refusal has
> in turn lead several upstreams to not or poorly support it and abuse
> /usr/lib or other directories for its purpose instead) because it was
> purportedly against the FHS (it seems they have never noticed that the
> clause that allows lib64 and lib32 does not actually require the suffix to
> be a number, "exec" is a perfectly fine suffix, so libexec is just another
> lib64/lib32-type directory), but was very fast to add an exception for this
> new entirely non-standard layout. (The FHS requires the arch-specific libdir
> variants to be suffixed sibling directories of lib, NOT subdirectories.)

In RISCV lands things look like this:

[..]
#define STARTFILE_PREFIX_SPEC \
   "/lib" XLEN_SPEC "/" ABI_SPEC "/ "\
   "/usr/lib" XLEN_SPEC "/" ABI_SPEC "/ "\
[..]

Linker default search paths:

[..]
SEARCH_DIR("=/usr/riscv64-redhat-linux/lib64/lp64d")
SEARCH_DIR("=/usr/riscv64-redhat-linux/lib64")
SEARCH_DIR("=/usr/riscv64-redhat-linux/lib6464/lp64d")
SEARCH_DIR("=/usr/lib6464/lp64d")
SEARCH_DIR("=/usr/lib64")
SEARCH_DIR("=/usr/local/lib64/lp64d")
SEARCH_DIR("=/usr/local/lib64")
SEARCH_DIR("=/lib64/lp64d")
SEARCH_DIR("=/lib64")
SEARCH_DIR("=/usr/lib64/lp64d")
SEARCH_DIR("=/usr/riscv64-redhat-linux/lib")
SEARCH_DIR("=/usr/local/lib")
SEARCH_DIR("=/lib")
SEARCH_DIR("=/usr/lib")
[..]

By default the expectation is to find libraries under ABI
subdirectory, e.g. /usr/lib64/lp64d

In Fedora/RISCV /usr/lib64/lp64d is a symlink back to /usr/lib64

From glibc:

[..]
This program interpreter self-identifies as: /lib/ld-linux-riscv64-lp64d.so.1

Shared library search path:
  (libraries located via /etc/ld.so.cache)
  /lib64/lp64d (system search path)
  /usr/lib64/lp64d (system search path)
[..]

david

>
> > That kind of layout would make it much easier to do cross compilation
> > because you could just take the whole /usr/lib/another-host-triplet/
> > directory from another architecture without it interfering with the host
> > libraries and use it for cross compilation purposes.
>
> Practical cross-compilation to a completely different architecture needs
> sysroots anyway. That way, one can also easily target a different
> distribution on a different (or even the same) architecture, not just Fedora
> on a different architecture.
>
> Kevin Kofler
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Is there a chance to phase out `/lib64` directory?

[Neal Gompa]

On Tue, Jun 27, 2023 at 8:21 PM Kevin Kofler via devel
 wrote:
>
> Kalev Lember wrote:
> > I would like to have a layout similar to what Debian is doing, so that
> > shared libraries would go in /usr/lib/x86_64-redhat-linux/ and /usr/lib64
> > would be a legacy symlink pointing to it.
>
> That layout is NOT compliant with the FHS.
>
> Which is particularly hilarious as Debian has long refused to use
> /usr/libexec (despite GNU having had it for ages, and Debian's refusal has
> in turn lead several upstreams to not or poorly support it and abuse
> /usr/lib or other directories for its purpose instead) because it was
> purportedly against the FHS (it seems they have never noticed that the
> clause that allows lib64 and lib32 does not actually require the suffix to
> be a number, "exec" is a perfectly fine suffix, so libexec is just another
> lib64/lib32-type directory), but was very fast to add an exception for this
> new entirely non-standard layout. (The FHS requires the arch-specific libdir
> variants to be suffixed sibling directories of lib, NOT subdirectories.)
>

Debian adopted /usr/libexec in 2018:
https://salsa.debian.org/dbnpolicy/policy/-/commit/5205d0a50465cf422f1040d9395d5ea83dbfde5f




-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Is there a chance to phase out `/lib64` directory?

[Kevin Kofler via devel]

Kalev Lember wrote:
> I would like to have a layout similar to what Debian is doing, so that
> shared libraries would go in /usr/lib/x86_64-redhat-linux/ and /usr/lib64
> would be a legacy symlink pointing to it.

That layout is NOT compliant with the FHS.

Which is particularly hilarious as Debian has long refused to use 
/usr/libexec (despite GNU having had it for ages, and Debian's refusal has 
in turn lead several upstreams to not or poorly support it and abuse 
/usr/lib or other directories for its purpose instead) because it was 
purportedly against the FHS (it seems they have never noticed that the 
clause that allows lib64 and lib32 does not actually require the suffix to 
be a number, "exec" is a perfectly fine suffix, so libexec is just another 
lib64/lib32-type directory), but was very fast to add an exception for this 
new entirely non-standard layout. (The FHS requires the arch-specific libdir 
variants to be suffixed sibling directories of lib, NOT subdirectories.)

> That kind of layout would make it much easier to do cross compilation
> because you could just take the whole /usr/lib/another-host-triplet/
> directory from another architecture without it interfering with the host
> libraries and use it for cross compilation purposes.

Practical cross-compilation to a completely different architecture needs 
sysroots anyway. That way, one can also easily target a different 
distribution on a different (or even the same) architecture, not just Fedora 
on a different architecture.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Is there a chance to phase out `/lib64` directory?

[Florian Weimer]

* Kalev Lember:

> I would like to have a layout similar to what Debian is doing, so that
> shared libraries would go in /usr/lib/x86_64-redhat-linux/ and
> /usr/lib64 would be a legacy symlink pointing to it.

The Debian layout is a bit misdesigned in that it's not possible to
discover the multi-arch subdirectories under /usr/lib without
maintaining an explicit list.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Is there a chance to phase out `/lib64` directory?

[Panu Matilainen]

On 6/27/23 15:04, Neal Gompa wrote:

On Tue, Jun 27, 2023 at 6:37 AM Panu Matilainen  wrote:


On 6/27/23 13:30, Kalev Lember wrote:

On Tue, Jun 27, 2023 at 11:02 AM Vít Ondruch mailto:vondr...@redhat.com>> wrote:

 I don't think that GCC is always the best example to follow.

 Nevertheless, wouldn't it be worth of phasing out the /lib64? I don't
 know what is the history behind, but I don't think this layout is
 conceptual.


I would like to have a layout similar to what Debian is doing, so that
shared libraries would go in /usr/lib/x86_64-redhat-linux/ and
/usr/lib64 would be a legacy symlink pointing to it.


Likewise.


That kind of layout would make it much easier to do cross compilation
because you could just take the whole /usr/lib/another-host-triplet/
directory from another architecture without it interfering with the host
libraries and use it for cross compilation purposes.


Yes, that /lib/ arrangement allows for all manner of things that
just aren't possible with /lib64.

https://wiki.debian.org/Multiarch/TheCaseForMultiarch is a good read.


It would be a lot of work transitioning to a new layout though.


That it is.



I'd rather move toward sysroot multiarch instead, which would expand
that benefit beyond libraries to basically everything.

But to do anything, RPM's handling of architectures needs to change.
Years ago, I had attempted to fix some of this upstream, but it didn't
make it in.

https://github.com/rpm-software-management/rpm/pull/1038


It didn't go in, but not because we disagreed with the concept as such.

Note that support for multi-arch in rpm is now on the roadmap for 4.20 
(https://rpm.org/roadmap)


- Panu -
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Is there a chance to phase out `/lib64` directory?

[Neal Gompa]

On Tue, Jun 27, 2023 at 6:37 AM Panu Matilainen  wrote:
>
> On 6/27/23 13:30, Kalev Lember wrote:
> > On Tue, Jun 27, 2023 at 11:02 AM Vít Ondruch  > > wrote:
> >
> > I don't think that GCC is always the best example to follow.
> >
> > Nevertheless, wouldn't it be worth of phasing out the /lib64? I don't
> > know what is the history behind, but I don't think this layout is
> > conceptual.
> >
> >
> > I would like to have a layout similar to what Debian is doing, so that
> > shared libraries would go in /usr/lib/x86_64-redhat-linux/ and
> > /usr/lib64 would be a legacy symlink pointing to it.
>
> Likewise.
>
> > That kind of layout would make it much easier to do cross compilation
> > because you could just take the whole /usr/lib/another-host-triplet/
> > directory from another architecture without it interfering with the host
> > libraries and use it for cross compilation purposes.
>
> Yes, that /lib/ arrangement allows for all manner of things that
> just aren't possible with /lib64.
>
> https://wiki.debian.org/Multiarch/TheCaseForMultiarch is a good read.
>
> > It would be a lot of work transitioning to a new layout though.
>
> That it is.
>

I'd rather move toward sysroot multiarch instead, which would expand
that benefit beyond libraries to basically everything.

But to do anything, RPM's handling of architectures needs to change.
Years ago, I had attempted to fix some of this upstream, but it didn't
make it in.

https://github.com/rpm-software-management/rpm/pull/1038



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Is there a chance to phase out `/lib64` directory?

[Vitaly Zaitsev via devel]

On 27/06/2023 12:30, Kalev Lember wrote:
I would like to have a layout similar to what Debian is doing, so that 
shared libraries would go in /usr/lib/x86_64-redhat-linux/ and 
/usr/lib64 would be a legacy symlink pointing to it.


Debian isn't a good example here. I've fixed over a hundred projects by 
switching from hard-coded lib/ to GNUInstallDirs.


--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Is there a chance to phase out `/lib64` directory?

[Panu Matilainen]

On 6/27/23 13:30, Kalev Lember wrote:
On Tue, Jun 27, 2023 at 11:02 AM Vít Ondruch > wrote:


I don't think that GCC is always the best example to follow.

Nevertheless, wouldn't it be worth of phasing out the /lib64? I don't
know what is the history behind, but I don't think this layout is
conceptual.


I would like to have a layout similar to what Debian is doing, so that 
shared libraries would go in /usr/lib/x86_64-redhat-linux/ and 
/usr/lib64 would be a legacy symlink pointing to it.


Likewise.

That kind of layout would make it much easier to do cross compilation 
because you could just take the whole /usr/lib/another-host-triplet/ 
directory from another architecture without it interfering with the host 
libraries and use it for cross compilation purposes.


Yes, that /lib/ arrangement allows for all manner of things that 
just aren't possible with /lib64.


https://wiki.debian.org/Multiarch/TheCaseForMultiarch is a good read.


It would be a lot of work transitioning to a new layout though.


That it is.

- Panu -
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Is there a chance to phase out `/lib64` directory?

[Vít Ondruch]

Dne 27. 06. 23 v 11:59 Nico Kadel-Garcia napsal(a):

On Tue, Jun 27, 2023 at 5:02 AM Vít Ondruch  wrote:

I don't think that GCC is always the best example to follow.

Nevertheless, wouldn't it be worth of phasing out the /lib64? I don't
know what is the history behind, but I don't think this layout is
conceptual.


Vít

Until, and unless, 32-bit compatibility on 64-bit hosts gets discarded



I don't think this really is precondition



and the File System Hierarchy rewritten, probably not.



We can drive the change instead waiting for it.


Vít



OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Is there a chance to phase out `/lib64` directory?

[Vít Ondruch]

Dne 27. 06. 23 v 12:30 Kalev Lember napsal(a):

On Tue, Jun 27, 2023 at 11:02 AM Vít Ondruch  wrote:

I don't think that GCC is always the best example to follow.

Nevertheless, wouldn't it be worth of phasing out the /lib64? I don't
know what is the history behind, but I don't think this layout is
conceptual.


I would like to have a layout similar to what Debian is doing, so that 
shared libraries would go in /usr/lib/x86_64-redhat-linux/ and 
/usr/lib64 would be a legacy symlink pointing to it.



Yep, something like this was on my mind. It would probably not directly 
solve the original issue which triggered the question, but afterall, it 
would be closer to what upstreams do.





That kind of layout would make it much easier to do cross compilation 
because you could just take the whole /usr/lib/another-host-triplet/ 
directory from another architecture without it interfering with the 
host libraries and use it for cross compilation purposes.


It would be a lot of work transitioning to a new layout though.



Indeed.


Vít




OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Is there a chance to phase out `/lib64` directory?

[Kalev Lember]

On Tue, Jun 27, 2023 at 11:02 AM Vít Ondruch  wrote:

> I don't think that GCC is always the best example to follow.
>
> Nevertheless, wouldn't it be worth of phasing out the /lib64? I don't
> know what is the history behind, but I don't think this layout is
> conceptual.
>

I would like to have a layout similar to what Debian is doing, so that
shared libraries would go in /usr/lib/x86_64-redhat-linux/ and /usr/lib64
would be a legacy symlink pointing to it.

That kind of layout would make it much easier to do cross compilation
because you could just take the whole /usr/lib/another-host-triplet/
directory from another architecture without it interfering with the host
libraries and use it for cross compilation purposes.

It would be a lot of work transitioning to a new layout though.

-- 
Kalev
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Is there a chance to phase out `/lib64` directory?

[Nico Kadel-Garcia]

On Tue, Jun 27, 2023 at 5:02 AM Vít Ondruch  wrote:
>
> I don't think that GCC is always the best example to follow.
>
> Nevertheless, wouldn't it be worth of phasing out the /lib64? I don't
> know what is the history behind, but I don't think this layout is
> conceptual.
>
>
> Vít

Until, and unless, 32-bit compatibility on 64-bit hosts gets discarded
and the File System Hierarchy rewritten, probably not.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Is there a chance to phase out `/lib64` directory?

[Vít Ondruch]

I don't think that GCC is always the best example to follow.

Nevertheless, wouldn't it be worth of phasing out the /lib64? I don't 
know what is the history behind, but I don't think this layout is 
conceptual.



Vít


Dne 27. 06. 23 v 3:19 Tom Stellard napsal(a):

On 6/26/23 10:02, Fabio Valentini wrote:
On Mon, Jun 26, 2023 at 6:13 PM Aoife Moloney  
wrote:


https://fedoraproject.org/wiki/Changes/LLVM-17

This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.

== Summary ==
Update all llvm sub-projects in Fedora Linux to version 17.

== Owner ==
* Name: [[User:tstellar| Tom Stellard]]

* Email: 


== Detailed Description ==
All llvm sub-projects in Fedora will be updated to version 17, and
there will be a soname version change for the llvm libraries.
Compatibility packages clang16, llvm16, and lld16 will be added to
ensure that packages that currently depend on clang and llvm version
16 libraries will continue to work.

Other notable changes:

* The Clang Resource Directory will be moved from /usr/lib64/clang/17/
to /usr/lib/clang/17/ this is the location of clang's internal headers
and runtime libraries like libomp and compiler-rt.  Package owners of
packages that read or write this directory will need to update their
packages when rebuilding against/with LLVM 17.  The
%clang_resource_dir helper macro can be used to make this transition
smoother, and packages are encouraged to update to use this macro even
before the LLVM 17 update.

* Along with the Clang Resource Directory change, compiler-rt will now
install its libraries into /usr/lib/clang/17/lib/$TRIPLE/ instead of
/usr/lib64/clang/17/lib/


Isn't installing architecture-specific binaries into /usr/lib a bit
broken (and against Packaging Guidelines)?
If this is intended to make it possible to have parallel installable
toolchains for different $TRIPLEs, it might be a better idea to
install files for the "host triple" in the current location, and only
add symlinks for thise in the "new" location.



We're trying to be more consistent with gcc and also upstream clang.
gcc installs some of these same libraries and some equivalent ones
into /usr/lib as well (/usr/lib/gcc/$TRIPLE/$MAJOR_VERSON).

This also fixes problems we have with clang being unable to find 32-bit
libraries.  clang expects 32-bit and 64-bit libraries to be within the
same Clang Resource Directory, so it searches for the 32-bit libraries
in /usr/lib64/clang/17/lib, and they are installed in 
/usr/lib/clang/17/lib.


We do currently have symlinks for the 32-bit libraries installed in 
/usr/lib64/clang/17/lib,

but this is not very robust and still has some bugs.  Moving the Resource
Directory to match upstream is the most simple solution for us and it 
should

help prevent issues in the future too.

-Tom





Fabio
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/

List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/

List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue