Pole !!!

Thanks for making it as a shared object. I see OWB 1.5 uses it :)

Are "shared objects" one of the new features of OS4? What are the benefits compared to the Amiga's traditional "shared libraries"? Are they just Object Orientated libraries?

_________________
Author of the PortablE programming language.
It is pitch black. You are likely to be eaten by a grue...

@ChrisH

They aren't really "shared objects" in that they must be reloaded each time a new program uses them. They do allow easy porting of Linux libraries like SDL however.

@Thread

I've been waiting for this for a long time! This means that closed-source commercial software that uses SDL can now be published for AmigaOS 4!

@Samurai_Crow:

Quote:

They aren't really "shared objects" in that they must be reloaded each time a new program uses them. They do allow easy porting of Linux libraries like SDL however.

Right. They do still give the benefit of reusing the code/functionality between different programs. Useful because that code still only needs to be developed once instead of for each project, and because the functionality taken from the .so will be known to be the same in all sharing programs, i.e. predictable behaviour. Still worthy benefits IMO.

Maybe they could be called "reusable objects"?

Quote:

I've been waiting for this for a long time! This means that closed-source commercial software that uses SDL can now be published for AmigaOS 4!

Oh, cool. Got any?

Best regards,

Niels

Thanks Richard ! Now I can use these libraries in PointRider, it will be in the new release to come (2 more weeks !!). I hope they contain SDL, SDL_image and SDL_ttf !
This will make a good test.

GREAT work rich! How I have waited for this!
Corto: So pointrider is going multiplatform?

_________________
AOS4 Betatester, Peg2, G4@1ghz, Radeon 9250 256mb, 1gb RAM.

http://www.asciiarena.com
http://www.uprough.net

Great work Richard! Typical that I sold my µA1 before I had a chance to test this.
But good to have when I get a new machine.

_________________
/Harry

[SOLD] µA1-C - 750GX 800MHz - 512MB - Antec Aria case

Avatar by HNL_DK!

@nbache

Regarding commercial SDL programs? Nothing official yet but stay tuned.

Quote:

They aren't really "shared objects" in that they must be reloaded each time a new program uses them. They do allow easy porting of Linux libraries like SDL however.

You're correct that the in-memory instance isn't shared (at the moment - in future, the read-only portion of shared objects in memory could be). But the on-disk instance is.

I know that disk space and network bandwidth aren't at a premium these days, but, as is, the OS4.0 shared object system allows developers and users to benefit from potentially much smaller executable sizes. Plus, there's the really great advantage that programs don't need to be recompiled to benefit from bug-fixes and new features in the libraries that they dynamically link to.

Cheers,
Rich

I downloaded and installed both the shared object and the dev files, then tried to recompile my port of CGTerm but it doesn't look like it's using the .so file. The stripped executable is as large as before.

Is there a particular compiler or linker flag I should use?

Right now the flags I have in the makefile are:

CFLAGS=-newlib -O3 -Wall -ISDK:Local/newlib/include/SDL -DPREFIX=\"$(PREFIX)\"

LDFLAGS=-newlib -LSDK:Local/newlib/lib -lSDL -lauto -lm

_________________
AlexC's free OS4 software collection

AmigaOne XE/X1000/X5000/UAE-PPC OS4 laptop/X-10 Home Automation

Quote:

Plus, there's the really great advantage that programs don't need to be recompiled to benefit from bug-fixes and new features in the libraries that they dynamically link to.

I think that's the main point, the SDL library can be bugfixed and optimized in the future, and a user updating to the latest library will instantly have all the applications he already has running better and faster.

And I don't know about others, but depsite the fact that hard-drive space is not an issue these days, I do prefer smaller executable sizes, I mean why put the same several megabytes of code into every application when it's not necessary.

Excellent work Rich

Quote:

What are the benefits compared to the Amiga's traditional "shared libraries"?

They are not meant to replace the traditional shared libraries. They work exactly like UNIX shared libraries (semantically; as others have pointed out, the current implementation will not really share the code and static data).

