Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #185643 > unrolled thread

Relocated Header Directories

Back to article view | Back to linux.debian.user

Contents

  Relocated Header Directories Dutch Ingraham <stoa@gmx.us> - 2017-08-21 15:40 +0200
    Re: Relocated Header Directories Kushal Kumaran <kushal@locationd.net> - 2017-08-21 16:10 +0200
      Re: Relocated Header Directories <tomas@tuxteam.de> - 2017-08-21 16:20 +0200
      Re: Relocated Header Directories Dutch Ingraham <stoa@gmx.us> - 2017-08-21 21:20 +0200
        Re: Relocated Header Directories <tomas@tuxteam.de> - 2017-08-21 22:00 +0200
          Re: Relocated Header Directories Dutch Ingraham <stoa@gmx.us> - 2017-08-21 22:10 +0200
        Re: Relocated Header Directories Christian Seiler <christian@iwakd.de> - 2017-08-22 07:10 +0200
          Re: Relocated Header Directories Mario Castelán Castro <marioxcc.MT@yandex.com> - 2017-08-22 16:50 +0200
            Re: Relocated Header Directories Christian Seiler <christian@iwakd.de> - 2017-08-22 17:00 +0200
              Re: Relocated Header Directories Mario Castelán Castro <marioxcc.MT@yandex.com> - 2017-08-22 17:00 +0200
    Re: Relocated Header Directories <tomas@tuxteam.de> - 2017-08-21 16:10 +0200
      Re: Relocated Header Directories Dutch Ingraham <stoa@gmx.us> - 2017-08-21 21:00 +0200

#185643 — Relocated Header Directories

Hi everyone -

It seems Debian has moved some header directories, like /usr/include/bits (and
sys, and asm, etc.) from /usr/include/ to, e.g., /usr/include/i386-linux-gnu/bits/
(arch-specific).

My first question is:  Why?

My second question is: How does this work?  There are no symlinks, yet a file
like /usr/include/signal.h, has the standard "#include <bits/sigset.h>", yet
that path does not exist with the change noted above.  So how is this file
included?

Any enlightenment is appreciated.

[toc] | [next] | [standalone]

#185644

Dutch Ingraham <stoa@gmx.us> writes:

> Hi everyone -
>
> It seems Debian has moved some header directories, like /usr/include/bits (and
> sys, and asm, etc.) from /usr/include/ to, e.g., /usr/include/i386-linux-gnu/bits/
> (arch-specific).
>
> My first question is:  Why?
>

This is so that headers that are architecture independent are separated
from headers with are architecture dependent.  Specifically, that they
are available at different paths.  This lets you install the headers
(and libraries) for different architectures simultaneously, which is
essential for debian's multiarch support.

> My second question is: How does this work?  There are no symlinks, yet a file
> like /usr/include/signal.h, has the standard "#include <bits/sigset.h>", yet
> that path does not exist with the change noted above.  So how is this file
> included?
>
> Any enlightenment is appreciated.

There are several directories configured for searching header files.
The command "gcc -xc -E -v - < /dev/null" will print those paths out.
For my system, the directories are:

 /usr/lib/gcc/x86_64-linux-gnu/6/include
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/6/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include

The list will be different for you because you appear to be running
i386.

-- 
regards,
kushal

[toc] | [prev] | [next] | [standalone]

#185646

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, Aug 21, 2017 at 07:06:17AM -0700, Kushal Kumaran wrote:

[...]

> There are several directories configured for searching header files.
> The command "gcc -xc -E -v - < /dev/null" will print those paths out.

HAH. Thanks. That's what was missing in my answer :-)

Cheers
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlma6lMACgkQBcgs9XrR2kYwhwCaAnYSF9BpvWmu04d2e6KyksRT
qEsAmgMcvSGyd/9DWVnYS96Qbk0Nz4s3
=Bder
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#185664

