Re: multiarch vs. multilib

Simon McVittie left as an exercise for the reader: > Sorry, I spend a lot of my work time immersed in this sort of thing and > how it differs between distributions, so I tend to forget that most > developers are able to stick to one distro and don't need to know this! no offense at all, and

Re: multiarch vs. multilib

On Thu, 08 Jun 2023 at 19:22:02 -0400, nick black wrote: > Simon McVittie left as an exercise for the reader: > > Debian-style multiarch or Fedora/Arch-style multilib is a much, much > > this is at least the second time you've drawn this distinction > in this thread. for any

Re: Lintian and Dpkg's :any multiarch acceptor

On 11/3/21 23:34, Felix Lechner wrote: 1. Did anyone find the latest Lintian versions (2.109.0 and up) confusing as to whether the :any should be included? The material you would have encountered includes both the context offered by Lintian (the extra information after the tag) and any relevant

Re: Lintian and Dpkg's :any multiarch qualifier

Hi Felix, Quoting Felix Lechner (2021-11-04 20:25:28) > On Thu, Nov 4, 2021 at 2:35 AM Johannes Schauer Marin Rodrigues > wrote: > > it seems the only tool that calls :any an "acceptor" is lintian > > I think the multiarch spec is confusing because of its termi

Re: Lintian and Dpkg's :any multiarch qualifier

Hi Johannes, On Thu, Nov 4, 2021 at 2:35 AM Johannes Schauer Marin Rodrigues wrote: > it seems the only tool that calls :any an "acceptor" is lintian I think the multiarch spec is confusing because of its terminology. It's been a hurdle for many people. > still wasn't sure what

Re: Lintian and Dpkg's :any multiarch qualifier

Hi, Quoting Felix Lechner (2021-11-03 23:34:17) > For a brief time between October 1 and October 15, Lintian gave potentially > confusing advice on some build prerequisites. [1] > > The :any multiarch acceptor—a rarely used feature some other tools call the > "muliarch q

Lintian and Dpkg's :any multiarch acceptor

Hi, For a brief time between October 1 and October 15, Lintian gave potentially confusing advice on some build prerequisites. [1] The :any multiarch acceptor—a rarely used feature some other tools call the "muliarch qualifier"—was originally not implemented at all [2] and then i

Bug#644986: marked as done (i386: Compiling gcc-snapshots from upstream with multiarch-toolchain?)

Your message dated Mon, 27 Jul 2020 18:05:22 +0200 with message-id <2ea4db46667572b33b5148a72025785732318b06.ca...@43-1.org> and subject line Re: general: Multiarch breaks support for non-multiarch toolchain has caused the Debian Bug report #637232, regarding i386: Compiling gcc-snapshot

Bug#637232: marked as done (general: Multiarch breaks support for non-multiarch toolchain)

Your message dated Mon, 27 Jul 2020 18:05:22 +0200 with message-id <2ea4db46667572b33b5148a72025785732318b06.ca...@43-1.org> and subject line Re: general: Multiarch breaks support for non-multiarch toolchain has caused the Debian Bug report #637232, regarding general: Multiarch breaks s

Please drop Pre-Depends: multiarch-support

Hello! I'd like to draw peoples attention to https://lintian.debian.org/tags/pre-depends-directly-on-multiarch-support.html In short, please drop "Pre-Depends: multiarch-support" from affected packages! (Lintian suggests using ${misc:Pre-Depends} but that expands to empty since a

Re: How to change config script for multiarch?

On 09.05.2016 16:37, Jakub Wilk wrote: * Helmut Grohne , 2016-05-09, 06:47: The first misconception I see in this thread is that somehow pkg-config is good and foo-config is bad. It's not as simple as that. Have a look at libpython3-dev. It ships e.g.

Re: How to change config script for multiarch?

* Helmut Grohne , 2016-05-09, 06:47: The first misconception I see in this thread is that somehow pkg-config is good and foo-config is bad. It's not as simple as that. Have a look at libpython3-dev. It ships e.g. x86_64-linux-gnu-python3-config. This is an unfortunate

