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 desc
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
On Thursday 02 November 2006 09:16, 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
Stephan Hegel wrote:
Tom Williams wrote:
Sure can. :)
START-
[EMAIL PROTECTED]:~$ echo $LD_LIBRARY_PATH
[EMAIL PROTECTED]:~$
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 d
Toby Haynes wrote:
Tom Williams wrote:
---START-
[EMAIL PROTECTED]:~$ file /usr/bin/gimp
/usr/bin/gimp: symbolic link to `gimp-2.2'
[EMAIL PROTECTED]:~$ 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, dynamica
Tom Williams wrote:
> Sure can. :)
>
> START-
>
> [EMAIL PROTECTED]:~$ echo $LD_LIBRARY_PATH
>
> [EMAIL PROTECTED]:~$
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 i
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 wrapper
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
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 re
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 wrap
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 runnin
> 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 r
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
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.
>
>
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
>
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
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 si
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
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
Y
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
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
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
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
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
--
GIMP > http://www.gimp.org | IRC: irc://irc.gimp.org/gimp
Wiki
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:
---
-- Original message --
From: "John R. Culleton" <[EMAIL PROTECTED]>
> 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:
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
27 matches
Mail list logo
