-------------- Original message ---------------------- From: "John R. Culleton"

With both of these versions the program compiles clean and installs clean but the following error occurs at runtime:

/usr/local/bin/gimp-2.3: symbol lookup error: /usr/local/bin/gimp-2.3: undefined symbol: gimp_env_init

I've got 2.3.11 running on Ubuntu 6.06 and I've never seen that error. I recently upgraded to glib 2.12.4 and gtk+ 2.10.6 from source and while I've seen some change in behavior of GNOME on my system, Gimp 2.3.11 runs fine and I don't recall seeing that message ever.

Peace...

Tom

Hi,

On Fri, 2006-10-27 at 12:09 -0400, John R. Culleton wrote:

With both of these versions the program compiles clean and installs clean but the following error occurs at runtime:

/usr/local/bin/gimp-2.3: symbol lookup error: /usr/local/bin/gimp-2.3: undefined symbol: gimp_env_init

Your copy of gimp-2.3 is most likely linking against the libraries from gimp-2.2. As outlined in the release notes for the development releases, you should take appropriate measure to avoid this.

Sven

Hi all,

I've seen this once and IIRC it turned out that my gimp-2.3 tried to load libgimp / libgimpbase from version 2.2 which is still on the somewhere on my Linux box.

I fixed this by installing gimp-2.3 completely under /usr/local/Gimp-2.3 and calling it by a little wrapper named gimpdev:

------------------ #!/bin/sh
LD_LIBRARY_PATH=/usr/local/Gimp-2.3/lib:${LD_LIBRARY_PATH} /usr/local/Gimp-2.3/bin/gimp-2.3 ------------------

The key is here that the LD_LIBRARY_PATH variable must point to the right libs.

Regards,
Stephan.

John R. Culleton wrote:

With both of these versions the program compiles clean and installs clean but the following error occurs at runtime:

/usr/local/bin/gimp-2.3: symbol lookup error: /usr/local/bin/gimp-2.3: undefined symbol: gimp_env_init

I use Slackware Linux 10.2. the only recent change has been the addition of freerock gnome, since Slackware Linux distros no longer include Gnome.

I have a version of 2.2.12 that works so I am not fussing with it :

Any suggestions?

Stephan Hegel wrote:

I fixed this by installing gimp-2.3 completely under /usr/local/Gimp-2.3 and calling it by a little wrapper named gimpdev:

The release notes suggest to use /opt/gimp-2.3, BTW.

HTH, Michael

Hi,

Does this affect the functionality of gimp-2.3 ? In that case "configure" should not allow a "--prefix=/usr/local/Gimp-2.3".

And: it does not fix the problem what was mentioned on top of the thread. HTH ? No, it does not help at all.

Regards, Stephan.

Michael Schumacher wrote:

Stephan Hegel wrote:

I fixed this by installing gimp-2.3 completely under /usr/local/Gimp-2.3 and calling it by a little wrapper named gimpdev:

The release notes suggest to use /opt/gimp-2.3, BTW.

HTH, Michael

Stephan Hegel wrote:

Does this affect the functionality of gimp-2.3 ? In that case "configure" should not allow a "--prefix=/usr/local/Gimp-2.3".

configure allows everything. Anyone who is building from source ought to know that the prefix he chooses should be one that does not cause harm to the system - or he should choose another one if the default one does.

And: it does not fix the problem what was mentioned on top of the thread. HTH ? No, it does not help at all.

You mean a GIMP 2.3 build with --prefix=/opt/gimp-2.3 still exhibits the same error on Slackware? Maybe this is something a Slackware user should investigate then.

Michael

I used the 2.3.11 version without problems

