Jump to content

  • Log In with Google      Sign In   
  • Create Account


link libpng

  • You cannot reply to this topic
11 replies to this topic

#1 FGFS   Members   -  Reputation: 157

Like
0Likes
Like

Posted 14 April 2014 - 09:19 AM

Hi
I try to package (Linux/c++/rpath) some libs with my app, as I doubt sdl1.2 will be around for very much longer. Now libsdl_image depends on libpng, but all I find are symlinks back and forth libpng12.so.0 etc. and only a libpng12.a but no .so (only symlinks on Ubuntu).
How to link to .a or where to find the .so? Do I need to include that at all? Is it enough if I pack/ship with my app only libsdl_image as there are also other libsdl dependencies like tiff etc. Are those dependencies only needed to compile libsdl?
Many thanks



Sponsor:

#2 georger.araujo   Members   -  Reputation: 595

Like
0Likes
Like

Posted 14 April 2014 - 09:24 AM

Hi
I try to package (Linux/c++/rpath) some libs with my app, as I doubt sdl1.2 will be around for very much longer.

 

Why do you think so? While I don't anticipate any new development on SDL 1.2, I also don't see it being killed anytime soon.



#3 FGFS   Members   -  Reputation: 157

Like
0Likes
Like

Posted 15 April 2014 - 12:35 AM

It happens often, for ex. I need an older python for Blender 2.49 and I'm pretty sure that I won't find that package for Ubuntu 14.04 anymore.

 

Even if I don't ship them for now, I want to have them ready. Thanks for answering my dependencies question.



#4 georger.araujo   Members   -  Reputation: 595

Like
0Likes
Like

Posted 15 April 2014 - 08:50 AM

It happens often, for ex. I need an older python for Blender 2.49 and I'm pretty sure that I won't find that package for Ubuntu 14.04 anymore.

 

Even if I don't ship them for now, I want to have them ready. Thanks for answering my dependencies question.

 

You're comparing apples to oranges here. Supporting a number of different Python releases is one thing, supporting two SDL versions is another thing entirely.

 

Blender 2.49 was released almost 5 years ago, SDL 1.2.15 is deprecated - time to consider upgrading.

 

As for your thanks, take the time to thoroughly read How To Ask Questions The Smart Way. If you're the TL;DR kind of person, at the very least read the On Not Reacting Like A Loser section and learn to become appreciative of people who get out of their way to try and help you.



#5 FGFS   Members   -  Reputation: 157

Like
0Likes
Like

Posted 16 April 2014 - 12:02 AM

Seems you can't understand my question.



#6 Ectara   Crossbones+   -  Reputation: 2398

Like
1Likes
Like

Posted 16 April 2014 - 12:15 AM


You're comparing apples to oranges here. Supporting a number of different Python releases is one thing, supporting two SDL versions is another thing entirely.

If I may throw my two cents into here, SDL 1.2 and SDL 2 have a decently different interface, from what I could tell reading about v2. Likewise, Python <= 2 and Python >= 3 have some significant differences that cause applications to fail to run across multiple versions, and they get installed in parallel to combat this: on my machine I have python2.6, python2.7, python3.3, python3.3m, python3.4, and python3.4m installed (the m variants using a different ABI, causing another incompatibility).

 

So, I'd say there are some similarities between needing to support a particular version of one and needing to support a particular version of another.

 

As for why, I don't have the explanation, and it wasn't provided. I assume it's a good one. In the case of Blender, as noted before, different Python versions aren't 100% compatible, so if someone wrote a good Blender plugin a long time ago and never updated it, you wouldn't be able to update Blender (or use a new Python version) and still use the plugin. It sounds as if his application is already done, so upgrading to SDL 2 is a little work-intensive.



#7 georger.araujo   Members   -  Reputation: 595

Like
0Likes
Like

Posted 16 April 2014 - 09:50 AM

Seems you can't understand my question.

 

Rather you don't understand the internet.

When you ask a question on this forum, it doesn't go into an oracle that takes your question as input and outputs an answer. Other users - human beings - will read it, and you can get a detailed answer, a comment, or even no answer at all. You're not entitled to an answer. Get over it.

 

