Jump to content

  • Log In with Google      Sign In   
  • Create Account

link libpng


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

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

#1 FGFS   Members   -  Reputation: 196

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: 817

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: 196

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: 817

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: 196

Like
-1Likes
Like

Posted 16 April 2014 - 12:02 AM

Seems you can't understand my question.



#6 Ectara   Crossbones+   -  Reputation: 2968

Like
2Likes
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: 817

Like
1Likes
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: 817

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: 1603

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: 196

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: 1603

Like
0Likes
Like

Posted 17 April 2014 - 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: 196

Like
0Likes
Like

Posted 18 April 2014 - 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



#13 dejaime   Crossbones+   -  Reputation: 4027

Like
0Likes
Like

Posted 18 April 2014 - 10:41 AM

In theory, you'd only need to add SDL_image and SDL to your linker.

If they are installed, you can use -lSDL2 and -lSDL2_image

 

If you are compiling it yourself, this command will probably work (given you have autotools and build-essential installed):

./autogen.sh && ./configure && make && sudo make install

It will compile and install SDL2, probably under usr/local. It would also work for SDL_image and SDL_mixer...

 

The libpng runtime come in every linux distribution I've ever used (save arch), so don't worry about it. Also, if someone is using an Arch or Gentoo or anything that doesn't come with the runtime libpng, they probably know what they are doing (and will understand the missing shared object error) and will be able to fix it themselves (basically a call apt-get or pacman).

 

But yes, unfortunately, linux does not link statically. This is a major pain when considering this kind of dependencies, but well, them's the breaks.

 

 


Also.. since SDL 1.2 is more portable. I predict it will actually outlive 2.0.

SDL1.2 is not necessarily more portable.

You can't use it on iOS in a practical manner, given the legal restrictions the LGPL license imposes. SDL2 is zlib, that is way more usable from a developer point of view.

 

There are also the more obvious reasons; SDL2 is fully hardware accelerated, it has a better API, supports OpenGL ES and 3+, to name a few.

So, I'd bet all my programming books that SDL2 will outlive 1.2 easily, the same way I did saying XNA would be discontinued.

@edit

SDL1.2 is already marked as a historical version, and looks like it hasn't been updated in over two years.


Edited by dejaime, 19 April 2014 - 09:21 PM.


#14 FGFS   Members   -  Reputation: 196

Like
0Likes
Like

Posted 19 April 2014 - 07:20 AM


But yes, unfortunately, linux does not link statically. This is a major pain when considering this kind of dependencies, but well, them's the breaks.

 

I was thinking the other way round. If a lib update breaks compatibility, like python in the past and sdl 1.2 to 2, I can simply include the old dynamic lib and am not forced

to rewrite my app. As this would have been a lot of work for my sdl 1.2 app, I was right. tongue.png 



#15 georger.araujo   Members   -  Reputation: 817

Like
0Likes
Like

Posted 19 April 2014 - 02:20 PM

 


But yes, unfortunately, linux does not link statically. This is a major pain when considering this kind of dependencies, but well, them's the breaks.

 

I was thinking the other way round. If a lib update breaks compatibility, like python in the past and sdl 1.2 to 2, I can simply include the old dynamic lib and am not forced

to rewrite my app. As this would have been a lot of work for my sdl 1.2 app, I was right. tongue.png

 

 

I just downloaded and installed Ubuntu 14.04 LTS, which was released last Thursday (Apr 17) and is supported for 5 years, on a VM.

 

Then I did a sudo apt-get install libsdl1.2-dev libsdl-image1.2-dev (libpng12-dev was among the dependencies), and built a simple program that loaded a .PNG file. Worked fine.

 

So it looks like SDL 1.2 will be around for at least another 5 years on a major distribution. All your work for being "right" was pointless.



#16 FGFS   Members   -  Reputation: 196

Like
0Likes
Like

Posted 20 April 2014 - 12:33 AM

No, as I've said, I only wanted to have them ready and test if all would be fine. I won't include them in the next years.






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS