FIFE forums

Please login or register.

Login with username, password and session length
Advanced search  

News:

FIFE 0.4.0 has been released on 15th of January, 2017!

Author Topic: Trac ticket #351: non-standard rpaths  (Read 6087 times)

readlock

  • Newbie
  • Posts: 4
    • View Profile
Trac ticket #351: non-standard rpaths
« on: June 05, 2009, 04:16:28 am »

Ticket.

Perhaps modifying ext/SConstruct, adding '--disable-rpath' to libpng and guichan 'configure' lines will solve this. Does someone have a Fedora installation to verify?

I'm posting here, since CVSdude still has anonymous commenting on tickets disabled, and I can't find how to register.
Logged

mvBarracuda

  • Administrator
  • Sr. Member
  • *
  • Posts: 411
    • View Profile
Re: Trac ticket #351: non-standard rpaths
« Reply #1 on: June 05, 2009, 07:00:54 am »

Sorry for all the trouble readlock :-/ Without the spam filter we would have massive ticket abuse issues, but the current situation of locking out feedback by community members is not really satisfying either.

I've tweaked the spam filter settings again and hopefully non-spam gets through now.
Logged

mvBarracuda

  • Administrator
  • Sr. Member
  • *
  • Posts: 411
    • View Profile
Re: Trac ticket #351: non-standard rpaths
« Reply #2 on: June 23, 2009, 06:22:29 am »

The spam filter was still flawed :-/

Fortunately the cvsdude support helped us to hopefully finally resolve the issue. Please let us know if there are continued issues with creating tickets as anonymous user.
Logged

readlock

  • Newbie
  • Posts: 4
    • View Profile
Re: Trac ticket #351: non-standard rpaths
« Reply #3 on: June 28, 2009, 01:31:36 pm »

Well, I tried it: http://fife.pastebin.com/m11c61034

It builds well, the tests go the same, and PARPG runs, too. I didn't test all that much.

Now, is there anyone with Fedora here, or should I contact che who reported the issue?
Logged

LinuxDonald

  • Newbie
  • Posts: 28
    • View Profile
    • My Blog (German)
Re: Trac ticket #351: non-standard rpaths
« Reply #4 on: June 29, 2009, 06:48:52 pm »

Please Contact che or cassmodiah :)
Logged

mvBarracuda

  • Administrator
  • Sr. Member
  • *
  • Posts: 411
    • View Profile
Re: Trac ticket #351: non-standard rpaths
« Reply #5 on: June 30, 2009, 09:33:30 am »

I guess they can be found at #unknown-horizons @ freenode LinuxDonald?
Logged

prock

  • Developer
  • Full Member
  • *
  • Posts: 236
    • View Profile
Re: Trac ticket #351: non-standard rpaths
« Reply #6 on: September 25, 2009, 02:27:23 pm »

Sorry to revive an old topic but I want to start getting as many of these old tickets out of the way as possible.


I'm looking at the <FIFE>/trunk/engine/SConscript from changeset 1829 here:  http://fife.trac.cvsdude.com/engine/changeset/1829/trunk/engine/SConscript

You can see that jasoka added some additional -rpath arguments to the linker flags.  I didn't bother tracing it back any farther.  I believe this is the problem.  The question is how to fix it.   I'll have to do some testing with it to find out. 

Also, is there a reason why we provide the ext directory with in FIFE?  Correct me if I'm wrong but I think I heard it was because scons was having difficulties detecting dependencies.   If we fixed scons would you guys be against removing the ext directory?
Logged

vtchill

  • Developer
  • Full Member
  • *
  • Posts: 206
    • View Profile
Re: Trac ticket #351: non-standard rpaths
« Reply #7 on: September 26, 2009, 07:52:10 am »

I believe the rpaths are bad because they do not rely on standard install locations for external dependencies.

The ext directory provides the source for some of the external deps we use and during the build process we build everything in the ext directory (provided the user passes ext=1 to scons which they have to the first time they build). To get rid of the ext directory we would have to provide some way (either through the package manager or something else) so that the user could install the binary or sources themselves into the standard install locations. This would require that everything we use in ext to be available to the user without us providing it and then us fixing the scons scripts to use the standard install paths.

I believe we could also still provide the ext directory and build those dependencies, but place them in standard install locations and then remove the rpath as well.
« Last Edit: September 26, 2009, 07:53:43 am by vtchill »
Logged

CheeseSucker

  • Developer
  • Newbie
  • *
  • Posts: 26
  • FIFE programmer
    • View Profile
