Any Tips For -rpath When Cross Compiling

[iamasmith]

Hi,

I find that many of the things that I'm building seem to fail dependencies off libraries and that whatever combination of -rpath and -rpath-link that I use doesn't seem to resolve the issue.

Consequently I end up tranferring stuff back to the Z and building some stuff native which is incredibly slow compared to my desktop machine.

Does anyone have any particular tips on overcoming this ?

- Andy

[lardman]

I've never needed to use -rpath for cross-compiling.

What kind of errors are you getting?


Si

[iamasmith]

Well if you try linking to libqt-mt without an -rpath pointing to your X11R6/libs directory you get a stack of errors for all the unresolved externals for X. as an example. - I needed to do this to get qbedic to build.

But if you look at this thread you can see one that really caused me problems.

https://www.oesf.org/forums/inde...?showtopic=9948

[iamasmith]

OK, I can see that it should really be -rpath-link but this seems to make no difference either.

The particular beast that I'm trying to build at the moment is pingus-0.6.0 !

I have libogg, libvorbis, libmikmod, libHermes, libclan* all compiled static and am trying to link pingus but it doesn't seem to find the static librararies for libmikmod, libogg etc, when it links libclanMikMod etc.

Does -rpath-link only work with shared libs ?

Any tricks that anyone can reccomend ?, I don't really want to use shared ClanLib because it's out of date with current versions of MikMod, it's an old version required to work with pingus and its pretty huge !.

Any ideas folks ?

[lardman]

From what I've read (briefly) -rpath only works with shared libs and is only used at run time to find the location of shared libs which should be linked (dynamically) from non-standard locations (so you don't have to manually alter LD_LIBRARY_PATH each time you run the binary).

-rpath-link seems to (sort of) do what you want (pull in the symbols, and code...? (not sure about that) from shared libs and make it an integral part of your binary), but why not just place the libs in question in the lib directory of your toolchain? Then they'll be linked in automatically...?

I've never had to deal with statically compiled libs, I'm not sure how to get them linked (specifically how to give them priority over shared libs should they be availble).


Si

[iamasmith]

Lardman,

Yes the libs in question are in the toolchain directory and were built using that prefix so the appropriate .la file is built too.

One thing that I did notice though is that ClanLib doesn't produce .la files so I'm not sure if this is significant. In any case I have had the problem with other library sets.

The problem doesn't actually appear linking single static libs but when one static lib is dependent upon another static lib i.e.

Linking libclanMikMod.a requires libmikmod.a and it doesn't resolve the libmikmod dependencies even if you explicitely link with -lclanMikMod and -lmikmod or even specifying the .a files explicitely in the object list.

Actually, I found yesterday that this isn't just effecting the cross environment. I tried to build pingus natively on the Z, it required a 96Mb swap file to even consider linking and eventually threw the same set of unresolved externals. This seems to be something particularly related to static libraries and dependencies.  - someone must know a little more about hacking these things together.

- Andy

[iamasmith]

OK, I just built a couple of shared libraries myself with dependencies linked off one to the other and successfully built an application using the cross compiler toolchain with no errors.

I'm now wondering if there's a slightly different ABI when building native to building cross. I ended up building libHermes on the Z because the configure script insists on working out byte ordering by building a test binary and then when it can't run it because its cross compiled it freaks out.

Anyone know if this is a factor ? I assumed to this point that it was feasible to transfer libraries built on the Z to the cross compile environment.

Incidentally, pingus uses g++ to invoke the linker. Could this also be a factor ? I tried getting the search paths out of amv5tel-cacko-linux-g++ and putting the libraries in these paths and I still got the same error.

- Andy

[pgas]

I'm pretty sure you can use lib build on the Z in the cross compiler environement, because I think i've done this once (not 100% sure though).

If i remember well i was just copying them over after I installed them on the Z.

As for the rest I don't know gcc  options well enough to help you.....

[lardman]

Incidentally, pingus uses g++ to invoke the linker.

As in the native toolchain not the cross-toolchain?

This won't work then (though the error should be a different one).

I'm pretty sure you can use lib build on the Z in the cross compiler environement, because I think i've done this once (not 100% sure though).

I've done this before without problems. There shouldn't be a difference (otherwise it wouldn't work on one or the other).


Si

[iamasmith]

Incidentally, pingus uses g++ to invoke the linker.

As in the native toolchain not the cross-toolchain?
 

g++ for native armv5tel-cacko-linux-g++ on the cross environment.

It's not calling the x86 native tools.

[iamasmith]

Pingus coming SOON...

This screenshot IS off my 860 running PDAXROM RC8. Pingus DOES run with the args -f -g 640x480 --frame-skip 3 with full ogg/vorbis music and sound and IS playable.

However, it's huge.

45Mb uncompressed or 19Mb of squashfs. I really want to link this statically and try to reduce the size as the archive is carrying 25Mb of shared clanlib stuff !

The only point to note with the app is that it doesn't seem to be particularly responsive to clicks from the stylus at times.

[tovarish]

looks great, could you also upload the source while releasing, i would like to compile it for cacko

tovarish

[pgas]

iamasmith: I suggest you contact ScottYelich if you need some space to host pingus.
He must be mirroring every bit of software that has compiled for the Z

Also I would like a copy of the  Hermes  lib you compile (with headers) as I want to try to compile
ChaosStrikesBack for windows and linux and that it apparently uses  this lib. Just to save me a bit of trouble...

[iamasmith]

looks great, could you also upload the source while releasing, i would like to compile it for cacko

tovarish

The source is available from http://pingus.seul.org however I think that your only option for compilation would be to use XQt and I also think it would be too slow.

Pingus uses ClanLib 0.6.5 which isn't aware of SDL, you basically get X11 or opengl support in the lib. You could try porting it to a later version of ClanLib that does support SDL if you wanted.

[iamasmith]

iamasmith: I suggest you contact ScottYelich if you need some space to host pingus.
He must be mirroring every bit of software that has compiled for the Z

Also I would like a copy of the  Hermes  lib you compile (with headers) as I want to try to compile
ChaosStrikesBack for windows and linux and that it apparently uses  this lib. Just to save me a bit of trouble...

Cool, actually I thought libHermes was a little obscure and therefore it would be better to statically link. If there are going to be a few projects perhaps I should rebuild and produce a shared version (I only built the static lib).

What do you think ? I could build a proper lib and push that to the dev feed of would static only work for you ?

- Andy