I stand by what I said: SDL 1.2 isn't going away anytime soon. There are many games and applications which rely on it. On top of that, SDL 2 was released less than a year ago; packages don't get deprecated so quickly in Linux distributions.



#8 georger.araujo   Members   -  Reputation: 595

Like
0Likes
Like

Posted 16 April 2014 - 09:55 AM

 


You're comparing apples to oranges here. Supporting a number of different Python releases is one thing, supporting two SDL versions is another thing entirely.

If I may throw my two cents into here, SDL 1.2 and SDL 2 have a decently different interface, from what I could tell reading about v2. Likewise, Python <= 2 and Python >= 3 have some significant differences that cause applications to fail to run across multiple versions, and they get installed in parallel to combat this: on my machine I have python2.6, python2.7, python3.3, python3.3m, python3.4, and python3.4m installed (the m variants using a different ABI, causing another incompatibility).

 

So, I'd say there are some similarities between needing to support a particular version of one and needing to support a particular version of another.

 

As for why, I don't have the explanation, and it wasn't provided. I assume it's a good one. In the case of Blender, as noted before, different Python versions aren't 100% compatible, so if someone wrote a good Blender plugin a long time ago and never updated it, you wouldn't be able to update Blender (or use a new Python version) and still use the plugin. It sounds as if his application is already done, so upgrading to SDL 2 is a little work-intensive.

 

 

Good point. That said, as for the Python/Blender argument: having 6 releases of Python installed is a mess. As for SDL, I don't think SDL 1.2 is going away anytime soon.



#9 Karsten_   Members   -  Reputation: 1201

Like
0Likes
Like

Posted 16 April 2014 - 10:41 AM

As I recall, how SDL_image utilizes image libraries it is all down to compile flags.

In the SDL_image src directory, run
 

./configure --help

By default it dynamically loads them at runtime but you can also link them to SDL_image at compile time.

Also.. since SDL 1.2 is more portable. I predict it will actually outlive 2.0. Especially since it has a much more stable API and has no input from companies like Valve.
SDL 1.2 is currently the only version that Emscripten supports too and it is surprising how little interest there has been in a SDL 2.0 API.

 

If you are worried about future portability, perhaps avoid SDL_image completely and just use libpng to load in your images (which is what I do). A good example is (http://zarb.org/~gc/html/libpng.html)


Edited by Karsten_, 16 April 2014 - 10:46 AM.

Mutiny - Open-source C++ Unity re-implementation.
Defile of Eden 2 - FreeBSD and OpenBSD binaries of our latest game.


#10 FGFS   Members   -  Reputation: 157

Like
0Likes
Like

Posted 16 April 2014 - 11:47 PM

Thanks for all input. I don't recall why I didn't use libpng, probably because you have to link statically.

 

I'll try a vanilla Ubuntu 14.04 in virtualbox and see if I can get all needed dependencies loaded/packed from: . by using ldd *

 

So, I can also check for python 2.6 and if all goes right, finally replace 12.04.


Edited by FGFS, 16 April 2014 - 11:48 PM.


#11 Karsten_   Members   -  Reputation: 1201

Like
0Likes
Like

Posted Yesterday, 07:33 AM

see if I can get all needed dependencies loaded/packed from: . by using ldd *

 

Ah, since I believe SDL_image loads image libraries at runtime (they are not linked in statically or dynamically by default) it is unlikely that they will show up by ldd.

 

You might be able to use something like trace, gdb (or other debugger) to find what libraries have been loaded by a test application.


Mutiny - Open-source C++ Unity re-implementation.
Defile of Eden 2 - FreeBSD and OpenBSD binaries of our latest game.


#12 FGFS   Members   -  Reputation: 157

Like
0Likes
Like

Posted Today, 01:36 AM

It's a shared lib, hence no problem with ldd. Works fine, only added 2-3 libs to . and done. Also there's a python 2.6 from:

 

https://launchpad.net/~fkrull/+archive/deadsnakes







PARTNERS