Re: Trac ticket #351: non-standard rpaths
« Reply #8 on: September 26, 2009, 09:16:09 am »

I think there is another reason why we provide the libs in ext:
 - We have patched Guichan so it supports UTF-8
 - We also have a patch for libpng, so it doesn't fail when building swig wrappers

I don't know why we provide the other libs
Logged

Sleek

  • Developer
  • Jr. Member
  • *
  • Posts: 57
    • View Profile
Re: Trac ticket #351: non-standard rpaths
« Reply #9 on: September 27, 2009, 08:30:14 pm »

Hi everyone.

As far as I remember it, ext/install/lib contains the dynamic libraries that are external to but depended on by FIFE. E.g. OpenGL, guichan, SDL and such. Also, as far as I know this rpath need is specific to Windows-case. The SConscript file still applies the rpath under linux, but probably ld.conf takes precedence there.

I can't remember it very well, but I think...  I/We were trying to get the executable to run on Windows based on the SDK that barra prepared. The directory structure of that SDK was in that manner, and there were discussions on having a better directory structure, but I guess we never got to a conclusion on that.

So it's possible to remove the rpath, but on Windows, we will have to move all the .dlls to the same directory as the executable.
Logged

prock

  • Developer
  • Full Member
  • *
  • Posts: 236
    • View Profile
Re: Trac ticket #351: non-standard rpaths
« Reply #10 on: September 27, 2009, 10:52:48 pm »

I did a quick test on my Ubuntu box...  if I remove the line from the <FIFE>/trunk/engine/SConscript file that contains the -rpath linker flags, re-build fife and try to run rio_de_hola I get a bunch of errors that it couldn't find the guichan and openal libs.  ldd also reports that it cannot find the libraries either (as expected).

This adds an interesting little twist.  If we have a patched guichan and libpng we cannot get rid of the ext directory.   The install target would have to copy the libs to a standard install path.  But what if the users already have a copy of guichan or libpng for another project they are working on and they dont want to clobber those shared libraries?

To get around this I tried setting the LD_LIBRARY_PATH environment variable to <FIFE>/ext/install/lib and it works.  We could wrap the run.py scripts with a shell script that sets the LD_LIBRARY_PATH.  I'm not sure how good of a solution that would be.  Seems more like a hack.

Any other ideas?

Logged

Sleek

  • Developer
  • Jr. Member
  • *
  • Posts: 57
    • View Profile
Re: Trac ticket #351: non-standard rpaths
« Reply #11 on: September 28, 2009, 01:48:04 am »

This is it prock. What rpath does is add the given path to the parameter to dynamic library search path. If you have a patched dynamic library, most probably you have not added it to ld.conf, and hence it's not in the search path. I am afraid LD_LIBRARY_PATH is available to Linux/*nix only. It would not work on Windows, for example.
Logged

CheeseSucker

  • Developer
  • Newbie
  • *
  • Posts: 26
  • FIFE programmer
    • View Profile
Re: Trac ticket #351: non-standard rpaths
« Reply #12 on: September 28, 2009, 05:25:04 am »

On windows, we supply pre-built (and patched) dependencies, so the ext/ folder is not necessary there.
I removed the rpaths from engine/SConscript, and FIFE compiled, linked and ran successfully on my win32 box.
Logged

prock

  • Developer
  • Full Member
  • *
  • Posts: 236
    • View Profile
Re: Trac ticket #351: non-standard rpaths
« Reply #13 on: September 28, 2009, 09:49:39 am »

So because this only affects users on Linux what are the proposed fixes? 

First we must remove the -rpath from the SConscript file.

Next:

1 - install the patched libraries and headers to standard install directories
2 - add <FIFE>/ext/install/lib to the users ld.conf file
3 - create wrapper script and set LD_LIBRARY_PATH before running run.py
4 - is there a way to set LD_LIBRARY_PATH in run.py directly?


Also, does someone know where to find the patches that were applied for libpng and guichan?
Logged

christoph

  • Newbie
  • Posts: 5
    • View Profile
Re: Trac ticket #351: non-standard rpaths
« Reply #14 on: October 01, 2009, 07:30:17 am »

IMHO (and that is in consent with current policy on Debian), if you really desperately need patched libraries either link them in statically or use rpath. If in any way possible avoid the need for patched libraries. Currently mostly only guichan needs to be patched, right? libpng needs some path for Ubuntu which AFAIR is some missuse of libpng's interface somewhere deep down the SWIG path and hardly findable.
Logged