Who's Online |
120 user(s) are online ( 79 user(s) are browsing Forums)
Members: 1
Guests: 119
VooDoo,
more...
|
|
Headlines |
-
snes9x.zip - emulation/gamesystem
Apr 29, 2024
-
hle-pokercard.lha - game/card
Apr 29, 2024
-
mce.lha - game/utility
Apr 29, 2024
-
amiarcadia.lha - emulation/gamesystem
Apr 28, 2024
-
ifarchive_dl.lha - utility/script
Apr 28, 2024
-
kt_scripts.lha - utility/script
Apr 28, 2024
-
stream.lha - utility/benchmark
Apr 27, 2024
-
thumbnailmaker.lha - video/misc
Apr 26, 2024
-
theme_list.lha - utility/misc
Apr 23, 2024
-
faac.lha - audio/convert
Apr 22, 2024
|
|
|
|
Re: Dynamic linker problem?
|
Posted on: 2010/4/17 22:14
#21
|
Just popping in
|
@ZeroG
But does it solve the above mentioned problem?
And I'm not a registered user. Maybe I will be, when the X1000 is available. But for the moment I have to live with my outdated beta version.
|
|
|
|
Re: Dynamic linker problem?
|
Posted on: 2010/4/17 16:21
#22
|
Just popping in
|
I contacted Hans-J?rg Frieden privately and he said that recursive symbol resolving with shared objects should work, provided the elf.library is new enough (which version? I have 52.4) and that the shared objects have a V2 tag. I.e. "objdump -p" must show the tag: 0x6000000e 0x2
But even with the latest SDK the problem remains. All gcc shared objects do not have the V2 tag: libgcc.so, libstdc++.so, libssp.so. So, as far as I understood, the dynamic linker still requires you to specify all libraries on the linker command line... :(
|
|
|
|
Re: Dynamic linker problem?
|
Posted on: 2010/4/15 9:22
#23
|
Just popping in
|
@ssolie Ok, so it's a known problem which one should be aware of.
Although I would tend to regard that as a bug of the dynamic-linker in elf.library. Any other operating system using ELF shared objects can deal with it. Usually you only have to resolve the references at link-time which come from your program, not from shared objects.
Are there plans to fix that?
|
|
|
|
Dynamic linker problem?
|
Posted on: 2010/4/14 22:10
#24
|
Just popping in
|
I'm having problems when linking with a shared objects which has references to another shared object. It seems to be important to resolve all those library dependencies at link-time, otherwise the executable crashes.
As an example I want to link with SDL_mixer.so:
This works: -lSDL -lSDL_mixer -lFLAC -lsmeg-0.4 -logg -lvorbisfile -lvorbis -lmikmod -lpthread -lstdc++ -lgcc
But this does not (although all references of my executables have been resolved): -lSDL -lSDL_mixer
I think it's a problem of the dynamic linker, which has to resolve all dependencies to other shared objects automatically. Is it a known problem and there was a directive to use the workaround from above? Will it be fixed?
|
|
|
|
Re: Shared objects and OS4/classic
|
Posted on: 2010/4/6 15:15
#25
|
Just popping in
|
@xeron
Ok, thanks. That's what I guessed.
But how many OS4/classic users are there?
Was there ever an official version, which you could buy (sorry, I don't remember, as I was using the developer-version)?
It requires not much extra effort for me to link statically instead of dynamically, so those old systems could be easily supported if it makes sense at all. But I'm still unsure about the making-sense part. ;)
|
|
|
|
Shared objects and OS4/classic
|
Posted on: 2010/4/6 9:53
#26
|
Just popping in
|
Hi,
I was not able to follow all the news over the last months but I remember that OS4 development for the classic (PowerUp-based) Amigas had stopped at some point?
Since OS4.1 it became more and more common to link your programs dynamically against shared objects, which is a great feature. But does anybody know whether the latest OS4 for classic Amigas supports it?
And is this a problem at all? I do not remember how official these OS4/classic versions were. How many OS4/classic users do exist? Is it enough to consider not using shared objects and to link statically to guaranteee compatibility with those earlier OS4 releases?
|
|
|
|
Re: A-EON Interview Part 3..
|
Posted on: 2010/4/2 19:49
#27
|
Just popping in
|
Very nice system. I guess I will have to buy it... ;)
And finally a useful firmware! Congratulations!
|
|
|
|
Re: Link problem (relocation truncated to fit)
|
Posted on: 2010/3/19 23:42
#28
|
Just popping in
|
@alfkil
A PLTREL24 relocation is used to call a subroutine through a jump-slot in the .plt section. When linking with a shared object at run time the PLT (procedure linkage table) jump slots will be filled with vectors to the functions from the shared object.
PLTREL24 and the normal REL24 are mainly used for PPC "bl" instructions (used as a relative branch into a subroutine). The region which can be reached by such a branch is within a signed 26-bit value (the two least significant bits are always zero), which means +/- 32MB.
It seems that your program is so big that the distance to the .plt is not within 32 MB from your caller.
I don't know the linker script you are using, but for the PPC architecture the .plt is usually stored together with .bss sections, which means that the size of the data adds to the distance and the 32MB are easily exceeded...
|
|
|
|
Re: SDL_Sound
|
Posted on: 2010/3/16 10:14
#29
|
Just popping in
|
Quote: spotUP wrote: what are you working on btw?
I do not want to reveil any details before I even started. But it's a port of a nice closed-source game.
|
|
|
|
Re: SDL_Sound
|
Posted on: 2010/3/16 10:07
#30
|
Just popping in
|
Quote: corto wrote: I've just uploaded here the libraries I compiled. I hope it will help and ... work ! The library supports libmodplug.
Thanks a lot! Much appreciated! :) I made a quick test and got it linking with vbcc. So I can turn to more important tasks now. But it would be nice when some group of programmers comes together to maintain all SDL libraries for OS4 (please understand that I cannot be one of them). Optimal would be when all SDL libraries are an integral part of OS4 (as the SDL base library already seems to be?) to cope with their importance for many OS4 ports.
|
|
|
|
Re: SDL_Sound
|
Posted on: 2010/3/15 16:18
#31
|
Just popping in
|
Quote: there is. i am running an amiupdate sdk repository, it has all the third party libs and it installs it for you.
URL? Quote: whining about stuff doesn't work here, there are to few good men around. if you want something done here, you have to rely on yourself, ask questions, get knowledge, do stuff on your own. that's what i always did. you are pretty much on your own, and that is part of the fun. You don't have to tell me that. The problem is that I'm doing too much myself (I even wrote my own compilers, linkers and assemblers ;). Just wanted to make sure if somebody else already did the work. Quote: ps. what was not clean with the other port from evil rich? it always worked for me. it's nice to see sdl being updated again though, and it is not perfect, but it works for most things.
I didn't really test it, because I guess it is obsoleted by the new (semi-official) SDL port where the Friedens are involved. And it doesn't use shared objects.
|
|
|
|
Re: SDL_Sound
|
Posted on: 2010/3/15 15:23
#32
|
Just popping in
|
Quote: spotUP wrote: i have sdl_sound ported here... i got it from toaks some years ago, but i promised not to spread it. :/ i have done a couple of ports with it.
Then it's not a shared object, which I would prefer. Quote: it shouldn't be that hard to port though.
No, of couse it isn't. But I don't have the time to do everything myself when just doing a simple port. Quote: haha and regarding os4 sdl being in a sad state because a third party library ain't ported, that is seldomly used, come on!
Unfortunately it's not just SDL_sound, but everything. There is now a clean port of the main library from H.J.-Frieden and Peter Gordon, but you have to collect the rest from multiple sources (with different quality and compatibility). Some support shared objects, some do not. There should be one source and one development team for SDL on OS4.
|
|
|
|
Re: SDL_Sound
|
Posted on: 2010/3/15 10:25
#33
|
Just popping in
|
Quote: corto wrote: Yesterday evening, I noticed HunoPPC about this question. As he has ported many SDL games on OS4, he knows well the availability and the problems of these libraries. He could have a good advice. Else I am afraid nobody has already ported/used SDL_sound ...
Thanks. That's what I feared. I didn't expect to find SDL for OS4 in such a sad state after so many years. :( Quote: I've just tried to compile SDL_sound this morning without the support of some audio formats but it still stops linking playsound. At the moment, I don't know why ...
Thanks for the try. Much appreciated. Maybe have a look at the error message? ;)
|
|
|
|
Re: SDL_Sound
|
Posted on: 2010/3/13 23:18
#34
|
Just popping in
|
Yes, but then I would still need SDL_Sound to be able to port a program using it. Or I also have to port SDL_Sound myself, using this libmodplug, which I would like to avoid.
|
|
|
|
SDL_Sound
|
Posted on: 2010/3/13 21:00
#35
|
Just popping in
|
I need SDL_Sound with libmodplug support. Does it exist anywhere? Or is somebody working on it?
|
|
|
|