Hi,
2011/6/29 Johannes Schauer :
> On Wed, Jun 29, 2011 at 10:07:17AM +0000, Hector Oron wrote:
> indeed that works for some debian architectures but for example for
> ARCH=powerpc, QEMUARCH should be ppc but dpkg-architectures only prints
> powerpc for the DEB_HOST_ARCH_CPU.
True.
Hi,
2011/3/23 Steve Langasek :
>> (Apologies for big attachment on previous email)
> Your mail doesn't seem to have made it through to the Debian mailing lists,
> and it arrived at the linaro list with the attachments stripped (presumably
> for size). :( Can you post these logs on a website som
Hi Goswin,
>>> It wouldn't. I don't see a compelling reason for dpkg to do this at all.
>>> Your quote shows that dpkg *does* do this today, which I didn't remember
>>> before this conversation, but that's not an explanation for *why* it does
>>> -
>>> as opposed to dpkg directly recording what i
Hello Loïc,
2010/7/25, Loïc Minier :
> On Sun, Jul 25, 2010, Hector Oron wrote:
>> Sysroot is everybody's way to cross compile in world but us (Debian)
>> if multiarch aims to be a fit-all solution it should be relevant, if
>> it is not, either you might misunderstood s
Dear Steve,
2010/7/24, Steve Langasek :
> On Mon, Jul 19, 2010 at 07:02:32PM +0100, Hector Oron wrote:
>> 2010/7/18 Steve Langasek :
>> AFAICS `dpkg' relais on -dumpmachine from `gcc'
>> scripts/Dpkg/Arch.pm:68:my $gcc_host_gnu_type = `\${CC:-gcc}
>&
Hi,
2010/7/19 Konstantinos Margaritis :
>> I can't see a use case to run 'armel' binaries on 'armhf' rootfs if
>> hardware supports it and software is free.
>
> From a hardware point of view, if it can run armhf it will certainly be able
> to run armel. A developer would be able to provide both pa
-architecture flags set could do the job)
• Lots of work for administrator. (A distributed shell or the right
bindings in place could also keep up with it)
Plus there is place for multiple binaries as well, that you can easily
run using QEmu magic.
> (BTW... if you want to run
Dear porters, dpkg maintainers and developers,
It seems that `armhf' and `arm-hardfloat-linux-gnueabi' are the winners.
We are starting to work on Debian new port based on those names.
Thanks all for your contributions!
Best regards,
--
Héctor Orón
19:57 < markos_> ostable: armhf
Dear developers,
2010/7/13, Riku Voipio :
> Subarchs could also be useful if we wanted to build softfp abi compatible
> armv6/armv7 armel builds of the whole debian repository. Of course we could
> do
> builds without subarchs, but then users would be unable distinguish which
> installed packages
Hello,
2010/7/15, Paul Brook :
> It isn't. "Cortex" is the marketing name for the current set of CPU core
> implementations designed by ARM ltd. Calling the armv7 port "cortex" is
> equivalent to calling the i686 port "pentium" [1].
But i?86 is ABI compatible, while ARM ABI is a full mess AFAICS
Hello,
2010/7/15, Konstantinos Margaritis :
> First, 'cortex' is not a vendor. it's a cpu family. It's not owned by
> Marvell
> or Qualcomm, but by ARM, if they are OK with us using the name, I don't see
> why the other companies would mind, esp. if they don't offer a cpu in that
> particular fami
Hello,
2010/7/6, Hector Oron :
> Dear armel porters,
[...]
It is past over a week and people is wanting to start.
I would like to point you to a parallel discussion hold at recent
created Linaro group [1]
There is also a wiki page for the port [2]
The one that bootstraps the port picks
Dear armel porters,
I am writting this letter to you by out concern of having to pick
up a name for a new armel architecture variant optimized for hard
floating point, instead soft floating point.
Konstantinos (and I shall be also supporting him) is willing to
maintain a new architecture fo
Hello,
2010/5/17 tangke :
> We've written a small installer, which will extract a base system
> archive, and then install additional debs in a chroot environment.
Out of curiosity, who is we? Is it posible to have a look to such
installer code?
Have you tried multistrap? [1]
> How to avoid stopi
Hello,
2010/4/28 Russ Allbery :
[...]
> I'm not sure what you mean by "flat binaries" here.
I meant
http://www.beyondlogic.org/uClinux/bflt.htm
[...]
> I see no reason why embedded platforms can't use ELF. ELF is very common
> in the embedded world even entirely apart from Linux.
Sometimes ELF
Hello Russ,
2010/4/27 Russ Allbery :
> I have a hard time imagining Debian ever supporting non-ELF targets. We'd
> need to maintain a completely separate libc, for instance, since I'm
> fairly sure glibc is ELF only.
uClibc is on the archive (not usable for runtime), it was also added
to dpkg as
Hi,
2010/4/23 Jonathan Nieder :
> Even if all supported targets use ELF, I don’t think it would justify
> the churn. The main advantages:
>
> - readelf is tiny and works for all ELF targets.
> By contrast, multi-target objdump is large and its Debian package
> only supports the targets that
Hi,
Thanks for the introduction.
2009/7/25 Goswin von Brederlow :
> after listening to the "Multiarch round table" talk at Debconf I feel
> that the talk was targeted at people already familiar with the subject
> and jumped right in at full speed. Someone new to the idea was
> probably lost in th
Hello,
> The toolchain does not yet look in all the right places. Neither for
> the multiarch nor the corss-compile way of putting the prefix. It is
> in a state where both ways are used and neither is complete enough for
> a full system.
So, would it be fine to send an addendum to multiarch[1] d
Hello,
>>> , and there is generally no need to
>>> install anything but libraries and headers into /usr/ -- so I
>>> don't think there is a pressing need to replicate a filesystem hierarchy
>>> standard below a triplet directory.
>
>> True, however, that is not a sufficient reason to not
>> move
Hello Simon,
> As far as I've understood, --with-sysroot gives the path to the target OS
> installation so the build can run "fixincludes" and add it to the search
> paths; since it should work with a largely unmodified snapshot of the
> target OS, they are pretty tolerant with the directory layou
Hello Simon,
> install anything but libraries and headers into /usr/ -- so I
> don't think there is a pressing need to replicate a filesystem hierarchy
> standard below a triplet directory.
That is what GNU people expect when building cross tools, they use a
switch called sysroot for it and it is
Hello,
I have been talking with Guillem on IRC, he has point me to a
reference[1], that might be useful.
[1] http://lackof.org/taggart/hacking/multiarch/
Regards
--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lis
>> The question is
>>
>> /arm-linux-gnu/lib/libfoo.so
> l> /usr/arm-linux-gnu/[usr/]lib/libbla.so
>> /usr/arm-linux-gnu/[usr/]include/foo.h
>>
>> or
>>
>> /lib/arm-linux-gnu/libfoo.so
>> /usr/lib/arm-linux-gnu/libbla.so
>> /usr/include/arm-linux-gnu/foo.h
>>
>> It has always been a question of wher
Hello,
[*]
I have been looking lately into making some cross toolchain
improvements, one of them will be to change to a sysrooted cross
toolchain, but the current layout we are using by dpkg-cross installs
relevant bits under:
/{include,bin,lib,lib64}
Mainstream code expects a different layo
Hello,
> gcc is still lacking some patches to properly support building using
> the multiarch dirs, Aurélien Jarno said he would be preparing some
> patches for which Matthias Klose agreed to include (at least agreed with
> the idea behind the patches).
>
> Once we have a working toolchain we can
26 matches
Mail list logo