Re: How to change config script for multiarch?

On Mon, 09 May 2016 at 06:47:38 +0200, Helmut Grohne wrote: > In order for pkg-config to be "better" than your foo-config script, you > need to tell it about the current host architecture by prefixing it with > the triplet. Instead of calling pkg-config, you should be calling >

Re: How to change config script for multiarch?

his thread is that somehow pkg-config is good and foo-config is bad. It's not as simple as that. Have a look at libpython3-dev. It ships e.g. x86_64-linux-gnu-python3-config. By prefixing the script with the triplet, we can treat it very much like libraries that are being placed in multiarch loca

{MBF}: Upcoming changes in flex to accommodate multiarch

Hi, Executive summary: An upcoming release of flex is going to stop pulling in libfl-dev; which will impact packages that build C++ scanners (and thus need FlexLexer.h). Please update your packages Build-depends line if it is affected (lists follow). Until recently, it was

Re: How to change config script for multiarch?

On Fri, Feb 12, 2016 at 8:10 PM, Bastien Roucaries wrote: > i will open a wiki page including this thread comments No need to duplicate the official documentation: https://sources.debian.net/doc/url/ Also no need to CC me. -- bye, pabs https://wiki.debian.org/PaulWise

Re: How to change config script for multiarch?

Le 12 février 2016 02:02:53 GMT+01:00, Paul Wise a écrit : >On Wed, Feb 10, 2016 at 9:09 PM, Johannes Schauer wrote: > >> A bit OT: the old-style-config-script lintian description links to a >404 page >> on sources.debian.net. Maybe this link should be updated? Is there a >way

Re: How to change config script for multiarch?

Hi, Quoting Bastien Roucaries (2016-02-12 10:10:10) > Le 12 février 2016 02:02:53 GMT+01:00, Paul Wise a écrit : > >On Wed, Feb 10, 2016 at 9:09 PM, Johannes Schauer wrote: > > > >> A bit OT: the old-style-config-script lintian description links to a > >404 page > >> on

Re: upstream_version not starting with a digit (was: Re: How to change config script for multiarch?)

* Johannes Schauer , 2016-02-12, 13:41: dpkg-buildpackage: warning: debian/changelog(l1): version '0:jessie' is invalid: version number does not start with digit LINE: name (0:jessie) unstable; urgency=medium According to the following regex over my Sources there seems to

upstream_version not starting with a digit (was: Re: How to change config script for multiarch?)

Hi, Quoting Paul Wise (2016-02-12 02:02:53) > On Wed, Feb 10, 2016 at 9:09 PM, Johannes Schauer wrote: > > A bit OT: the old-style-config-script lintian description links to a 404 > > page > > on sources.debian.net. Maybe this link should be updated? Is there a way to > > create a link to a file

Re: How to change config script for multiarch?

At Fri, 12 Feb 2016 01:12:43 +0100, Jakub Wilk wrote: > I don't know much about this package, but codesearch.d.n tells me that > all users of chasen-config call it with the --mkchadic option, which > causes the script to print /usr/lib//chasen/, which is a > directory shipped by chasen-config. So

Re: How to change config script for multiarch?

* Johannes Schauer <jo...@debian.org>, 2016-02-10, 11:09: I am a maintainer of chasen package. It contains chasen-config, it work as pkg-config like but it's a single script. Latest lintain reports: E: libchasen-dev: old-style-config-script-multiarch-path usr/bin/chasen-config ful

Re: How to change config script for multiarch?

Hi, Quoting Jakub Wilk (2016-02-11 12:44:34) > * Johannes Schauer , 2016-02-10, 11:09: > >The old-style-config-script tag which src:chasen suffers from as well and > >which was also linked to by Bastien contains more valuable information. The > >important message is: please use

Re: How to change config script for multiarch?

* NOKUBI Takatsugu , 2016-02-12, 08:27: Jakub Wilk wrote: Are you trying to move the script to libchasen-dev? Why? There are Debian maintainer scripts that use chasen-config. Are they going to depend on the -dev package? Yes, now I will move the script into libchasen-dev

