Package: gnat-4.6
Followup-For: Bug #687642
On amd64, /usr/lib/gcc/x86_64-linux-gnu/4.6/adalib/ contains
libgnarl.a
libgnarl.so -> ../../../../../x86_64-linux-gnu/libgnarl-4.6.so.1
On armhf, /usr/lib/gcc/arm-linux-gnueabi/4.6/adalib/ contains
libgnarl-4.6.a -> libgnarl.a
libgnarl.a
libgnarl.so ->
Processing commands for cont...@bugs.debian.org:
> affects 687642 libtemplates-parser libaws
Bug #687642 [gnat-4.6] gnat-4.6: on armel armhf, gcc -shared reads
libgnarl-4.6.a instead of .so
Added indication that 687642 affects libtemplates-parser and libaws
> thanks
Stopping processing here.
Ple
Processing control commands:
> retitle -1 gnat-4.6: on armel armhf, gcc -shared reads libgnarl-4.6.a instead
> of .so
Bug #687642 [gnat-4.6] gnat-4.6: libgnarl-4.6.a should be rebuilt with -fPIC,
libaws FBTFS
Changed Bug title to 'gnat-4.6: on armel armhf, gcc -shared reads
libgnarl-4.6.a inste
Package: gnat-4.6
Version: 4.6.4-1
Followup-For: Bug #687642
Control: retitle -1 gnat-4.6: on armel armhf, gcc -shared reads libgnarl-4.6.a
instead of .so
Hello. Here is a reproducer, tested on abel.debian.org (armel).
The bug may present other symptoms: ld will complain about missing
symbols, b
Am 21.08.2013 20:55, schrieb YunQiang Su:
> This new one won't define TARGET for control.m4 when
> with_deps_on_target_arch_pkgs=yes is used.
why? TARGET is used in conditionals in the control.m4, so it has to be defined
for every cross build. Am I missing something?
the patch for debian/rules.de
Am 26.08.2013 22:33, schrieb Felix Salfelder:
> Package: libppl0.12-dev
> Version: 1:1.0-7
> Severity: important
>
> Dear Maintainer,
>
> ppl.hh contains a remark about a transition concerning the numeric_limits
> declaration.
>
> /*
> [..]
> \note
> The PPL provides the specializations of
Am 23.08.2013 00:26, schrieb Thorsten Glaser:
> Matthias Klose dixit:
>
>> yes, I do reject this.
>
> I see. Would you please…
>
>>> “for the time being”? If so, would you accept a patch
>>> that just disables -fauto-inc-dec on m68k *always*,
>>> even in the cases where it doesn’t ICE? (one-line
Mikael Pettersson writes:
> > pr49847.diff is not applied yet even though it seems
> > to be clear =E2=80=93 I=E2=80=99ve prodded them again a month ago
> > and have not received any response yet; maybe just
> > nobody feels responsible?
>
> I was hoping for some gcc maintainer to speak up a
8 matches
Mail list logo