maybe you should try building the 2.3.12 version (current developement release) with prefix (i'm using /opt/gimp-2.3) also don't forget to create the script which lauches gimp

-->

#!/bin/sh

PATH=/opt/gimp-2.3/bin:$PATH export PATH
LD_LIBRARY_PATH=/opt/gimp-2.3/lib
export LD_LIBRARY_PATH

/opt/gimp-2.3/bin/gimp-2.3 "$@"

wrote:

Stephan Hegel wrote:

Does this affect the functionality of gimp-2.3 ? In that case "configure" should not allow a "--prefix=/usr/local/Gimp-2.3".

configure allows everything. Anyone who is building from source ought to know that the prefix he chooses should be one that does not cause harm to the system - or he should choose another one if the default one does.

And: it does not fix the problem what was mentioned on top of the thread. HTH ? No, it does not help at all.

You mean a GIMP 2.3 build with --prefix=/opt/gimp-2.3 still exhibits the same error on Slackware? Maybe this is something a Slackware user should investigate then.

Michael

Michael Schumacher wrote:

You mean a GIMP 2.3 build with --prefix=/opt/gimp-2.3 still exhibits the same error on Slackware? Maybe this is something a Slackware user should investigate then.

Even on my SuSE 10.0, this would cause the same problem as LD_LIBRARY_PATH does not point to "/opt/gimp-2.3/lib" by default. Therefore the loader would grab the wrong library again. It's not only a pure Slackware issue.

Stephan.

Hi,

On Sun, 2006-10-29 at 04:04 +0100, Stephan Hegel wrote:

Michael Schumacher wrote:

You mean a GIMP 2.3 build with --prefix=/opt/gimp-2.3 still exhibits the same error on Slackware? Maybe this is something a Slackware user should investigate then.

Even on my SuSE 10.0, this would cause the same problem as LD_LIBRARY_PATH does not point to "/opt/gimp-2.3/lib" by default. Therefore the loader would grab the wrong library again. It's not only a pure Slackware issue.

Not if you use the wrapper script that is suggested by the release notes and has already been mentioned here.

Sven

Sven Neumann wrote:

Not if you use the wrapper script that is suggested by the release notes and has already been mentioned here.

Yes, I've posted a little wrapper by myself - you haven't read the whole thread carefully, have you ?

Honestly: who is reading release notes ? This assumption is simply far from reality and real world does not work like this. Users/customers expect from release notes to get informed about changes, new features, etc. ... but not that they have to fiddle around with additional wrapper scripts to get the whole thing up and running. What they expect after installing is that the program is running out of the box. Right ?

The problem is in the Gimp installation procedure itself ...

Why not install an appropriate wrapper automatically after configure && make && make install and just tell the user to add the location of the wrapper to the PATH environment variable ? Or tell him to call it with the full path ?

This is not only a problem of the development version of Gimp, this would happen with the stable version of Gimp as well when one decides to install it to a "non-standard" location.

Regards, Stephan.

On Sunday 29 October 2006 14:18, Stephan Hegel wrote:

Sven Neumann wrote:

Not if you use the wrapper script that is suggested by the release notes and has already been mentioned here.

Yes, I've posted a little wrapper by myself - you haven't read the whole thread carefully, have you ?

Honestly: who is reading release notes ? This assumption is simply far from reality and real world does not work like this. Users/customers expect from release notes to get informed about changes, new features, etc. ... but not that they have to fiddle around with additional wrapper scripts to get the whole thing up and running. What they expect after installing is that the program is running out of the box. Right ?

I have to respectfully disagree here. When something is being "released" and it's not even production, then yes, you should read them. In reading them, you would discover the wrapper script. I know because this is how I discovered it, and I am not a Gimp devel, just a user.

Brendan wrote:

I have to respectfully disagree here. When something is being "released" and it's not even production, then yes, you should read them. In reading them, you would discover the wrapper script. I know because this is how I discovered it, and I am not a Gimp devel, just a user.

You are right: you _should_ read them. But reality is that only a few people do this. And finally we end up with threads like this where a program even does not start out of the box 'cause it's grabbing a wrong library.

As I said the wrapper script is not only a problem of the development version, you need this wrapper also with the stable version of The Gimp when installing it in a non-standard location. Take an average Windows user: usually he runs an install.exe, can store the application at any place on his harddisks and at the end of this procedure the program often is even launched ... Done.

Sorry, but I stick with my opinion that the problem is caused by the installation procedure of The Gimp. It should install the wrapper by itself. And it could be done easily: create a wrapper template, during make or make install replace the path with the --prefix passed from configure, install it and print a message where the wrapper is so that the user know what to invoke.

Kind regards, Stephan.

Hi,

On Tue, 2006-10-31 at 04:48 +0100, Stephan Hegel wrote:

You are right: you _should_ read them. But reality is that only a few people do this. And finally we end up with threads like this where a program even does not start out of the box 'cause it's grabbing a wrong library.

As I said the wrapper script is not only a problem of the development version, you need this wrapper also with the stable version of The Gimp when installing it in a non-standard location. Take an average Windows user: usually he runs an install.exe, can store the application at any place on his harddisks and at the end of this procedure the program often is even launched ... Done.

Sorry, but I stick with my opinion that the problem is caused by the installation procedure of The Gimp. It should install the wrapper by itself. And it could be done easily: create a wrapper template, during make or make install replace the path with the --prefix passed from configure, install it and print a message where the wrapper is so that the user know what to invoke.

You are making a wrong assumption here about the target audience of a source release. Users are not the target audience. Users should grab a pre-compiled binary from their distributor or from someone who knows what he's doing and provides one for them.

The target audience of a source code release are people who are experienced in building software from source. They do appreciate the standard autoconf/automake based build and install procedures that GIMP provides. They would hate us if we deviated from this standard build process and started to install wrapper scripts.

Sven

Sven Neumann wrote:

You are making a wrong assumption here about the target audience of a source release. Users are not the target audience. Users should grab a pre-compiled binary from their distributor or from someone who knows what he's doing and provides one for them.

I consider myself belonging to the target audience. And I'm just a user. Who else shall fetch source code releases ? Developers go straight for the CVS repository anyway.

There are more people in this thread who state to be just a user and do install source code releases. When you browse through the threads of the gimp-user list, there are also discussions about 2.3.x topics which is available as source code only.

I do install Gimp source releases - on top of my favorite distribution 'cause it contains bug fixes I don't get quickly from the vendor. Or I like the latest Gimp but the distribution is not maintained anymore and I don't want to upgrade. Or I want to try brand-new features, e.g. the object extraction via Siox, etc. All the stuff which is not offered by an official distribution. I could imagine more use cases like this.

The target audience of a source code release are people who are experienced in building software from source. They do appreciate the standard autoconf/automake based build and install procedures that GIMP provides. They would hate us if we deviated from this standard build process and started to install wrapper scripts.

I'm sorry but why should they hate you ? They need the wrapper anyway as pointed out in the release notes.

There are several other source code releases who provide wrappers to make sure that the application runs of the box after installation. They provide additional checks about the environment, check permissions, make sure that they access the right libraries to avoid unnecessary user confusion. Examples are Firefox, Thunderbird, the Wine applications, Tomboy, Beagle (in fact all Mono applications), etc. ....

It does not break the mechanism of "configure && make && make install" as everything could be embedded fully transparent within this procedure, even the installation of a wrapper. The user even wouldn't notice.

Kind regards, Stephan.

Stephan Hegel wrote:
Who else shall fetch source code releases ?

The package maintainers for the over 300 different Linux distributions. Not to mention maintainers for Solaris, BSD, and Windows.

I'm sorry but why should they hate you ? They need the wrapper anyway as pointed out in the release notes.

They don't necessarily *need* the wrapper (that is but one suggested solution to having multiple GIMPs installed concurrently) and, if they do need to customize the setup for their own distribution's setup, they might very well resent having to UNDO the decisions that the GIMP developers made in how it was to be installed.

There are several other source code releases who provide wrappers to make sure that the application runs of the box after installation. They provide additional checks about the environment, check permissions, make sure that they access the right libraries to avoid unnecessary user confusion. Examples are Firefox, Thunderbird, the Wine applications, Tomboy, Beagle (in fact all Mono applications), etc. ....

I am not going to bother looking at all of your examples but a quick search of running multiple instances (that is what's being discussed, not a solitary installation) of FireFox suggests that their installer does NOT automatically provide the wrapper scripting required.

It does not break the mechanism of "configure && make && make install" as everything could be embedded fully transparent within this procedure, even the installation of a wrapper. The user even wouldn't notice.

I think your suggestion, if implemented, would be noticed right away by package maintainers who are the best qualified (no offense to GIMP developers) to determine how the GIMP should be installed for their distribution's particular implementation.

-------- "It is amazing what you can accomplish if you do not care who gets the credit." -- Harry S. Truman

For the record folks, I've got Gimp 2.2.11 installed in /usr (came with my Linux distro) and Gimp 2.3.12 (used to have 2.3.11) installed in /usr/local/gimp-2.3 and I'm able to run either version without any problems, errors, or wrapper scripts (unless gimp-2.3 is a wrapper script).

I'm running on Ubuntu 6.06 Linux but I used to run stable and development versions of Gimp built from source on my old Slackware 8-based machine all the time and without problems.

I don't think the error Mr Culleton received is as big of an issue as it appears to be.

Peace...

Tom Williams wrote:

For the record folks, I've got Gimp 2.2.11 installed in /usr (came with my Linux distro) and Gimp 2.3.12 (used to have 2.3.11) installed in /usr/local/gimp-2.3 and I'm able to run either version without any problems, errors, or wrapper scripts (unless gimp-2.3 is a wrapper script).

That's very interesting. Could you please post the output of echo $LD_LIBRARY_PATH
and
file /usr/local/gimp-2.3/bin/gimp-2.3 ?

Thanks.

I'm wondering how this works with multiple gimp libs.

Kind regards, Stephan.

Saul Goode wrote:

They don't necessarily *need* the wrapper (that is but one suggested solution to having multiple GIMPs installed concurrently)

If you have another suggestion how to run multiple, library-wise incompatible instances of Gimp without using a wrappers, please let me know.

Kind regards,
Stephan.

Stephan Hegel wrote:

Tom Williams wrote:

For the record folks, I've got Gimp 2.2.11 installed in /usr (came with my Linux distro) and Gimp 2.3.12 (used to have 2.3.11) installed in /usr/local/gimp-2.3 and I'm able to run either version without any problems, errors, or wrapper scripts (unless gimp-2.3 is a wrapper script).

That's very interesting. Could you please post the output of echo $LD_LIBRARY_PATH
and
file /usr/local/gimp-2.3/bin/gimp-2.3 ?

Thanks.

I'm wondering how this works with multiple gimp libs.

Kind regards, Stephan.

Sure can. :)

--------START-------------

tom@gwanna:~$ echo $LD_LIBRARY_PATH

tom@gwanna:~$ file /usr/local/gimp-2.3/bin/gimp-2.3 /usr/local/gimp-2.3/bin/gimp-2.3: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.6.0, dynamically linked (uses shared libs), for GNU/Linux 2.6.0, not stripped tom@gwanna:~$ which gimp
/usr/bin/gimp
tom@gwanna:~$ gimp --version
GIMP version 2.2.13
tom@gwanna:~$ gimp &
[1] 5821
tom@gwanna:~$ /usr/local/gimp-2.3/bin/gimp-2.3 --version GNU Image Manipulation Program version 2.3.12 tom@gwanna:~$ /usr/local/gimp-2.3/bin/gimp-2.3 & [2] 5830
tom@gwanna:~$ This is a development version of GIMP. Debug messages may appear here.

jpeg-load: found EXIF block (15 bytes) jpeg-load: found image comment (17 bytes)

[1]- Done gimp [2]+ Done /usr/local/gimp-2.3/bin/gimp-2.3 tom@gwanna:~$

-----------END-------------

I upgraded from Ubuntu 6.06 (Dapper) to 6.10 (Edgy) this morning. I was able to run Gimp 2.2.13 (came with Edgy) and 2.3.12 (built from source) concurrently. The jpeg-load messages came from my loading an image in Gimp 2.3.12.

For completeness, here is the "file" info on /usr/bin/gimp:

-------START---------

tom@gwanna:~$ file /usr/bin/gimp /usr/bin/gimp: symbolic link to `gimp-2.2' tom@gwanna:~$ file /usr/bin/gimp-2.2 /usr/bin/gimp-2.2: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.6.0, dynamically linked (uses shared libs), for GNU/Linux 2.6.0, stripped
tom@gwanna:~$

---------END----------

Peace...

Tom

Stephen Hegel wrote:

Saul Goode wrote:

They don't necessarily *need* the wrapper (that is but one suggested solution to having multiple GIMPs installed concurrently)

If you have another suggestion how to run multiple, library-wise incompatible instances of Gimp without using a wrappers, please let me know.

Having separate accounts for use and development?

Using 'sudo' with an alternate account?

On a Solaris, use library interposing? (Maybe a stretch for the casual user but perhaps of interest to a developer or package maintainer.)

-------- "It is amazing what you can accomplish if you do not care who gets the credit." -- Harry S. Truman

Tom Williams wrote:

Sure can. :)

--------START-------------

tom@gwanna:~$ echo $LD_LIBRARY_PATH

tom@gwanna:~$

Thanks, Tom. The point is the empty LD_LIBRARY_PATH variable.

IIUC, in this case the loader is not forced to search for libs in certain directories. Seems it just uses the lib paths compiled in. And than it works for me too with multiple Gimp installations in different locations without using a wrapper. Just the PATH must be adjusted.

Regards,
Stephan.

Toby Haynes wrote:

Tom Williams wrote:

-------START---------

tom@gwanna:~$ file /usr/bin/gimp /usr/bin/gimp: symbolic link to `gimp-2.2' tom@gwanna:~$ file /usr/bin/gimp-2.2 /usr/bin/gimp-2.2: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.6.0, dynamically linked (uses shared libs), for GNU/Linux 2.6.0, stripped
tom@gwanna:~$

---------END----------

It would be more interesting to see what the dynamic linker is doing for the gimp install in /usr/local

i.e. ldd /usr/local/gimp-2.3/bin/gimp-2.3

compared with ldd /usr/bin/gimp

The reason for problems is not normally the base executable - it is the libraries that end up being linked to it. Both gimp-2.2 and gimp-2.3 have similar library names - if you see the /usr/local/gimp-2.3/bin/gimp-2.3 binary getting linked to the /usr/lib/libgimp* libraries, then you have a problem. If they are linked to /usr/local/gimp-2.3/lib/libgimp*, then you are less likely to have problems.

Ok, I've run the two commands above, as requested, except I ran the ldd against /usr/bin/gimp-2.2 instead of /usr/bin/gimp.

The results are in the attached text files. It looks like the right library search paths are compiled into the executable.

Peace...

Tom

libgimpwidgets-2.0.so.0 => /usr/lib/libgimpwidgets-2.0.so.0 (0x00002ab139043000) libgimpmodule-2.0.so.0 => /usr/lib/libgimpmodule-2.0.so.0 (0x00002ab13922e000) libgimpcolor-2.0.so.0 => /usr/lib/libgimpcolor-2.0.so.0 (0x00002ab139332000) libgimpthumb-2.0.so.0 => /usr/lib/libgimpthumb-2.0.so.0 (0x00002ab13943c000) libgimpmath-2.0.so.0 => /usr/lib/libgimpmath-2.0.so.0 (0x00002ab139545000) libgimpbase-2.0.so.0 => /usr/lib/libgimpbase-2.0.so.0 (0x00002ab13964a000) libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0x00002ab13975a000) libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0x00002ab139bee000) libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0x00002ab139d86000) libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0x00002ab139ea6000) libm.so.6 => /lib/libm.so.6 (0x00002ab139fbf000) libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0x00002ab13a140000) libXext.so.6 => /usr/lib/libXext.so.6 (0x00002ab13a249000) libXrender.so.1 => /usr/lib/libXrender.so.1 (0x00002ab13a35b000) libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0x00002ab13a464000) libXi.so.6 => /usr/lib/libXi.so.6 (0x00002ab13a566000) libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0x00002ab13a66f000) libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0x00002ab13a772000) libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0x00002ab13a87c000) libcairo.so.2 => /usr/lib/libcairo.so.2 (0x00002ab13a982000) libX11.so.6 => /usr/lib/libX11.so.6 (0x00002ab13aaeb000) libart_lgpl_2.so.2 => /usr/lib/libart_lgpl_2.so.2 (0x00002ab13acc9000) libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0x00002ab13ade1000) libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0x00002ab13af0f000) libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x00002ab13b04f000) libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0x00002ab13b191000) libdl.so.2 => /lib/libdl.so.2 (0x00002ab13b294000) libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x00002ab13b398000) libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x00002ab13b537000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x00002ab13b676000) libz.so.1 => /usr/lib/libz.so.1 (0x00002ab13b7ef000) libc.so.6 => /lib/libc.so.6 (0x00002ab13b906000) libXau.so.6 => /usr/lib/libXau.so.6 (0x00002ab13bb47000) libpng12.so.0 => /usr/lib/libpng12.so.0 (0x00002ab13bc4a000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00002ab13bd6e000) librt.so.1 => /lib/librt.so.1 (0x00002ab13be73000) /lib64/ld-linux-x86-64.so.2 (0x00002ab138f26000) libexpat.so.1 => /usr/lib/libexpat.so.1 (0x00002ab13bf7d000) libpthread.so.0 => /lib/libpthread.so.0 (0x00002ab13c09f000)