Re: How to change config script for multiarch?

On Wed, Feb 10, 2016 at 9:09 PM, Johannes Schauer wrote: > A bit OT: the old-style-config-script lintian description links to a 404 page > on sources.debian.net. Maybe this link should be updated? Is there a way to > create a link to a file on sources.debian.net where, if the version doesn't >

Re: How to change config script for multiarch?

On Fri, Feb 12, 2016 at 10:20 AM, NOKUBI Takatsugu wrote: > I am also a member of the upstream, but the software is now under > maintainance phase, so it is hard to accept using pkg-config insead of > the current script. > I consider to use pkg-config on debian specific patch in the future.

Re: How to change config script for multiarch?

At Wed, 10 Feb 2016 13:17:50 +0100, Jakub Wilk wrote: > Are you trying to move the script to libchasen-dev? Why? There are > Debian maintainer scripts that use chasen-config. Are they going to > depend on the -dev package? Yes, now I will move the script into libchasen-dev because it seems make

Re: How to change config script for multiarch?

Thank you your good answer. At Wed, 10 Feb 2016 08:34:10 +0100, Vincent Danjean wrote: > I do not think there is a generic answer. But, if your script is > simple, perhaps just replacing hardcoded directory names by the output > of "dpkg -qDEB_HOST_MULTIARCH" will be enough. I think

Re: How to change config script for multiarch?

On Wed, Feb 10, 2016 at 8:12 AM, NOKUBI Takatsugu <k...@daionet.gr.jp> wrote: > I am a maintainer of chasen package. It contains chasen-config, it > work as pkg-config like but it's a single script. > > Latest lintain reports: > E: libchasen-dev: old-style-config-script-mult

Re: How to change config script for multiarch?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi , I've solved this problem by: (1) creating a pkg-config script, adding it as multiarch. (2) editing the config script to use the pkg-config script. In particular, for any non-standard variables, you can read them, by eg: f90_compiler=$(pkg

Re: How to change config script for multiarch?

> > Latest lintain reports: > > E: libchasen-dev: old-style-config-script-multiarch-path > > usr/bin/chasen-config full text contains architecture specific dir > > x86_64-linux-gnu > > > > But I want to keep libchasen-dev as Multi-Arch: same. Would you tell >

Re: How to change config script for multiarch?

On Wed, Feb 10, 2016 at 10:59 AM, Alastair McKinstry <mckins...@debian.org> wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Hi , > > I've solved this problem by: > (1) creating a pkg-config script, adding it as multiarch. > (2) editing the co

Re: How to change config script for multiarch?

On Wed, 10 Feb 2016 at 11:03:04 +0100, Bastien ROUCARIES wrote: > On Wed, Feb 10, 2016 at 10:59 AM, Alastair McKinstry > <mckins...@debian.org> wrote: > > I've solved this problem by: > > (1) creating a pkg-config script, adding it as multiarch. > > (2) editing th

Re: How to change config script for multiarch?

* NOKUBI Takatsugu <k...@daionet.gr.jp>, 2016-02-10, 16:12: I am a maintainer of chasen package. It contains chasen-config, it work as pkg-config like but it's a single script. Latest lintain reports: E: libchasen-dev: old-style-config-script-multiarch-path usr/bin/chasen-config ful

How to change config script for multiarch?

I am a maintainer of chasen package. It contains chasen-config, it work as pkg-config like but it's a single script. Latest lintain reports: E: libchasen-dev: old-style-config-script-multiarch-path usr/bin/chasen-config full text contains architecture specific dir x86_64-linux-gnu But I want

Re: How to change config script for multiarch?

Le 10/02/2016 08:12, NOKUBI Takatsugu a écrit : > I am a maintainer of chasen package. It contains chasen-config, it > work as pkg-config like but it's a single script. > > Latest lintain reports: > E: libchasen-dev: old-style-config-script-multiarch-path > usr/bin/chase

Re: Getting multiarch fixes unstuck

