OESF Portables Forum
Model Specific Forums => Sharp Zaurus => Zaurus - pdaXrom => Topic started by: lardman on August 19, 2004, 07:18:27 am
-
I get this error when trying to run things which used to work on 1.0.5.
For example Xcas/Giac (which was compiled on the skiffcluster) and swfplayer (which I cross compiled, probably with the pdaXrom toolchain - but I can't really remember).
Any ideas for a fix, or will I have to re-compile everything?
Cheers,
Si
P.S. A few more things which come up with the same error: gnuplot and xscreensaver
-
I'm getting this same error after installing gimp from www.pdaxrom.org/feed
-
Hello,
I have another undefined symbol when I run snes emulator (from davonz feed):
relocation error: /usr/bin/snes9x: undefined symbol: __umodsi3
Regards,
Fabian
-
and with "less" ... etc.
<Xumbi> has anyone else seen the "udivsi3" error with kathrin?
> less: relocation error: less: undefined symbol: __modsi3
what is this? some math libs? (div, mod, etc)
Scott
-
I've seen something similar to my error caused by different versions of libncurses.
That said, I don't think this can be ncurses as gnuplot works until it tries to create the X11 window to display the plot.
I had thought this was only X lib related, but if less does it too....
Si
-
I don't know if this is related, but I'm noticing strangeness when trying to install applications from www.pdaxrom.org/feed on RC2.
For example, I installed doomdemo from the feed onto my SD card. At the same time, it installed sdl, sdl-mixer and sdl-net to SD as well, when sdl and sdl-mixer were already installed to root (they came installed with RC2). After installing, doom runs fine, but it shouldn't have to install those dependencies.
Something similar happens with gimp, but far worse. It tries to install all kinds of packages that are already installed to root (like xfree430!). This is the worst for me, since I really wanted gimp to work with RC2. I'm going to try installing from the command line with --force-depends or something...
UPDATE: I installed gimp, libgimp, and gimp-plugins from the command line using -force-depends, when I try to run gimp I get the following:
gimp: relocation error: gimp: undefined symbol: __divsi3
-
I tried installing some packages and they all demanded themselves as dependencies, very useful.
Personally I think that the ROM should move away from the ipkg script and use something like the binary ipkg which OZ uses (as it's more stable and just works).
This isn't related to the undefined symbols errors mind you, just my opinion; I'm going to try the transplant over the weekend.
Si
-
It was suggested on IRC that I change libgcc_s.so.1 for an older version to get rid of these problems, unfortunately gnuplot (the only one I've tested thus far) still dies with the same undefined symbol error even with the new version.
On a brighter note, I've successfully transplanted the ipkg package from OZ3.3.5 and now I have a useful installation system (no offence to the ipkg script developers).
Si
-
Something similar happens with gimp, but far worse. It tries to install all kinds of packages that are already installed to root (like xfree430!). This is the worst for me, since I really wanted gimp to work with RC2. I'm going to try installing from the command line with --force-depends or something...
I have tried to install gnumeric(from feed2) and it keeps installing multiple files(some of which are needed, some of which are already installed to /), not just once but over and over again, I had to interupt it in the end.
I installed xmonobut with no problems
It is OK though, as this is an RC!
Simon
-
Yes, this problem does exist. I bumped into it when I tried to run freesci 0.3.3 from Familiar site. It installed perfectly, detected my game and when initializing graphics it gave relocation error: undefined symbol: __divsi3 . And I wanted to play my old games on Z so very much... Any suggestions (e.g. links to necessary libs) will be greatly appreciated.
-
Funnily enough I can run R (though I've not tried any graphics) and gnuplot only falls over when I try to create graphics. Other than the report of less not working, this all seems to be related to X11 somehow.
As an aside, which toolchain should one use to develop for RC2? Does the 1.0.5 toolchain/SDK produce working binaries?
Si
-
Si
Checkout the fixed bug list on pdaXrom.org, it's showing the undefined symbols bug as being fixed.
Can't wait for the final release
Jerry
-
Yeah, it was 'fixed' almost as soon as I put it on there.
The answer given was to not use anything older than the pdaXrom 1.0.5 SDK. All well and good, but I'd like to know what causes the problem (as I have lots of older stuff which I don't want to re-compile).
A bit more info about my gnuplot problem: gnuplot starts gnuplot_x11 which I assume does the plotting; if I type "plot sin(x)" in gnuplot, it dies but gnuplot_x11 is started and goes on living (and eating 40% of the processor cycles to boot).
Very strange.
Si
-
Hello,
gnuplot works with my RC2, I tried the plot sin(x) and load "all.dem" and no problems (many graphics). I just installed it from the feed.
Regards,
Fabian
-
i too am experiencing the sam divsi3 problem in vim, nano, and xchat.
-
Had this problem while porting code to embeded linux (ARM based but not zaurus).
I don't have the details at home, but you need to setup the LD_PRELOAD environment variable to load a number of shared libraries such as:
export LD_PRELOAD=/usr/lib/libgcc.so
You may need to also preload the shared math library.
If nm is available then you should be able to find which shared library you need to preload.
--
Still trying to convince the Wife to let me have a C860!
-
Does the above fix work?
Do any of the programs which people were having troubles with now work with RC3?
Cheers,
Si
-
Does the above fix work?
Do any of the programs which people were having troubles with now work with RC3?
At least Vim-6.2 (which gave the undefined symbol: __divsi3 error before) works, but you have to use export LD_PRELOAD=/lib/libgcc_s.so.
Thanks to damiandixon for providing the solution; can't have a Zaurus without Vim
-
The fix did not work for me trying to compile pari-gp on a C860 with RC3. I still get:
hidden symbol '__udivisi3' . . . . is referenced by DSO
after about 10 minutes of compiling. I found that /lib/libgcc_s.so was not executable while the other similar files in /lib were, but changing it to be executable made no difference. I'm new at this, so I could easily be doing something else wrong. Must other compile options be set? I assumed that the options and instructions for cross compiling on the pdaXrom site for the earlier SDK were not applicable to the new native SDK. Are some of them needed in any event?
RC3 seems terrific in general, but if sources generally don't compile without a lot of effort, I'll probably have to head back to pocketworkstation and apt-get, which got pari-gp and several other programs running without any difficulty. But if I can get a few standard options in place and then compile most programs, pdaXrom looks much better.
-
Going OT:
Is pari-gp not available in binary form already (http://wotan.algebra.math.uni-siegen.de/~countnumber/zaurus/ and http://modular.fas.harvard.edu/ipaq/) (http://modular.fas.harvard.edu/ipaq/)).
That said, it may be linked against a slightly later version of libc (it's said to run on OZ3.2 which is libc 2.2 based, but pdaXrom seems to use an older subversion so ymmv).
Edit: I suppose you may also want to re-compile to enable X11 plotting, in that case there are some compilation tips in the first link.
Si
-
Thanks for the leads, lardman. I had tried another binary, the .deb package, and compiling unsuccessfully. The binary at the first link failed for me in RC3 complaining about libqpe.so.1. (I suspect that I'm not the only newbie confused about the status of Qt under pdaXrom and that QtConfig tool.)
But the second link worked, so at least I have the gp calculator working on the Z, if not the graphing. It's a kick to see it spit out the exact several hundred digit value of 3578! almost instantly. As long as you keep away from floating point calculations, the Z is actually *fast*.
I'll keep working on learning the Z compiling rituals with the hints in the first link as I get the time. I should probably hold off on posting too many questions about compiling under pdaXrom till people have a chance to work with it under the final 1.1 release.