On 3/16/10, Adam D. Barratt wrote:
> > gem fails to build on armel with assembler errors. From the build log:
> >
> > g++ -c-I/usr/include/lqt -fopenmp -I/usr/include/ImageMagick
> -I/usr/include/lqt -I/usr/include/avifile-0.7 -I/usr/include/FTGL
> -I/usr/include/freetype2 -I.
On 9/21/09, Martin Guy wrote:
> I just tried this, and it's doing a misaligned word access:
Sorry, my mistake. It's pumping misaligned half-word (16-bit)
accesses, which again returns some form of garbage, probably either
the correct value if it's from the middle of a 4
On 9/21/09, Daniel Kahn Gillmor wrote:
> I should note that i have some concerns about tremor on armel in general
> that haven't been addressed by upstream (and i haven't been able to sort
> out):
>
> http://lists.xiph.org/pipermail/tremor/2009-April/001564.html
>
> Maybe this update will co
On 9/20/09, Luk Claes wrote:
> Maybe it's an option to revert using libvorbisidec-dev and use
> libvorbis-dev again on armel to fix the FTBFS of mpd?
>
> debian-arm and Joey Cc-ed so they can give input as I'm unsure if
> current ARM hardware does have floating point support to make this
> re
On the llvm-dev mailing list in message
http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-August/024629.html
Anton Korobeynikov says:
> 518592: Sounds like compiler / linker problem, it's not LLVM related at all
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject
_SHORT_CALL_ATTR_P'
libbackend.a(arm.o): In function `arm_is_longcall_p':
/home/martin/arm/llvm-gcc-4.2-2.5/build-gcc/gcc/../../llvm-gcc-4.2-2.5/gcc/config/arm/arm.c:3581: undefined reference to `ENCODED_LONG_CALL_ATTR_P'
collect2: ld returned 1 exit status
Definitions fished out of the 2.
Hi
The fix is very simple: the defaulting of this macro to 0 in
gcc/config/arm/arm.h, present in 2.2 has been omitted in 2.5.
The attached patch puts the defaulting clause back, the same as it was in 2.2
M
--- a/llvm-gcc-4.2-2.5/gcc/config/arm/arm.h 2008-11-03 01:44:11.0 +
+++
I've tried this on armv5te and armv4t hardware under armel-sid under
gdb and not, and in all cases it works fine, so I suggets closing this bug.
For further details of the specific failing environment, see
http://sourceforge.net/mailarchive/[EMAIL PROTECTED]&forum_name=ecls-list
M
--
To U
I just tried this, on a Thecus N2100 (armv5te) running sid and with a
tripwire set on misaligned data accesses (echo 5 >
/proc/cpu/alignment). Although the installation was very noisy,
spewing warnings while recompiling common-lisp-controller three times,
it turned out ok:
n2100:/home/martin/arm#
Actually your patch works fine, since D_A_B_CPU matches "arm" both on
arm and on armel. My apologies.
M
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
only) if you build with g++-4.2 or 4.3 the build segfaults the
first time it tries to run the interpreter.
MACHCONF is set to linux-arm on both arm and armel, so we invent another
config variable to distringuish between Debian arm and armel, and select
gcc-4.1 on arm only.
Martin Guy <[EMAIL PROTEC
On 7/28/08, peter green <[EMAIL PROTECTED]> wrote:
> > * adonthell:
> >
> > *** warning: prefs::read_adonthellrc: creating config file failed
> > Fatal Python error: exceptions bootstrapping error.
> >
>
> Workaround for this is to use python 2.4, I have posted a patch that does
> that to
> http:/
It also fails on arm-sid if compiled with gcc-4.2 in the very same
way: SEGFAULT at the same line in the build.
However, it succeeds if compiled with gcc-4.1 - see my AFNIX doc for
details of the hack.
Unfortunately to achieve this you need to patch one of the package's
config files to select gcc-
The moment in which it segfaults is the first time it runs the
interpreter it has just built, "axi", during the build, so I guess the
whole interpreter is broken. I've tried a debugging build by hacking
debian/rules:
<./cnf/bin/afnix-setup -o --prefix=/usr
>./cnf/bin/afnix-setup -g
2008/3/13, Luk Claes <[EMAIL PROTECTED]>:
> Martin Guy wrote:
> > Hi!
> > FWIW, the new arm port "armel" requires gcc-4.1.1, since its new ABI
> > support only made it, so we'd vote for rotd and gcc-4.1, and the gcc-4
> > patch for #297217 &quo
Hi!
FWIW, the new arm port "armel" requires gcc-4.1.1, since its new ABI
support only made it, so we'd vote for rotd and gcc-4.1, and the gcc-4
patch for #297217 "invalid lvalue in assignment" is sufficient to make
the current ancient version compile for us.
M
--
To UNSUBSCRIBE, email to
Yes, armel gives the same error message
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Package: rbot
Version: 0.9.10-1
Severity: serious
# apt-get install rbot
The following packages have unmet dependencies:
rbot: Depends: ruby (< 1.9) but 4.1 is to be installed
E: Broken packages
because rbot Depends: ruby (>= 1.8), ruby (<< 1.9)
but ruby switched to a versioning scheme which a
18 matches
Mail list logo
