| View previous topic :: View next topic |
| Author |
Message |
Squall
Joined: 22 Oct 2007
Posts: 24
|
 Posted: Wed May 21, 2008 9:41 am Post subject: DevilID library loading incorrect on linux |
 |
|
derelict tries to load libIL.so on linux, which isn't present unless you have the development package installed -- even though the "release" package of devil is installed.
for example on ubuntu:
user@pandora:~$ aptitude search devil
i libdevil-dev - Cross-platform image loading and manipulation toolkit
i libdevil1c2 - DevIL image manipulation toolkit runtime support
user@pandora:~$ dpkg -S libIL.so
libdevil-dev: /usr/lib/libIL.so <-- Only in dev
libdevil1c2: /usr/lib/libIL.so.1.0.0
libdevil1c2: /usr/lib/libIL.so.1
user@pandora:~$
This is a similar problem to a previous post I made: "libfreetype loading on linux"
I don't know what the solution to this is properly.
Why does derelict dynamically load all the libraries it uses by the way? |
|
| Back to top |
|
 |
h3r3tic
Joined: 30 Mar 2004
Posts: 261
Location: Torun, Poland
|
| Posted: Wed May 21, 2008 2:55 pm Post subject: |
|
|
Uh, I guess some lib names might be added to the IL loaders, but the long-term solution would probably be to have search path and library name wildcard matching...
Perhaps something similar to what I've done in Dog?
http://team0xf.com:8080/dog/file/1bdd270a6b3c/LoaderCommon.d
e.g.
| Code: | appendLibSearchPaths(`.`, ``, `/usr/lib`, `/usr/local/lib`);
appendLibNames(`libGL.so`, `libGL.so.1.*`, `libGL.so.*`);
appendGluLibNames(`libGLU.so`, `libGLU.so.1.*`, `libGLU.so.*`);
|
|
|
| Back to top |
|
|
aldacron
Joined: 05 May 2004
Posts: 1322
Location: Seoul, South Korea
|
| Posted: Wed May 21, 2008 6:30 pm Post subject: Re: DevilID library loading incorrect on linux |
|
|
| Squall wrote: | | Why does derelict dynamically load all the libraries it uses by the way? |
You can find the answer to that on the index page of the docs. The short answer is that it allows more control over what do to if a shared lib isn't present on the user's system. FYI, the option to statically link with shared libraries will be available for most Derelict packages in future.
_________________
The One With D | The One With Aldacron | D Bits |
|
| Back to top |
|
|
Squall
Joined: 22 Oct 2007
Posts: 24
|
| Posted: Thu May 22, 2008 3:26 am Post subject: |
|
|
Thanks aldacron
Since static linking might be on the cards, presumably dynamic linking done via the standard dynamic loader would also be included? (as opposed to the current dlopen method)
In the mean time I can find ways round this, probably creating a local symlink and useing LD_LIBRARY_PATH or some such. |
|
| Back to top |
|
|
aldacron
Joined: 05 May 2004
Posts: 1322
Location: Seoul, South Korea
|
| Posted: Thu May 22, 2008 5:37 am Post subject: |
|
|
| Squall wrote: |
Since static linking might be on the cards, presumably dynamic linking done via the standard dynamic loader would also be included? (as opposed to the current dlopen method) |
Well, that's essentially what I mean. I'm a Windows type, so I think in terms of statically linking to an import library rather than linking directly to a shared library as on Linux (though MingW supports passing DLLs on the command line in place of import libraries these days). But at the heart of it, it doesn't matter in D. The interface for linking with static and shared libraries is the same. So both will be supported. You can see this with the current DerelictFT trunk.
_________________
The One With D | The One With Aldacron | D Bits |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