libgimpwidgets-2.0.so.0 => /usr/local/gimp-2.3/lib/libgimpwidgets-2.0.so.0 (0x00002ae81e9ae000) libgimpmodule-2.0.so.0 => /usr/local/gimp-2.3/lib/libgimpmodule-2.0.so.0 (0x00002ae81ebc2000) libgimpcolor-2.0.so.0 => /usr/local/gimp-2.3/lib/libgimpcolor-2.0.so.0 (0x00002ae81ecc6000) libgimpthumb-2.0.so.0 => /usr/local/gimp-2.3/lib/libgimpthumb-2.0.so.0 (0x00002ae81edd1000) libgimpmath-2.0.so.0 => /usr/local/gimp-2.3/lib/libgimpmath-2.0.so.0 (0x00002ae81eeda000) libgimpconfig-2.0.so.0 => /usr/local/gimp-2.3/lib/libgimpconfig-2.0.so.0 (0x00002ae81efdf000) libgimpbase-2.0.so.0 => /usr/local/gimp-2.3/lib/libgimpbase-2.0.so.0 (0x00002ae81f0ee000) libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0x00002ae81f21a000) libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0x00002ae81f6ad000) libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0x00002ae81f845000) libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0x00002ae81f966000) libm.so.6 => /lib/libm.so.6 (0x00002ae81fa7e000) libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0x00002ae81fbff000) libcairo.so.2 => /usr/lib/libcairo.so.2 (0x00002ae81fd09000) libart_lgpl_2.so.2 => /usr/lib/libart_lgpl_2.so.2 (0x00002ae81fe72000) libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0x00002ae81ff89000) libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0x00002ae8200b8000) libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x00002ae8201f8000) libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0x00002ae820339000) libdl.so.2 => /lib/libdl.so.2 (0x00002ae82043d000) libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x00002ae820541000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x00002ae820680000) libz.so.1 => /usr/lib/libz.so.1 (0x00002ae8207fa000) libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0x00002ae820910000) libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x00002ae820a14000) libpthread.so.0 => /lib/libpthread.so.0 (0x00002ae820bb3000) libc.so.6 => /lib/libc.so.6 (0x00002ae820cc9000) libX11.so.6 => /usr/lib/libX11.so.6 (0x00002ae820f0a000) libXext.so.6 => /usr/lib/libXext.so.6 (0x00002ae8210e8000) libXrender.so.1 => /usr/lib/libXrender.so.1 (0x00002ae8211f9000) libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0x00002ae821303000) libXi.so.6 => /usr/lib/libXi.so.6 (0x00002ae821405000) libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0x00002ae82150d000) libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0x00002ae821611000) libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0x00002ae82171b000) libpng12.so.0 => /usr/lib/libpng12.so.0 (0x00002ae821821000) librt.so.1 => /lib/librt.so.1 (0x00002ae821944000) /lib64/ld-linux-x86-64.so.2 (0x00002ae81e891000) libexpat.so.1 => /usr/lib/libexpat.so.1 (0x00002ae821a4e000) libXau.so.6 => /usr/lib/libXau.so.6 (0x00002ae821b70000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00002ae821c73000)