On 08/21/2017 09:06 AM, Kushal Kumaran wrote:
> Dutch Ingraham <stoa@gmx.us> writes:
>
>> Hi everyone -
>>
>> It seems Debian has moved some header directories, like /usr/include/bits (and
>> sys, and asm, etc.) from /usr/include/ to, e.g., /usr/include/i386-linux-gnu/bits/
>> (arch-specific).
>>
>> My first question is:  Why?
>>
> This is so that headers that are architecture independent are separated
> from headers with are architecture dependent.  Specifically, that they
> are available at different paths.  This lets you install the headers
> (and libraries) for different architectures simultaneously, which is
> essential for debian's multiarch support.
Thanks for the response.  Since both you and Tomas are saying the same
thing,
maybe I'm not understanding something.  For example, Fedora (and Gentoo,
etc. )
also installs glibc for both 32- and 64-bit on the same machine, but
they have not
relocated these header files.  So are you saying this was just Debian's
method
of solving the multi-arch issue, and other distributions solved in some
other way?
>
>> My second question is: How does this work?  There are no symlinks, yet a file
>> like /usr/include/signal.h, has the standard "#include <bits/sigset.h>", yet
>> that path does not exist with the change noted above.  So how is this file
>> included?
>>
>> Any enlightenment is appreciated.
> There are several directories configured for searching header files.
> The command "gcc -xc -E -v - < /dev/null" will print those paths out.
> For my system, the directories are:
>
>  /usr/lib/gcc/x86_64-linux-gnu/6/include
>  /usr/local/include
>  /usr/lib/gcc/x86_64-linux-gnu/6/include-fixed
>  /usr/include/x86_64-linux-gnu
>  /usr/include
>
> The list will be different for you because you appear to be running
> i386.
I'm not seeing some of these paths in vanilla gcc.  Does this mean
Debian patched
gcc as well to add the "Debian" path of /usr/include/x86_64-linux-gnu/ ?

Thanks again to you and Tomas for your responses.

[toc] | [prev] | [next] | [standalone]

#185666

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, Aug 21, 2017 at 02:12:05PM -0500, Dutch Ingraham wrote:
> On 08/21/2017 09:06 AM, Kushal Kumaran wrote:
> > Dutch Ingraham <stoa@gmx.us> writes:
> >
> >> Hi everyone -
> >>
> >> It seems Debian has moved some header directories, like /usr/include/bits (and
> >> sys, and asm, etc.) from /usr/include/ to, e.g., /usr/include/i386-linux-gnu/bits/
> >> (arch-specific).
> >>
> >> My first question is:  Why?
> >>
> > This is so that headers that are architecture independent are separated
> > from headers with are architecture dependent.  Specifically, that they
> > are available at different paths.  This lets you install the headers
> > (and libraries) for different architectures simultaneously, which is
> > essential for debian's multiarch support.
> Thanks for the response.  Since both you and Tomas are saying the same
> thing,
> maybe I'm not understanding something.  For example, Fedora (and Gentoo,
> etc. )
> also installs glibc for both 32- and 64-bit on the same machine, but
> they have not
> relocated these header files.  So are you saying this was just Debian's
> method
> of solving the multi-arch issue, and other distributions solved in some
> other way?

Exactly. In RH, the "default" is under /usr/lib, /usr/include, in Debian,
there's for every installed architecture /usr/*/$ARCH. This provides an
uniform structure, independent of the "default" arch. The change is a bit
more difficult, but the result is cleaner, as far as I understand.

This eases co-installing cross compilers for other architectures too,

