Quote:

Yes the reason for the _au.library is to have libraries where the function lookup table is fixed in some central location so no two different incompatible ports of a library with the same name could pop up. Currently these are located in the AROS svn repo but I do plan to move this to a separate location and port these libraries to all amiga-like OSes.
Currently the z_au.library is not a good base for m68k software to be run also on OS3.x. Until ABIv1 is fixed the interface may still change (and I do expect it to still change).

Sorry for seeing this thread so late, I only occasionally check AROS Exec.

Let me clarify some things I found out:


1. It's not the zlib.library that causes AROS68K (tried only this one) to crash. I am responsible for this rumour, since that was my first thought since it is a WarpOS Mixed Binary and my programs crashes almost instantly before they did anything visible.
But it is not. It is this Datatype Method that causes instant crash:

DTM\MethodID = #PDTM_READPIXELARRAY
DTM\pbpa_PixelData = \raw_ptr ; /* The pixel data to transfer to/from */
DTM\pbpa_PixelFormat = #PBPAFMT_ARGB ; /* Format of the pixel data (see "Pixel Formats" below) */
DTM\pbpa_PixelArrayMod = \bpr ; /* Number of bytes per row */
DTM\pbpa_Left = 0 ; /* Left edge of the rectangle to transfer pixels to/from */
DTM\pbpa_Top = 0 ; /* Top edge of the rectangle to transfer pixels to/from */
DTM\pbpa_Width = *bmhdp\bmh_Width ; /* Width of the rectangle to transfer pixels to/from */
DTM\pbpa_Height = *bmhdp\bmh_Height
If DoMethodA (*DTPic,&DTM) Then succ = True

I need this call in Amiblitz images loader, since internally Amiblitz handles all images as 32bit ARGB.

So, once this is fixed, I assume most Amiblitz3 Programs that deal with images will work on AROS68k.

2. About this z.library confusion:
"zlib" itself is unproblematic, platform independent code that just compresses or decompresses data in memory.
The problems we had here is that there are several Amiga ports of zlib, whose interfaces are different. Opening z.library instead of zlib.library would crash when the first function call is done and vice versa. Unfortunately, there are various incarnations of z.library across the Amiga-like platforms that are also incompatible. And since there is no way to query the interface for Amiga Shared Libraries, the program has no chance to complain about the wrong lib.
So the zlib situation is pretty much messed up on Amiga. I guess that was the reason for z_au.library? Unfortunately, this just increases the confusion, also I am not sure right now which one I should use.

In the thread on amiga-news Wanderer suspects that the problem is in the datatypes. Hmmmm. The datatypes are using the #?_au libraries while applications are using the normal libraries (if there's a OpenLibrary("z.library"...). I wonder if both can co-exist.

@all interested:

it seems to be a false alarm.
i have just tested the library in question:
http://aminet.net/util/libs/zlib-library.lha
using this test example:
http://aminet.net/package/util/pack/zlibexample
along with few own files and it seems to have worked, that means, it didnt crash.

Short explanation... the Amiblitz examples (almost) all crash on AROS 68k. I examined it and found out that it happened at the command "image_load" what is used almost everywhere. I asked Thilo (Wanderer) if he could look at it. He tracked it down to the zlib library (68k) that I had used in AROS Vision. It is a mixed library (68k/PPC) what seems to create the problem. He wanted to use z.library what would have worked but then it became obvious that there is a z.library on MorphOS that is not compatible so by changing to z.library his software would work on 68k and AmigaOS but not MorphOS (amiga-world seems to copy "DLL hell" from Windows). So there we are...

Short explanation as I'll soon leave for work: Under ABIv1 z, expat and bz2 are implemented as shared libraries. They're are named #?_au.library (au = amiga universal ) to avoid name clashes. I don't know why they are crashing under 68k. The libraries which are included in diskimage device aren't used on ABIv1.

@wawa

z.library is included with and used by diskimage.device.

I don't know why you would say that it's "deprecated", also this is the first time I've heard of this z_au.library (what's the au for?) that keeps getting mentioned in this thread.

The source code of my AROS z.library, bz2.library and expat.library is available here (z.library and bz2.library also build for m68k-amigaos):
http://sourceforge.net/p/diskimagedevice/code/HEAD/tree/src/

z.library has been depreciated i guess in favour of z_au, nevertheless a z.library will not be called by an app that requires zlib.library. either the app has to be rebuilt or a wrapper written or either the library renamed, if api compatible, otherwise it has to be ported.

Quote:
i've seen it in icaros 1.5. it's called z.library btw.

one of primary question is what applications take advantage of zlib.library, both on aros x86 (apparently none since the lib got removed) and on amiga (68k). as it seems the aminet version of zlib.library is unique of its kind, as it contains both 68k and warpos executive code within one file, which is likely what makes it crash on aros(68k) while it works on aos.

now, i see multiple solutions here depending what is the simplest and the cleanest:
1. if there was zlib.library on aros and it was api compatible with 68k/wos version, make it build again.
2. build pure 68k version of aminet zlib.library from the sources delivered with it. it should work on aros68k. x86 may not need native version if there is no applications for it and everybody uses z_au.library.
3. fix aros (68k) in order to accept the unique 68k/wos library construct
4...