not as if
gnat-4.9 is about to migrate into testing, even then the new version
would migrate with the constraints met.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgpbnbEwmKcfw.pgp
Description: OpenPGP digital signature
On Sat, 14 Jul 2012 20:12:45 +0200
Matthias Klose wrote:
> On 14.07.2012 20:02, Neil Williams wrote:
> > On Sat, 14 Jul 2012 03:08:09 +0200 Matthias Klose wrote:
> >
> >> please could you find out, which object files (if there are more than
> >> one) do export
() const;
const QList &arguments() const;
template void serialize(Stream &stream) const;
template void deserialize(Stream &stream);
Why is gcc-4.7 overriding the class and optimising away a public symbol
in -O2 when it does not in -O1 or in gcc-4.6 with -O2?
dbg
pn libgomp1-dbg
pn libitm1-dbg
pn libmudflap0-4.7-dev
pn libmudflap0-dbg
pn libquadmath0-dbg
-- no debconf information
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgpjgG0ceHZ4O.pgp
Description: PGP signature
ch gcc-4.6 can pick up as an error or warning in
the qmf sources.
Reinstalling gcc-4.7 & g++-4.7 and rebuilding with the same flags
(and the #include patch) does not indicate any problems with
the qmfclient library itself, g++-4.7 just fails to link the test
binary.
--
Neil Williams
the .la file and the
dependency_libs settings, please raise this on debian-devel for
clarification.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgpWFqMTKvwXH.pgp
Description: PGP signature
ent that the entire dependency chain of a
C++ program using g++-4.5 would either generate new bugs or require
rebuilds using g++-4.5 merely to use the optional compiler.
Stable releases need a stable toolchain with known bugs, not a
comparatively untested optional compiler with compatibility issues
against the existing binary packages available in Squeeze.
--
Neil Williams
=
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/
pgpBJSvC5RwVL.pgp
Description: PGP signature
ut the file into /usr/powerpc-linux-gnu/lib/
Question is, where did this file come from?
I can check the chroot on emdebian.org - I just need to know which one
was used.
Could this be a result of a failed clean up in this chroot?
--
Neil Williams
=
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/
pgpUlzMhpzXK6.pgp
Description: PGP signature
reassign 518754 gcc-4.3
clone 518754 -1
reassign -1 gcc-4.4
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
ging tools and that means dpkg and no dpkg-cross, it means apt
and no apt-cross and it means that cross-building needs to adopt and
modify multiarch to the point where we can all use it, albeit with
wrappers and support tools where necessary. Then, we can work on
absorbing those wrappers into the new
/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 /usr/ to /usr/lib/ and /usr/include/
if it means getting such support into the core Debia
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 where to put the tripplet, not
> whether or not to have an extra subdir below that. Although I'm
> against the subdirs. No need to duplicate that this is "usr".
I'd agree - [usr] below $arch-linux-gnu appears redundant to me. The
only difference between /lib and /usr/lib/ relates to the libraries
required to boot before /usr is mounted. That reasoning doesn't apply
to toolchain issues.
--
Neil Williams
=
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/
pgpm553xyH46c.pgp
Description: PGP signature
lib/libfoo.so
/usr/include/arm-linux-gnu/usr/include/foo.h
?
I thought the question was whether we would have:
/usr/lib/arm-linux-gnu/lib/libfoo.so
or
/usr/lib/arm-linux-gnu/usr/lib/libfoo.so
or
/usr/arm-linux-gnu/usr/lib/libfoo.so
or the current
/usr/arm-linux-gnu/lib/libfoo.so
as a conversion of /usr/lib/libfoo.so
--
Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
pgpmAQytPasu5.pgp
Description: PGP signature
Package: gcc-snapshot
Version: 20090224-1
Severity: normal
This issue affects Emdebian Grip in gcc-4.3 but I'm filing it here because Grip
has
a workaround that is OK for 4.3 and I'm trying to fix the problem before 4.4
arrives.
Please let me know if I did that wrong.
The -base postinst script
hat need support from the existing Debian
arm port as well as newer devices that need the new ABI. There is a
possible method for combining the two but both will be needed - and
probably for some time after Lenny. Contact debian-arm for more info.
--
Neil Williams
=
http://ww
Raphael Hertzog wrote:
> On Sun, 09 Dec 2007, Neil Williams wrote:
>>> I'm ok with a
>>> supplementary specific check for building of a cross-compiler, but not
>>> with a generic check like testing the ARCH environment variable.
>> OK, I have a solution
Raphael Hertzog wrote:
> On Sun, 09 Dec 2007, Neil Williams wrote:
>> Emdebian cannot build, patch or test every permutation of toolchain that
>> people need so this isn't about "us" patching locally, it is about
>> lowering the barrier to cross building on De
Guillem Jover wrote:
> Hi,
>
> [ I don't have a real opinion yet on the initial patch and this
> changes proposed, will try to get to this on Sunday. ]
OK, thanks, Guillem. I'd like to get this resolved asap.
> On Sat, 2007-12-08 at 19:01:14 +, Neil Williams
Raphael Hertzog wrote:
> On Wed, 05 Dec 2007, Neil Williams wrote:
>> My first patch did exactly that - and failed on building a cross
>> compiler. gcc needs dpkg-shlibdeps to take notice of $ARCH in the
>> preparation of libgcc1-$arch-cross and other libraries used in the
Package: gcc-4.2
Version: 4.2.2-3
Severity: wishlist
gcc has a complex debian build layout and it isn't straightforward to
disable the generation of the various -doc packages when preparing test
builds or (in my case) cross builds. It would save a lot of build time
and upload time if gcc could sup
ption for the others.
When building Emdebian toolchains, we install libgcc1 (amongst others)
using apt-cross, then build binutils and gcc, then install in one
operation.
Try checking the source code of emchain from emdebian-tools.
--
Neil Williams
=
http://www.data-freedom.
cvs20070426) | 2.17cvs20070426-8
libgcc1 (>= 1:4.2-20070627-1) | 1:4.2-20070627-1
libgomp1 (>= 4.2-20070627-1) | 4.2-20070627-1
libc6 (>= 2.5-5) | 2.5-11
--
Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.c
22 matches
Mail list logo