> >> My second question is: How does this work?  There are no symlinks, yet a file
> >> like /usr/include/signal.h, has the standard "#include <bits/sigset.h>", yet
> >> that path does not exist with the change noted above.  So how is this file
> >> included?
> >>
> >> Any enlightenment is appreciated.
> > There are several directories configured for searching header files.
> > The command "gcc -xc -E -v - < /dev/null" will print those paths out.
> > For my system, the directories are:
> >
> >  /usr/lib/gcc/x86_64-linux-gnu/6/include
> >  /usr/local/include
> >  /usr/lib/gcc/x86_64-linux-gnu/6/include-fixed
> >  /usr/include/x86_64-linux-gnu
> >  /usr/include
> >
> > The list will be different for you because you appear to be running
> > i386.
> I'm not seeing some of these paths in vanilla gcc.  Does this mean
> Debian patched
> gcc as well to add the "Debian" path of /usr/include/x86_64-linux-gnu/ ?

I think it is a configuration option when building gcc and friends.

Cheers
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlmbOqYACgkQBcgs9XrR2kaLfgCfQFrgdJMoQILmwppzdtVNRWWx
/14An3zfOdkFainyDcyaCUws9Qfrsmmr
=IGz4
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#185667

On Mon, Aug 21, 2017 at 09:55:18PM +0200, tomas@tuxteam.de wrote:
> On Mon, Aug 21, 2017 at 02:12:05PM -0500, Dutch Ingraham wrote:
> > On 08/21/2017 09:06 AM, Kushal Kumaran wrote:
> > > Dutch Ingraham <stoa@gmx.us> writes:
> > >
> > >> Hi everyone -
> > >>
> > >> It seems Debian has moved some header directories, like /usr/include/bits (and
> > >> sys, and asm, etc.) from /usr/include/ to, e.g., /usr/include/i386-linux-gnu/bits/
> > >> (arch-specific).
> > >>
> > >> My first question is:  Why?
> > >>
> > > This is so that headers that are architecture independent are separated
> > > from headers with are architecture dependent.  Specifically, that they
> > > are available at different paths.  This lets you install the headers
> > > (and libraries) for different architectures simultaneously, which is
> > > essential for debian's multiarch support.
> > Thanks for the response.  Since both you and Tomas are saying the same
> > thing,
> > maybe I'm not understanding something.  For example, Fedora (and Gentoo,
> > etc. )
> > also installs glibc for both 32- and 64-bit on the same machine, but
> > they have not
> > relocated these header files.  So are you saying this was just Debian's
> > method
> > of solving the multi-arch issue, and other distributions solved in some
> > other way?
> 
> Exactly. In RH, the "default" is under /usr/lib, /usr/include, in Debian,
> there's for every installed architecture /usr/*/$ARCH. This provides an
> uniform structure, independent of the "default" arch. The change is a bit
> more difficult, but the result is cleaner, as far as I understand.

Excellent!  Thanks.

> 
> This eases co-installing cross compilers for other architectures too,
> 
> > >> My second question is: How does this work?  There are no symlinks, yet a file
> > >> like /usr/include/signal.h, has the standard "#include <bits/sigset.h>", yet
> > >> that path does not exist with the change noted above.  So how is this file
> > >> included?
> > >>
> > >> Any enlightenment is appreciated.
> > > There are several directories configured for searching header files.
> > > The command "gcc -xc -E -v - < /dev/null" will print those paths out.
> > > For my system, the directories are:
> > >
> > >  /usr/lib/gcc/x86_64-linux-gnu/6/include
> > >  /usr/local/include
> > >  /usr/lib/gcc/x86_64-linux-gnu/6/include-fixed
> > >  /usr/include/x86_64-linux-gnu
> > >  /usr/include
> > >
> > > The list will be different for you because you appear to be running
> > > i386.
> > I'm not seeing some of these paths in vanilla gcc.  Does this mean
> > Debian patched
> > gcc as well to add the "Debian" path of /usr/include/x86_64-linux-gnu/ ?
> 
> I think it is a configuration option when building gcc and friends.

OK - this answers my questions - thanks again!

> 
> Cheers
> -- tomás
> 

[toc] | [prev] | [next] | [standalone]

#185680