Stephan Hegel wrote:

Tom Williams wrote:

Sure can. :)

--------START-------------

tom@gwanna:~$ echo $LD_LIBRARY_PATH

tom@gwanna:~$

Thanks, Tom. The point is the empty LD_LIBRARY_PATH variable.

IIUC, in this case the loader is not forced to search for libs in certain directories. Seems it just uses the lib paths compiled in. And than it works for me too with multiple Gimp installations in different locations without using a wrapper. Just the PATH must be adjusted.

Yep, that sounds like what's going on as shown by my other response to this thread. :)

Let me know if there are any more desired output. :)

Peace...

Tom

Hi,

On Thu, 2006-11-02 at 03:41 +0100, Stephan Hegel wrote:

It does not break the mechanism of "configure && make && make install" as everything could be embedded fully transparent within this procedure, even the installation of a wrapper. The user even wouldn't notice.

This discussion is pretty much pointless to have. The development releases are there to test the upcoming stable 2.4 release. We are not going to introduce the possibility that problems with our build system are show up when such a wrapper script is removed for the final 2.4.0 release.

Why don't you just pass --enable-binreloc to configure and simply call the resulting binary directly? It will then figure out where to find the libraries and data files relative to the location of the binary.

Sven

Sven Neumann wrote:

Why don't you just pass --enable-binreloc to configure and simply call the resulting binary directly? It will then figure out where to find the libraries and data files relative to the location of the binary.

Thanks for this hint. Meanwhile I've solved the problem as described in an earlier posting, even without a wrapper.

However, I will remember this option when I run in trouble again ...

Kind regards, Stephan.