Opened 11 years ago
Closed 11 years ago
#3162 closed defect (worksforme)
r8340 ppc/dbox2 or old dreambox not startup
Reported by: | alborland | Owned by: | |
---|---|---|---|
Priority: | Please fill in | Component: | ! Please select... |
Severity: | Please fill in | Keywords: | |
Cc: | Sensitive: | no |
Description
build ok but if starting oscam on old ppc like dbox2 or dreambox-old:
/var/bin/oscam: symbol lookup error: /var/bin/oscam: undefined symbol: ashldi3
Change History (9)
comment:1 by , 11 years ago
comment:2 by , 11 years ago
please don't change everything ...
on all my dbox2's its run perfectly.
old dreams too
the error is not in svn ... toolchain ???
comment:3 by , 11 years ago
Here everything ok. Build with simplebuild and works perfect on my ppcold
comment:4 by , 11 years ago
Your toolchain is buggy. ashldi3 is a function that libgcc *should* provide.
https://www.informatik.uni-hamburg.de/RZ/software/gnu/gcc/gccint/Integer-library-routines.html
4.1.1 Arithmetic functions — Runtime Function: int __ashlsi3 (int a, int b) — Runtime Function: long __ashldi3 (long a, int b) — Runtime Function: long long __ashlti3 (long long a, int b) These functions return the result of shifting a left by b bits.
Fix your compiler, nothing Oscam can do about it if the compiler can't perform simple subtraction (or for that matter bit shift) without emitting broken code.
comment:5 by , 11 years ago
comment:6 by , 11 years ago
If we are to force the compiler should this do the trick long blah = (long)muah << (int)3
.
comment:7 by , 11 years ago
So as hapeba said that it is a toolchain or compilation error I vote for closing this. Any other opinion?
comment:8 by , 11 years ago
@Admin I also vote for closing this. Whit the current fast evolution it's important to have up to date compilers. So alborland should consider to update's his cross compile toolchains since a lot of code used in oscam has being improved to the new standards required for up the up to date linux kernels and library's used. Of which some parts do require up to date compilers.
This has probably something todo with this code introduced in r8206:
These macros (which are defined in the standard headers) somehow expand to use ashldi3 function and dbox2 strips this function out of it's code (which is a problem since always). I've no idea how to fix that, probably we would need to copy the complete implementation into OSCam instead of using what the standard headers provide...