On 09/03/15 14:16, Francois Gouget wrote: About a month ago I sent fixes to make a bunch of packages multiarch compatible. You might have noticed that Debian has been in a freeze for the last 4 months: https://release.debian.org/jessie/freeze_policy.html Multiarch'ifying libraries for Debian

Getting multiarch fixes unstuck

About a month ago I sent fixes to make a bunch of packages multiarch compatible. However, except for two packages, none of the 20 packages have included the proposed fix, or commented on them, requested improvements, or given any sign of life. What can I do to help move things forward? Here

Re: moving to multiarch for packages with plugins

Wow -- thanks so much everyone who replied. This is really helpful! Cheers, Dennis van Dok (on behalf of the other developers) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive:

Re: moving to multiarch for packages with plugins

. If the version of the framework that introduces multiarch is x, the plugins would have to include Depends: liblcmaps0 (= x) once they update to multiarch. It's harder to reversely state that the new framework conflicts with older plugin packages: they would all have to be listed in the control file

moving to multiarch for packages with plugins

that the plugins are not in a single source package. Once we update the framework package, all the plugin packages need to update as well. The way to solve this would be by adding certain dependencies. If the version of the framework that introduces multiarch is x, the plugins would have to include

Re: moving to multiarch for packages with plugins

-3) with the current version of all known plugins, and leave that line in for at least one release, possibly adding new plugins or adjusting the version if a plugin ships another version without multiarch. Simon -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject

Re: moving to multiarch for packages with plugins

included plugins are multiarch, openscenegraph-plugin-osgearth isn't), but it already had the check multiple locations mechanism before it became multiarch (osgDB::appendPlatformSpecificLibraryFilePaths in https://sources.debian.net/src/openscenegraph/3.2.1-6/OpenSceneGraph/src/osgDB

Re: moving to multiarch for packages with plugins

path. Is multiarch actually beneficial to you for lcmaps / would it ever make sense to have more than one architecture's instance of it installed? If not, you can use something like dh_auto_configure -- --libdir=/usr/lib to take it back to the single-arch path. This is what telepathy-mission-control

Bug#637232: BTS #637232: Multiarch breaks support for non-multiarch toolchain

