Help with building SDL_image shared library

	Bottom Previous Topic Next Topic
Register To Post

MickJT

Posted on: 2012/9/24 3:14 #1

Just can't stay away

Hi,

I'm having major issues getting this to work. Version 1.2.10 doesn't work either. I must never have tested that.

Any image that requires a 3rd party library to load, such as libjpeg/libtiff/libpng, it crashes in IMG_LoadTyped_RW. I'm using the included showimage program to test it.

I've tried a range of compiling options, and building the library by hand without success.

About the only thing I can think of that I haven't tried, is using an older SDK. sdl_image 1.2.6 is on OS4Depot, but the SDK that that would have been compiled with is no longer available for download. I can't get my own build of 1.2.6 to work either.

If anyone can figure out what the problem is, I'd be grateful. There's no issue with the static library. You do need to disable dynamic loading though.

ChrisH

Re: Help with building SDL_image shared library

Posted on: 2012/9/24 9:11 #2

Home away from home

I guess that a CrashLog might be helpful?

Author of the PortablE programming language.

salass00

Re: Help with building SDL_image shared library

Posted on: 2012/9/24 14:36 #3

Just can't stay away

Well according to addr2line the ISI is likely from this line:
image = supported[i].load(src);

Maybe if I add some debug output here I can find out why it crashes...

salass00

Re: Help with building SDL_image shared library

Posted on: 2012/9/24 14:59 #4

Just can't stay away

Problem appears with the linking of the libpng/libjpeg/libtiff libraries. If I put some debug output into IMG_InitJPG() and try to display a JPG image with "showimage" it says that all the libjpeg functions are NULL:


int IMG_InitJPG()

{

    if ( lib.loaded == 0 ) {

        lib.jpeg_calc_output_dimensions = jpeg_calc_output_dimensions;

        lib.jpeg_CreateDecompress = jpeg_CreateDecompress;

        lib.jpeg_destroy_decompress = jpeg_destroy_decompress;

        lib.jpeg_finish_decompress = jpeg_finish_decompress;

        lib.jpeg_read_header = jpeg_read_header;

        lib.jpeg_read_scanlines = jpeg_read_scanlines;

        lib.jpeg_resync_to_restart = jpeg_resync_to_restart;

        lib.jpeg_start_decompress = jpeg_start_decompress;

        lib.jpeg_std_error = jpeg_std_error;

        fprintf(stderr, "lib.jpeg_calc_output_dimensions: 0x%08x\n", lib.jpeg_calc_output_dimensions);

        fprintf(stderr, "lib.jpeg_CreateDecompress: 0x%08x\n", lib.jpeg_CreateDecompress);

        fprintf(stderr, "lib.jpeg_destroy_decompress: 0x%08x\n", lib.jpeg_destroy_decompress);

        fprintf(stderr, "lib.jpeg_finish_decompress: 0x%08x\n", lib.jpeg_finish_decompress);

        fprintf(stderr, "lib.jpeg_read_header: 0x%08x\n", lib.jpeg_read_header);

        fprintf(stderr, "lib.jpeg_read_scanlines: 0x%08x\n", lib.jpeg_read_scanlines);

        fprintf(stderr, "lib.jpeg_resync_to_restart: 0x%08x\n", lib.jpeg_resync_to_restart);

        fprintf(stderr, "lib.jpeg_start_decompress: 0x%08x\n", lib.jpeg_start_decompress);

        fprintf(stderr, "lib.jpeg_std_error: 0x%08x\n", lib.jpeg_std_error);

    }

    ++lib.loaded;



    return 0;

}

corto

Re: Help with building SDL_image shared library

Posted on: 2012/9/24 20:46 #5

Not too shy to talk

MickJT: I a pretty sure you have in your system mixed things like headers for jpeg library v6 with a shared object that could be in v8.
The compatibility is broken between these versions, due to new fields in the middle of others, in some structures exported to the includes.

I wonder if there is not other compatibility problems about libpng and libz.

It was a nightmare when I had problem with my projects, when I found the cause for JPEG.

That's not always a good idea to upload new versions of critical libraries on os4depot.
And unfortunately, shared objects don't ease to make things clear at the moment (more or less linked between the SDK and SOBJS:, problems to manage versions and keep things compatible, ...).

salass00

Re: Help with building SDL_image shared library

Posted on: 2012/9/24 21:05 #6