Their purpose is:

- Provide an easier portability for UNIX libraries, which, let's face it, are radically different from the standard Amiga shared libraries.
- Provide the possibility to update what used to be static link libraries without recompilation (i.e. in this case SDL programs can benefit from new versions)
- Provide a means to satisfy the LGPL without your code becoming subject to it. Now you can write proprietary software that uses SDL on AmigaOS 4.0 (granted some people might consider this a drawback, but if you do, just consider the alternative of not having said program at all).

In the future, they'll be updated to provide real shared code and static data. This can come in very handy for things like the BOOST library which is a VERY big chunk of code which can be then shared between instances. Or libX11 for example.

_________________
Seriously, if you want to contact me do not bother sending me a PM here. Write me a mail

Initially I thought there was something wrong with the lha archive but it turned out to be the RESRAD: ram drive. Unarc fails when I try to unpack the archive to RESRAD: (It looks like the directory name and the "info" file get truncated and become the same name). Unpacking to RAM: works so this must be a problem with RESRAD:. Maybe you could notify the person who maintains the RESRAD: code.

Once I unpacked to RAM: the SDL files themselves seem OK.

_________________
X1000 with 2GB memory & OS4.1FE

@AlexC

It looks like you're still linking to the static version. I'd assume that the new archive has instructions on how to linked to the shared-object version. I haven't had time to check it out myself yet.

_________________
Join the Kea Campus - upgrade your skills; support my work; enjoy the Amiga corner.
https://keasigmadelta.com/ - see more of my work

@Xenic

That's because the last A1 release of the ramdrive device still uses DOS\0 and thus doesn't support long filenames :-/

Since then it has been changed to DOS\6 so it should work for Classic users as they have version 52.4, but A1 users may have to wait until the next update.


@Hans

I didn't find any documentation in the dev archive.

_________________
AlexC's free OS4 software collection

AmigaOne XE/X1000/X5000/UAE-PPC OS4 laptop/X-10 Home Automation

@Rogue:

Granted, there is some need for supporting the porting developers (and there is much done in the meantime), but I would love to see some (no, not some... much more!) support for the native developers, too, mainly regarding the field of API documentation and examples. That would be really great.

Regards

Okay, with Joerg's help I got it working.

Here's what I had to do:

- Upgrade from gcc 3.x to gcc 4.x
and
- Add "-use-dynld" to the linker flags

The resulting exe can't be stripped directly or it will not run properly (strip removes too much stuff), so to strip it I used the command:

strip `nm -u cgterm | sed "s/U /-K/"` cgterm -R.comment

and it works fine.

Without using the shared object, cgterm was 454808 bytes, now it's 151236 bytes

_________________
AlexC's free OS4 software collection

AmigaOne XE/X1000/X5000/UAE-PPC OS4 laptop/X-10 Home Automation

RAM: has supported long filenames (107 chars) since before I can remember.
At least since my A1200 and A3000.

_________________
Wanna try a wonderfull magical Amiga strategy game?
Total Chaos AGA

Quote:

RAM: has supported long filenames (107 chars) since before I can remember. At least since my A1200 and A3000.

Doesn't matter since RAM: and RAD: are entirely different things.

RAM: uses the RAM-Handler filesystem (a filesystem which stores file data in RAM).

RAD: uses ramdrive.device which is a trackdisk device driver which emulates a disk using a block of allocated memory, which means that the filename limit is dependant on what filesystem the device is mounted/formatted with.

Quote:

Granted, there is some need for supporting the porting developers (and there is much done in the meantime), but I would love to see some (no, not some... much more!) support for the native developers, too, mainly regarding the field of API documentation and examples. That would be really great.

There are autodocs for the API, and if that fails, people can always ask. However, there seems to be a generally low developer concentration currently - most people do ports, and this is right now the main source for software.

I agree that we could really use a new SDK with a few missing bits and pieces added, but since the day only has 48 hours (I think) there is little I can do about it.

_________________
Seriously, if you want to contact me do not bother sending me a PM here. Write me a mail