On 08/21/2017 09:12 PM, Dutch Ingraham wrote:
> For example, Fedora (and Gentoo,
> etc. )
> also installs glibc for both 32- and 64-bit on the same machine, but
> they have not
> relocated these header files.  So are you saying this was just Debian's
> method
> of solving the multi-arch issue, and other distributions solved in some
> other way?

Other distributions' support for multiple architectures is limited to
32bit and 64bit of the same fundamental CPU - for example 32bit and
64bit Intel/AMD CPUs. In these cases the header files that are
installed have traditionally been the same (just with #ifdef in them
for things that differ). What you can't do on those distributions is
install packages from foreign architectures on your local system;
for example you can't install a library for ARM on a system with
Intel/AMD CPUs on those systems.

Debian and Ubuntu decided to go a more thorough route here: instead
of just supporting the parallel installation of 32bit and 64bit
packages they decided to fully support the installation of packages
from arbitrary architectures. This means that instead of having
/usr/lib32 and /usr/lib64, you have /usr/lib/ARCH (where ARCH is
the triplet that specifies the architecture, for example
x86_64-linux-gnu or arm-linux-gnueabihf) and /usr/include/ARCH.
Libraries themselves should not be installed in /usr/lib directly
anymore (and most libraries have already moved to /usr/lib/ARCH,
but some packages haven't yet), while /usr/include (without ARCH)
does still have a purpose: for those headers where the architecture
doesn't play a role at all. Architecture-dependent headers should
go into /usr/include/ARCH instead though. The compiler and linker
are configured in such a way that they'll look in _both_ directories
by default (with a preference for the ARCH directory) when searching
for header files and libraries.

Now it might seem strange to do this, as you can't natively run an
ARM application on an Intel/AMD CPU (you'd need an emulator for
that, though there are such things for binaries alone, take a look
at qemu-user for that), but there are other benefits to this scheme:

 - You can use this scheme to cross-compile to other architectures.
   Want to create an arm64 Debian package? Install the build
   dependent libraries in their arm64 variants on your system and
   you can do so (if the package supports cross-compiling, which
   not all do).

 - Since there's no arbitrary restriction of 32bit and 64bit that
   may be installed in parallel, there are cases when there are
   two different 32bit architectures you may want to install in
   parallel. For example, there are two 32bit ARM variants
   supported by Debian at the moment: armel and armhf. Both use
   the ARM EABI binary interface, but armhf assumes that ARMv7
   floating point instructions are present in the CPU (along with
   the corresponding registers) while armel uses software emulation
   for floating point instructions (to support ARM CPUs that don't
   have them). Now say you have an ARM application (from a 3rd-
   party repository for example) that was compiled for armel, but
   your system is armhf. In Debian you can just install the
   libraries required for that program in their armel variant onto
   your otherwise armhf system and you can run that program.
   Whereas other distributions would put the libraries for both
   variants in /lib32 (or just /lib) in those cases, so you could
   not install the same libraries for both architectures - which
   also includes the system C library.

 - Code compiled for alternative C libraries (e.g. musl instead
   of glibc) can't be linked against code compiled for the standard
   C library. In Debian you have a trivial way of installing code
   that was compiled for both: alternative C libraries use a
   different architecture specifier, in the case of musl for
   example x86_64-linux-musl (vs. x86_64-linux-gnu) and you can
   also install libraries compiled for both variants in parallel.

The only disadvantage in my eyes seems to be that Debian and its
derivatives (Ubuntu, etc.) are the only ones that do this, and all
the other distributions seem to favor the /lib32 vs /lib64 variant
to do this.

Regards,
Christian

[toc] | [prev] | [next] | [standalone]

#185712

[Multipart message — attachments visible in raw view] — view raw

Thanks everybody for the explanation (note that I did not make the
original question). I had been wondering about why some of my “.so” were
in “/usr/lib/x86_64-linux-gnu” instead of just “/usr/lib”.

What about the ELF shared objects that *are* under “/usr/lib”? Are these
programs that do not have support for multi-arch?

-- 
Do not eat animals, respect them as you respect people.
https://duckduckgo.com/?q=how+to+(become+OR+eat)+vegan

[toc] | [prev] | [next] | [standalone]

#185713

Am 2017-08-22 16:47, schrieb Mario Castelán Castro:
> What about the ELF shared objects that *are* under “/usr/lib”? Are 
> these
> programs that do not have support for multi-arch?

Not programs, but packages, yes. Not all library packages in Debian
have been updated to use the Multi-Arch scheme yet (in some cases
other aspects of the package may make this difficult, even if it
is easy to put the .so file into the new location), though the
number of packages that are still in /usr/lib directly has decreased
with every Debian release since Wheezy (the first with Multi-Arch).

Regards,
Christian

[toc] | [prev] | [next] | [standalone]

#185714

[Multipart message — attachments visible in raw view] — view raw

On 22/08/17 09:57, Christian Seiler wrote:
> Not programs, but packages, yes. Not all library packages in Debian
> have been updated to use the Multi-Arch scheme yet (in some cases
> other aspects of the package may make this difficult, even if it
> is easy to put the .so file into the new location), though the
> number of packages that are still in /usr/lib directly has decreased
> with every Debian release since Wheezy (the first with Multi-Arch).

Thanks for the information.

-- 
Do not eat animals, respect them as you respect people.
https://duckduckgo.com/?q=how+to+(become+OR+eat)+vegan

[toc] | [prev] | [next] | [standalone]

#185645

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, Aug 21, 2017 at 08:37:14AM -0500, Dutch Ingraham wrote:
> Hi everyone -
> 
> It seems Debian has moved some header directories, like /usr/include/bits (and
> sys, and asm, etc.) from /usr/include/ to, e.g., /usr/include/i386-linux-gnu/bits/
> (arch-specific).
> 
> My first question is:  Why?

Multi-arch. These days you can have libraries (and the corresponding
headers) for several architectures co-installed on your system.

Start here:

  https://wiki.debian.org/Multiarch

> My second question is: How does this work?  There are no symlinks, yet a file
> like /usr/include/signal.h, has the standard "#include <bits/sigset.h>", yet
> that path does not exist with the change noted above.  So how is this file
> included?

Your compiler should know which architecture is relevant and set the default
include directories (can't look it up now to be sure, sorry).

Cheers
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlma5+cACgkQBcgs9XrR2kZbkgCeMXS69kgQkQAkOlMgIyJgPt8i
YloAnREMU31YSlj/GrO3/Yv/u/bAQ1lP
=DdkG
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#185662

On 08/21/2017 09:02 AM, tomas@tuxteam.de wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Mon, Aug 21, 2017 at 08:37:14AM -0500, Dutch Ingraham wrote:
>> Hi everyone -
>>
>> It seems Debian has moved some header directories, like /usr/include/bits (and
>> sys, and asm, etc.) from /usr/include/ to, e.g., /usr/include/i386-linux-gnu/bits/
>> (arch-specific).
>>
>> My first question is:  Why?
> Multi-arch. These days you can have libraries (and the corresponding
> headers) for several architectures co-installed on your system.
>
> Start here:
>
>   https://wiki.debian.org/Multiarch
Thanks for your response and the link.  I'll respond more fully to the other
reply in this thread since they are both so similar.
>
>> My second question is: How does this work?  There are no symlinks, yet a file
>> like /usr/include/signal.h, has the standard "#include <bits/sigset.h>", yet
>> that path does not exist with the change noted above.  So how is this file
>> included?
> Your compiler should know which architecture is relevant and set the default
> include directories (can't look it up now to be sure, sorry).
>
> Cheers
> - -- tomás
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
>
> iEYEARECAAYFAlma5+cACgkQBcgs9XrR2kZbkgCeMXS69kgQkQAkOlMgIyJgPt8i
> YloAnREMU31YSlj/GrO3/Yv/u/bAQ1lP
> =DdkG
> -----END PGP SIGNATURE-----
>

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web