Just can't stay away

@corto

The issue that jpeg library API is incompatible between versions isn't really such a big deal because the name of .so file changes with versions that break backwards compatibility (same with libpng and many other shared objects).

Something I've been thinking about though is that it might be a good idea to have a user archive for libs like this that includes the latest revision of all these incompatible .so files so that you don't end up with programs you can't use because the latest .so file available is a newer incompatible version and the program in question is compiled for an older version and maybe won't be updated for one reason or another.

broadblues

Re: Help with building SDL_image shared library

Posted on: 2012/9/24 23:51 #7

Home away from home

Quote:

The issue that jpeg library API is incompatible between versions isn't really such a big deal because the name of .so file changes with versions that break backwards compatibility (same with libpng and many other shared objects).

All available libjpeg.so are named just that. "libjpeg.so" this breaks the concept of linking against numbers libs, because the libs aren't numbered.

That combined with the fact that the SDK has 6.2 headers only, causes all sorts of trouble.

To avoid this I built my own libjpeg6.2 and built it into PIL rather than link it externally.

Blender For OS4.x : Blues : Walker Broad

MickJT

Re: Help with building SDL_image shared library

Posted on: 2012/9/25 3:13 #8

Just can't stay away

Quote:

ChrisH wrote:
I guess that a CrashLog might be helpful?

I probably should have but didn't think it'd be useful, since no-one else had the program to use addr2line with.

Quote:

salass00 wrote:

Well according to addr2line the ISI is likely from this line:
image = supported[i].load(src);

Maybe if I add some debug output here I can find out why it crashes...

That was my process too.

Quote:

Problem appears with the linking of the libpng/libjpeg/libtiff libraries. If I put some debug output into IMG_InitJPG() and try to display a JPG image with "showimage" it says that all the libjpeg functions are NULL:

I forgot to check there. I thought that section was only used when dynamic loading was enabled (I spotted the "#endif /* LOAD_JPG_DYNAMIC */" and thought the text above wasn't used).

I had traced it to:

cinfo.err = lib.jpeg_std_error(&jerr.errmgr);

but from looking at your post, the problem isn't there, but due to the functions being NULL. I don't know if I'm experienced enough to figure out why, but I'll have a look. In the meantime, if you can see a fix, please let me know.

Quote:

corto wrote:

MickJT: I a pretty sure you have in your system mixed things like headers for jpeg library v6 with a shared object that could be in v8.

I'm certain that's not the case. I'm very careful about these things, and remove old headers and libraries prior to compiling newer versions. I checked again though, and there's no issue there.

Quote:

That's not always a good idea to upload new versions of critical libraries on os4depot.

They all have different filenames (unless you make a softlink). Unless you overwrite the ones in SObjs: and make a link to .so, there shouldn't be a problem. I do that, but so far I haven't had an issue. I'm not aware of any software that uses the shared objects that come with OS4.1, but I might just be naive about that. Any examples?

Quote:

salass00 wrote:

@corto

The issue that jpeg library API is incompatible between versions isn't really such a big deal because the name of .so file changes with versions that break backwards compatibility (same with libpng and many other shared objects).

I agree with that, and all versions I've uploaded have different file names. There is the issue with OS4Depot wanting just 1 archive per library or program. I could upload to Aminet too in the future, if people want me to do that. I haven't been storing previous versions when just updating my own uploads. They can be built again if needed to.

Quote:

Something I've been thinking about though is that it might be a good idea to have a user archive for libs like this that includes the latest revision of all these incompatible .so files so that you don't end up with programs you can't use because the latest .so file available is a newer incompatible version and the program in question is compiled for an older version and maybe won't be updated for one reason or another.

Unfortunately, the general rule for OS4Depot is that older versions need to be replaced. I'd been hoping that either a program is linked with the version included with OS4.1 (though those sobjs get updated too) or the .so is included with the program.

I'm don't want to feel guilty or blame myself for updating libraries. Do people want me to keep older versions in the same archive, though it would increase the archive size?

Quote:

broadblues qrote:

All available libjpeg.so are named just that. "libjpeg.so" this breaks the concept of linking against numbers libs, because the libs aren't numbered.

The last two I've uploaded have been .so.11 and .so.12. In recent times, since learning how to get the right sonames, I've been careful in making sure that the sonames differ when needed to. The exception so far has been libmp3lame.so.0. On many platforms it's been .so.0 for a long time. I don't know if that's on purpose or not.

I have been editing libtool for deplibs_check_method="pass_all" and version_type=freebsd-elf

Back on topic though, this isn't just about libjpeg, if I disable libjpeg/libtiff and only use libpng, I also get an ISI, but I haven't tried tracing that back any further than IMG_LoadTyped_RW.

FWIW, yesterday I wiped my SDK, reinstalled it. Installed just libjpeg, then booted off of the OS4.1 installation disc, ran the SDK startup script, and compiled SDL_image with the live CD, and it still has the same problem. There's no mismatch of headers.

If I fiddle around with old versions and purposely mismatch, I can get the old SDL_image 1.2.6 .so to work with libjpeg.so.12, but not if I compile 1.2.6 myself.

Edited by MickJT on 2012/9/25 3:29:03
Edited by MickJT on 2012/9/25 3:31:02
Edited by MickJT on 2012/9/25 3:37:01
Edited by MickJT on 2012/9/25 3:42:26
Edited by MickJT on 2012/9/25 3:43:50
Edited by MickJT on 2012/9/25 3:48:51
Edited by MickJT on 2012/9/25 5:35:19
Edited by MickJT on 2012/9/25 5:57:41

MickJT

Re: Help with building SDL_image shared library

Posted on: 2012/9/25 5:55 #9

Just can't stay away

I managed to work around it by removing "lib." from anything that starts with lib.jpeg in IMG_jpg.c, and commenting the lines that salass00 quoted, but still letting it set lib.loaded to 1 if it is 0.

Thanks Fredrik. Is there a better solution? I assume I'll have to do a similar "fix" for png and tiff.

I don't understand why the static build was OK when this wasn't.

salass00

Re: Help with building SDL_image shared library

Posted on: 2012/9/25 8:17 #10

Just can't stay away

@MickJT

Quote:

I managed to work around it by removing "lib." from anything that starts with lib.jpeg in IMG_jpg.c, and commenting the lines that salass00 quoted, but still letting it set lib.loaded to 1 if it is 0.

If that works then it can call the functions normally but for some reason can't get pointers to functions in libjpeg.so so it must be an issue with relocation (elf.library). Since it works with static libSDL_image it's probably something to do with compiling it as PIC. It would probably be a good idea to post about it on the support forum since it likely may be a bug in elf.library.

Quote:

Thanks Fredrik. Is there a better solution? I assume I'll have to do a similar "fix" for png and tiff.

Yes, since they use the same method they will have to be modified as well.

BTW I just remembered that SDL_LoadObject() support should be enabled now in the latest OS4 SDL release so it might worth a try to leave dynamic loading enabled for the shared object build at least:
http://code.google.com/p/os4sdl/issues/detail?id=13&can=7

If it works then it would be the best solution since it will only load the libjpeg/libpng/... so files only when/if they are needed.

MickJT

Re: Help with building SDL_image shared library

Posted on: 2012/9/25 8:46 #11

Just can't stay away

The latest SDL still doesn't have SDL_LoadObject implemented.

SDL_image also doesn't seem to have big endian support for WebP images. I've sent off an e-mail about that. I managed to modify the code so it displays one particular test image properly, but whether other images with alpha channels and transparency will work, I don't know.

I'll wait for a response first. Chances are I'll upload it to OS4Depot with WebP support disabled.

In other news, I uploaded the latest libwebp to OS4Depot.

Quote:

If that works then it can call the functions normally but for some reason can't get pointers to functions in libjpeg.so so it must be an issue with relocation (elf.library)

I don't pretend to know much about C/C++ at all. Are you sure it would be elf.library and not something else?

elfpipe

Re: Help with building SDL_image shared library

Posted on: 2013/8/28 23:00 #12

Just can't stay away

The cause of the problem is versioned symbols. And yes the problem is elf.library. If you objdump -T libjpeg.so.9 you will see, that the symbols are prefixed (or postfixed?) with 'LIBJPEG_9.0'. I have custom-built a version of libjpeg.so, that doesn't have those, it is included in libpoppler on os4depot. It's also v.9, so it should work out of the box.

EDIT: Ok, I thought this was a new thread, my bad... :)

Register To Post
	Top Previous Topic Next Topic

Currently Active Users Viewing This Thread: 1 ( 0 members and 1 Anonymous Users )