Hi, My condolences for too many non-bug bug-reports :-) I have no objection to have some mention for the multiarch in release-notes. But relaistically, users who do not read NEWS.Debian (very long) will likely not to read long release-notes :-( So documenting here will have minimal impact

Re: multiarch coinstallability of libc6 / conflicting loader paths

On Sun, Dec 07, 2014 at 01:08:24AM +0100, Timo Weingärtner wrote: A short-term fix for the dpkg errors could be to express the conflicting loader paths with Conflicts: between the relevant libc6 packages. Have multiarch conflicts/breaks been specified already? Sure, this would

multiarch coinstallability of libc6 / conflicting loader paths

Hi, last week I tried exploiting multiarch to set up a machine to build and run binaries for multiple architectures. So I enabled architectures in dpkg, updated the package lists and tried installing libc6 packages for each architecture, but dpkg refused to unpack libc6:mipsel after libc6

Re: multiarch coinstallability of libc6 / conflicting loader paths

the same path for their dynamic loader: /lib/ld.so.1 FYI, some earlier discussion of this issue: https://wiki.debian.org/Multiarch/LibraryPathOverview#ELF_interpreter-1 https://lists.linaro.org/pipermail/linaro-toolchain/2010-July/58.html https://sourceware.org/glibc/wiki/ABIList https

Re: binary data file and endianness and multiarch

On 09/27/2014 05:36 PM, Adam Borowski wrote: Except that the endianness war has been won by little-endian and thus your code would optimize for an already tiny part of the population that is going to only decrease: arm, mips switched from mostly be to almost only le, and the newest Debian

Re: binary data file and endianness and multiarch

Hi, Quoting Thomas Goirand (2014-09-28 12:42:24) Just to be sure: is ppc64el also using little endian? yes it is. Here is a great overview which answers that question and others: https://wiki.debian.org/ArchitectureSpecificsMemo cheers, josch -- To UNSUBSCRIBE, email to

Re: binary data file and endianness and multiarch

On Sun, 2014-09-28 at 18:42 +0800, Thomas Goirand wrote: Just to be sure: is ppc64el also using little endian? Yes; that's why the name ends in el. Regards, Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact

Re: binary data file and endianness and multiarch

On Sun, 2014-09-28 at 18:42:24 +0800, Thomas Goirand wrote: On 09/27/2014 05:36 PM, Adam Borowski wrote: Except that the endianness war has been won by little-endian and thus your code would optimize for an already tiny part of the population that is going to only decrease: arm, mips

Re: binary data file and endianness and multiarch

On Sat, Sep 27, 2014 at 04:41:42AM +0200, Juliusz Chroboczek wrote: Standardising on big-endian is a good idea, not only because it is the canonical byte ordering, but also because little-endian arches tend to have more efficient byte-swapping instructions. Except that the endianness war has

Re: binary data file and endianness and multiarch

On 27 Sep 2014, at 10:36, Adam Borowski kilob...@angband.pl wrote: Except that the endianness war has been won by little-endian And yet, network byte order remains big. It's less important which endian they pick, but that they pick one and use it consistently across arches. -- To

Re: binary data file and endianness and multiarch

Hi, Jonathan Dowland: It's less important which endian they pick, but that they pick one and use it consistently across arches. The advantage of using big-endian data on a little-endian system is that you actually have a chance of finding mis-swapped and/or mis-sized items. I do admit that

Re: binary data file and endianness and multiarch

On 2014-09-27 11:18:18 +0100, Jonathan Dowland wrote: On 27 Sep 2014, at 10:36, Adam Borowski kilob...@angband.pl wrote: Except that the endianness war has been won by little-endian And yet, network byte order remains big. But does this matter in the context of these binary data files?

Re: binary data file and endianness and multiarch

Standardising on big-endian is a good idea [...] Except that the endianness war has been won by little-endian That's not what my mail was about. My point is that the issue with the software should be resolved upstream, rather than implementing yet another dodgy hack in dpkg. Which particular

Re: binary data file and endianness and multiarch

Hello All, thanks for your answer. On 27/09/14 23:37, Juliusz Chroboczek wrote: Standardising on big-endian is a good idea [...] Except that the endianness war has been won by little-endian That's not what my mail was about. My point is that the issue with the software should be

Re: binary data file and endianness and multiarch

That's not what my mail was about. My point is that the issue with the software should be resolved upstream, in my case, it cannot be resolved upstream, Yes, abandoned software is a problem, unfortunately quite common in the scientific community. (Understandably so, since researchers get

binary data file and endianness and multiarch

source), so it may support multiarch. What is not clear to me right now is how to stock those data files: is there an endian triplet ? Any hint is welcome, Jerome [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762746 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org

Re: binary data file and endianness and multiarch

The mesh files are stored in binary form, and thus endian-ness is a worry when moving from one platform to another. [...] What is not clear to me right now is how to [store] those data files: is there an endian triplet ? Jérôme, Please try to work with upstream to fix the issue. Byte

Re: Multiarch capabilities for mingw crossbuilds too?

On Fri, 8 Aug 2014 16:41:22 +0100, Wookey woo...@wookware.org wrote: +++ Joerg Desch [2014-08-08 05:38 +]: Today I've read about Debians Multiarch capabilities for the first time. Is it possible to use this technique to build deb packages of libraries for the mingw crosscompile

Multiarch capabilities for mingw crossbuilds too?

Today I've read about Debians Multiarch capabilities for the first time. Is it possible to use this technique to build deb packages of libraries for the mingw crosscompile toolchain too? I have to build Windows executables and therefore need some libraries. For now, I build and install them

Re: Multiarch capabilities for mingw crossbuilds too?

+++ Joerg Desch [2014-08-08 05:38 +]: Today I've read about Debians Multiarch capabilities for the first time. Is it possible to use this technique to build deb packages of libraries for the mingw crosscompile toolchain too? In principle, yes. In practice right now, no. Stephen Kitt has

Re: bzip2 and multiarch transition

the lib32bz* packages. For the record, I run some tests: Case 1: i386 multiarch is not enable: apt does not consider to upgrade it automatically, however apt-get install lib32bz2-1.0 understands the dependency, but since it cannot satisfy it, it exits with error. aptitude automatically considers

Re: bzip2 and multiarch transition

On Mon, Jul 28, 2014 at 07:38:46AM +0200, santi...@debian.org wrote: So, to be sure, should I just drop the old lib{32,64}bz2*, without any transition mechanism? (no other package depends on them now.) If they are not referenced in the archive, nothing special needs to be done.

Re: bzip2 and multiarch transition

On 28 July 2014 06:38, santi...@debian.org wrote: Hi, (Please CC me when answering) I've just uploaded a new bzip2 revision and I think I need to revert a change. bzip2 used to build cross architecture lib{32,64}bz2* packages, but multiarch has obsoleted them. To stop building those

Re: bzip2 and multiarch transition

On Mon, Jul 28, 2014 at 09:27:20AM +0100, Dimitri John Ledkov wrote: On 28 July 2014 06:38, santi...@debian.org wrote: I've just uploaded a new bzip2 revision and I think I need to revert a change. bzip2 used to build cross architecture lib{32,64}bz2* packages, but multiarch has obsoleted

Re: bzip2 and multiarch transition

architecture lib{32,64}bz2* packages, but multiarch has obsoleted them. To stop building those packages (and close #736815), and to look for a smooth transition, I added conflicts/replace/provides control fields in the -1.0 and -dev packages. But I realized that those fields were wrong

Re: bzip2 and multiarch transition

On Mon, Jul 28, 2014 at 08:59:26PM +0200, Philipp Kern wrote: I guess you could offer lib32bz2 as a transitional package on the 32bit arch, depending on libbz2 of its own arch and vice versa for lib64? Since when does apt consider a:amd64 - a:i386 a valid upgrade path? The only reason to ship

bzip2 and multiarch transition

Hi, (Please CC me when answering) I've just uploaded a new bzip2 revision and I think I need to revert a change. bzip2 used to build cross architecture lib{32,64}bz2* packages, but multiarch has obsoleted them. To stop building those packages (and close #736815), and to look for a smooth

Re: multiarch: arch dependent header file path choice

Am 28.06.2014 19:44, schrieb Osamu Aoki: Hi, The path for the arch dependent header file seems to have several options. 1) /usr/include/multiarch/*.h 2) /usr/include/multiarch/packagename/*.h 3) /usr/lib/multiarch/packagename/include/*.h I would like to know rationale for each

Re: multiarch: arch dependent header file path choice

On 28/06/14 18:44, Osamu Aoki wrote: The path for the arch dependent header file seems to have several options. 1) /usr/include/multiarch/*.h 2) /usr/include/multiarch/packagename/*.h 3) /usr/lib/multiarch/packagename/include/*.h The correct answer depends: (a) what users are meant

multiarch: arch dependent header file path choice

Hi, The path for the arch dependent header file seems to have several options. 1) /usr/include/multiarch/*.h 2) /usr/include/multiarch/packagename/*.h 3) /usr/lib/multiarch/packagename/include/*.h I would like to know rationale for each choice, especially between 2 and 3. I am sure they all

Re: multiarch: arch dependent header file path choice

On Sun, Jun 29, 2014 at 02:44:21AM +0900, Osamu Aoki wrote: Hi, The path for the arch dependent header file seems to have several options. 1) /usr/include/multiarch/*.h 2) /usr/include/multiarch/packagename/*.h 3) /usr/lib/multiarch/packagename/include/*.h I would like to know

Multiarch and perl

On Fri, May 02, 2014 at 05:14:48PM +0300, Niko Tyni wrote: It seems to me that an interpreter supporting DSO language extensions can have multi-arch support at several different levels. 1) multiarch annotations for /usr/bin/interp, but no Multi-Arch:same packages. The architecture of /usr

Multiarch and interpreters

.html It seems to me that an interpreter supporting DSO language extensions can have multi-arch support at several different levels. I think this classification might explain why the current python multiarch implementation hasn't encountered the above problems. The levels I see are 1) multiarch

ld.so for multiarch and multilib installed at same time

On amd64 system: libc6-i386 make /lib/ld-linux.so.2 link to /lib32/ld-linux.so.2 and link to /lib32/ld-2.18.so libc6:i386 make /lib/ld-linux.so.2 link to /lib/i386-linux-gnu/ld-2.18.so when these 2 packages installed at the same time /lib/ld-linux.so.2 is linked to

Re: ld.so for multiarch and multilib installed at same time

Yunqiang Su wrote: On amd64 system: libc6-i386 make /lib/ld-linux.so.2 link to /lib32/ld-linux.so.2 and link to /lib32/ld-2.18.so libc6:i386 make /lib/ld-linux.so.2 link to /lib/i386-linux-gnu/ld-2.18.so when these 2 packages installed at the same time /lib/ld-linux.so.2 is

Re: ld.so for multiarch and multilib installed at same time

of multi-arch setup? ldso is the load of binary, it is the entrance of any binary execution. On any system, it is fixed please see: https://wiki.debian.org/Multiarch/LibraryPathOverview#ELF interpreter It is directly in these packages. On mips64el system: libc6-mips32 make /lib/ld.so.1 link to /lib

Re: ld.so for multiarch and multilib installed at same time

, or made by postinst etc.? Are the 2 packages sensible in terms of multi-arch setup? ldso is the load of binary, it is the entrance of any binary execution. On any system, it is fixed please see: https://wiki.debian.org/Multiarch/LibraryPathOverview#ELF interpreter Oh yes, I lnow that bit. I've got

Re: ld.so for multiarch and multilib installed at same time

On Fri, Apr 25, 2014 at 06:49:49PM +0800, Yunqiang Su wrote: On amd64 system: libc6-i386 make /lib/ld-linux.so.2 link to /lib32/ld-linux.so.2 and link to /lib32/ld-2.18.so libc6:i386 make /lib/ld-linux.so.2 link to /lib/i386-linux-gnu/ld-2.18.so when these 2 packages

Re: ld.so for multiarch and multilib installed at same time

On Fri, Apr 25, 2014 at 9:00 PM, Andrey Rahmatullin w...@wrar.name wrote: On Fri, Apr 25, 2014 at 06:49:49PM +0800, Yunqiang Su wrote: On amd64 system: libc6-i386 make /lib/ld-linux.so.2 link to /lib32/ld-linux.so.2 and link to /lib32/ld-2.18.so libc6:i386 make

Re: ld.so for multiarch and multilib installed at same time

On Fri, 2014-04-25 at 16:39 +0800, Yunqiang Su wrote: [...] On mips64el system: libc6-mips32 make /lib/ld.so.1 link to /lib/ld-2.18.so (yes, quite strange, mips system asks for use /lib as o32 multilib path) libc6:mipsel make /lib/ld.so.1 link to /lib/mipsel-linux-gnu/ld-2.18.so

Re: ld.so for multiarch and multilib installed at same time

On Fri, 2014-04-25 at 16:28 +0100, Ben Hutchings wrote: On Fri, 2014-04-25 at 16:39 +0800, Yunqiang Su wrote: [...] On mips64el system: libc6-mips32 make /lib/ld.so.1 link to /lib/ld-2.18.so (yes, quite strange, mips system asks for use /lib as o32 multilib path)

conflicts and multiarch

Hello, when working on the next version of dose-distcheck we found a cornercase where we are not sure about multiarch semantics. To explain the problem at hand of an example: without mutiarch, we all know that a self-conflict is ignored: Package: a1 Architecture: amd64 Version: 1 Conflicts

Re: conflicts and multiarch

Hi, On 11/04/2014 19:32, Ralf Treinen wrote: Can package a2 be installed for both architectures at the same time? Policy section 7.4 seems to indicate that yes, but then it was written without multiarch in mind. What do you think should be the right answer? You can install a2:amd64

Multirelease, something like Multiarch.

Hello, Multiarch gives the ability to store libraries in the main root lib directories from different architectures and this allows applications to co-exist on the same system. Some applications are compiled for amd64 while others are for i386 and perhaps x32. This could have been done using

Re: Multirelease, something like Multiarch.

On Fri, Feb 21, 2014 at 09:31:56AM -0600, Mike Mestnik wrote: Now we've a similar situation for releases and even distributions. We can run multiple releases using a chroot for each, but perhaps this system can be improved on. This doesn't seem particularly Debian-specific, so I'm not sure

Re: AST ksh alpha: compilation failure related to multiarch

Hi Steve, On 27/10/13 20:44, Steve Langasek wrote: I think to submit them a summary of https://wiki.debian.org/Multiarch/TheCaseForMultiarch for the reason of such a header files setup in debian/ubuntu and https://wiki.debian.org/Multiarch/LibraryPathOverview for the way their source code

AST ksh alpha: compilation failure related to multiarch

the same behavior (i.e compilation failure solved with the symlink) under debian wheezy and ubuntu 12.04. So I think ksh does not handle correctly the implementation of multiarch in debian. Am I right? If ksh source code does not handle multiarch correctly, which document should I ask upstream

Re: AST ksh alpha: compilation failure related to multiarch

/usr/include/sys - /usr/include/x86_64-linux-gnu/sys the compilation succeeds. I have the same behavior (i.e compilation failure solved with the symlink) under debian wheezy and ubuntu 12.04. So I think ksh does not handle correctly the implementation of multiarch in debian. Am I right? I

Re: [RFC] multiarch and virtual packages

of this virtual package on all architectures, which is what's currently required? Or libc-dev: on some architectures, this is provided by libc6-dev, but other architectures have different names for the -dev package, which makes cross-building for these architectures using multiarch quite impossible. So I

Re: [RFC] multiarch and virtual packages

in multiarch mode. Regards, Vincent S -- Vincent Danjean GPG key ID 0x9D025E87 vdanj...@debian.org GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87 Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html APT repo: deb http

Re: [RFC] multiarch and virtual packages

Le 03/10/2013 13:04, David Kalnischkies a écrit : On Thu, Oct 3, 2013 at 11:54 AM, Vincent Danjean vdanjean...@free.fr wrote: I tried several variation, adding :same and/or :i386/:amd64 to the Conflicts and/or Provides in ICD Loader. I do not succeed into :same doesn't exist (in this

Re: [RFC] multiarch and virtual packages

On Thu, Oct 03, 2013 at 11:54:55AM +0200, Vincent Danjean wrote: The current proposal about Depends/Conflicts/Provides is the following: ICD Loader: === Section: libs Multi-Arch: same Architecture: any Provides: libopencl1 Conflicts: libopencl1 Replaces: libopencl1 Suggests (or

Re: ports and multiarch

On 2 Oct 2013, at 20:44, Ben Hutchings b...@decadent.org.uk wrote: I don't think Debian development should be driven by retro-computing. No, but driven by demand makes sense to me, and I'm glad Stephen pulled some figures on that. I'm not saying we should drop support for perfectly

[RFC] multiarch and virtual packages

architecture, but no relation between ICD Loader for different architectures in multiarch). I see (not tested) one solution: to use one virtual package per architecture (libopencl1-i386, libopencl1-amd64, ...) but this means to generate the Provides/Conflicts/Replaces field at build time (using

Re: [RFC] multiarch and virtual packages

On Thu, Oct 3, 2013 at 11:54 AM, Vincent Danjean vdanjean...@free.fr wrote: I tried several variation, adding :same and/or :i386/:amd64 to the Conflicts and/or Provides in ICD Loader. I do not succeed into :same doesn't exist (in this context), where did you find that? Anyway, negative

Re: [RFC] multiarch and virtual packages

On 03/10/13 10:54, Vincent Danjean wrote: The only problem is that it is not currently possible to install an ICD Loader:i386 from one vendor and an ICD Loader:amd64 from another vendor. Is there a valid reason to do that, other than because I can? If nobody would actually want to do that,

  1   2   3   4   5   6   7   8   9   10   >