Skip Menu |

This queue is for tickets about the Imager CPAN distribution.

Report information
The Basics
Id: 57518
Status: resolved
Priority: 0/
Queue: Imager

People
Owner: Nobody in particular
Requestors: jrcd83 [...] gmail.com
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: [PATCH] libtiff detection fails if using non-standard lib dir
Date: Sat, 15 May 2010 14:22:58 -0700
To: bug-Imager [...] rt.cpan.org
From: Justin Davis <jrcd83 [...] gmail.com>
I have installed my libtiff, libjpeg etc library in a non-standard location. This way I won't break my websites when I do system upgrades, etc. All the libraries are detected except libtiff, which uses Devel::CheckLib. Very funky stuff, but I found out it fails because the compiled test (C) program won't run. It won't run because it can't find the libraries! So I created a patch to set LD_LIBRARY_PATH if we are running linux. I don't know how to fix this with other OSes. I added a WARNING because Devel::CheckLib does not run the compiled test file anymore, it seems. If it still did I would submitted a bug report to them instead. I also used the 3-arg form of open, since you already have the file path in a variable... and it's nicer looking. diff --git a/Makefile.PL b/Makefile.PL index 0b71b80..d71440b 100644 --- a/Makefile.PL +++ b/Makefile.PL @@ -1026,6 +1026,11 @@ sub postcheck_tiff { $lib = "tiff"; } + # Fix our non-standard lib paths for runtime as well. + local $ENV{'LD_LIBRARY_PATH'} = join q{:}, + ( @{ $format->{libdir} }, ( $ENV{'LD_LIBRARY_PATH'} || qw// )) + if $^O eq 'linux'; + my $good = eval { assert_lib @@ -1047,12 +1052,13 @@ sub postcheck_tiff { return 0; } FUNCTION - ); + ); # WARNING: Devel::CheckLib might not execute this in newer versions! + # v0.699_002 only checks if it compiles and links properly. 1; }; unless ($good && -s $tiffver_name - && open(VERS, "< probe/tiffver.txt")) { + && open(VERS, '<', $tiffver_name)) { unlink $tiffver_name unless $KEEP_FILES; print <<EOS; **tiff: cannot determine libtiff version number
Sorry for the delayed response. On Sat May 15 17:23:12 2010, jrcd83@gmail.com wrote: Show quoted text
> I have installed my libtiff, libjpeg etc library in a non-standard > location. This way I won't break my websites when I do system > upgrades, etc. All the libraries are detected except libtiff, which > uses Devel::CheckLib. Very funky stuff, but I found out it fails > because the compiled test (C) program won't run. It won't run because > it can't find the libraries! So I created a patch to set > LD_LIBRARY_PATH if we are running linux. I don't know how to fix this > with other OSes.
With your change, doesn't make test fail, since LD_LIBRARY_PATH isn't set? I'm inclined not to make this change - the configure (Makefile.PL) environment should match the test environment. Show quoted text
> I added a WARNING because Devel::CheckLib does not run the compiled > test file anymore, it seems. If it still did I would submitted a bug > report to them instead.
I'm confused by this - the Devel::CheckLib bundled with Imager is very similar to the latest development release - both versions should be running the compiled test program. Show quoted text
> I also used the 3-arg form of open, since you already have the file > path in a variable... and it's nicer looking.
It is, I've been thinking about dropping support for 5.005, but haven't decided yet. Tony
Thanks Tony for responding I don't mind the delay! After finishing this email I decided I should preface it and let you know that I am sorry I should have filed this report with Devel::CheckLib. You are indeed correct and Devel::CheckLib still runs the program it compiles. If you are still curious I think I have given good reasons to patch in lieu of CheckLib accepting a patch. I will also give an updated patch at the end. (I ended up posting this with the web interface because the email came back "unsendable") On May 24, 2010, at 3:00 AM, TONYC via RT wrote: Show quoted text
> With your change, doesn't make test fail, since LD_LIBRARY_PATH isn't set?
make test does work without LD_LIBRARY_PATH... interesting! Show quoted text
> I'm inclined not to make this change - the configure (Makefile.PL) > environment should match the test environment.
I think you hit the nail on the head! What we are doing is matching the Makefile.PL to the Makefile environment. Your two paragraphs above made it click in my head. I didn't know this before, but the rpath is stored inside Imager.so. So the search path for my libraries is encoded into the file itself. I found the rpath with: find blib -name '*.so' -exec sh -c 'echo "{}" $(readelf -d {} | grep RPATH)' \; Imager.so is the only .so file in the blib with an rpath for some reason. I read about the rpath on this webpage: http://www.eyrie.org/~eagle/notes/rpath.html . According to it the rpath is compiled into the library if the LD_RUN_PATH environment variable is set. The Makefile sets the LD_RUN_PATH environment variable at line 627 for my Makefile. So you are right we are indeed trying to match Makefile.PL's runtime environment with the Makefile's. The Makefile uses LD_RUN_PATH (which turns into an rpath) and we have to use LD_LIBRARY_PATH to match the runtime environment in Makefile.PL. Show quoted text
> I'm confused by this - the Devel::CheckLib bundled with Imager is very > similar to the latest development release - both versions should be > running the compiled test program.
Ah you are right, I must have missed it in this line of Devel::CheckLib: push @wrongresult, $lib if $rv == 0 && -x $exefile && system(File::Spec->rel2abs($exefile)) != 0; Not very comely, that... I'm sorry though I feel silly now. I should file a bug on Devel::CheckLib's RT I think. By the way, thanks very much for Imager. I switched some code from ImageMagick. Your API is so much nicer. Its easier to compile and use! -Justin Here is another patch with less junk if you want one. local $ENV is inside the eval {} block now and I removed the bits you showed were unnecessary. open still uses the 2-arg form. I would like to write a test for this but I am unsure how. diff --git a/Makefile.PL b/Makefile.PL index 0b71b80..f209761 100644 --- a/Makefile.PL +++ b/Makefile.PL @@ -1028,6 +1028,12 @@ sub postcheck_tiff { my $good = eval { + # Fix our non-standard lib paths for runtime as well. + local $ENV{'LD_LIBRARY_PATH'} = + join q{:}, ( @{ $format->{libdir} }, + ( $ENV{'LD_LIBRARY_PATH'} || qw// )) + if $^O eq 'linux'; + assert_lib ( debug => $VERBOSE, @@ -1052,7 +1058,7 @@ FUNCTION }; unless ($good && -s $tiffver_name - && open(VERS, "< probe/tiffver.txt")) { + && open(VERS, "< $tiffver_name")) { unlink $tiffver_name unless $KEEP_FILES; print <<EOS; **tiff: cannot determine libtiff version number
On Mon May 24 14:18:13 2010, JUSTER wrote: Show quoted text
> I read about the rpath on this webpage: > http://www.eyrie.org/~eagle/notes/rpath.html . > According to it the rpath is compiled into the library if the > LD_RUN_PATH environment > variable is set. The Makefile sets the LD_RUN_PATH environment > variable at line 627 for my > Makefile. > > So you are right we are indeed trying to match Makefile.PL's runtime > environment with the > Makefile's. The Makefile uses LD_RUN_PATH (which turns into an rpath) > and we have to use > LD_LIBRARY_PATH to match the runtime environment in Makefile.PL.
Sorry for the delay on this. I've modified Imager's Makefile.PL to populate LD_RUN_PATH when calling assert_lib() to match the Makefile environment. If you have a chance, could you please try Imager from svn to see if it solves the problem for you? If you have svn: svn co http://imager.perl.org/svn/trunk/Imager perl Makefile.PL # add options here, eg. --incpath, --libpath (please check or report the output here) make test If you don't have easy access to svn on the machine where the problem occurred, please let me know and I'll make a dev release. Thanks for reporting this problem. Tony
On Sat May 15 17:23:12 2010, jrcd83@gmail.com wrote: Show quoted text
> I have installed my libtiff, libjpeg etc library in a non-standard > location. This way I won't break my websites when I do system > upgrades, etc. All the libraries are detected except libtiff, which > uses Devel::CheckLib. Very funky stuff, but I found out it fails > because the compiled test (C) program won't run. It won't run because > it can't find the libraries! So I created a patch to set > LD_LIBRARY_PATH if we are running linux. I don't know how to fix this > with other OSes.
This has been fixed in Imager 0.77, which now sets LD_RUN_PATH in the same way the Makefile does. Thank you for the report. Tony
Subject: Re: [rt.cpan.org #57518] [PATCH] libtiff detection fails if using non-standard lib dir
Date: Tue, 17 Aug 2010 18:26:10 -0700
To: bug-Imager [...] rt.cpan.org
From: Justin Davis <jrcd83 [...] gmail.com>
Thanks very much Tony! I tried the SVN checkout (rev 1805) and libtiff works perfect! I hate to say this but now libpng is no longer working... Here is the relevant output when I run: perl Makefile.PL --incpath $SSPATH/include --libpath $SSPATH/lib ($SSPATH is my website's prefix) PNG: Not found via pkg-config PNG: includes found - libraries found /home/juster/build/Imager/PNG/assertlibs9pNNdD7: error while loading shared libraries: libpng14.so.14: cannot open shared object file: No such file or directory PNG: Test code failed: wrong result: 'png' I tried again, setting the PKG_CONFIG_PATH variable for pkg-config's benefit (this is after I noticed the pkg-config message above): PKG_CONFIG_PATH=$SSPATH/lib/pkgconfig perl Makefile.PL --incpath $SSPATH/include --libpath $SSPATH/lib (Woo that's a big-un!) I got slightly different output when using the above command: PNG: Found via pkg-config libpng14 /home/juster/build/Imager/PNG/assertlibclcOhYhW: error while loading shared libraries: libpng14.so.14: cannot open shared object file: No such file or directory PNG: Test code failed: wrong result: 'png14' I will dig into this more and get back to you, hopefully with a patch. I have only scanned the code. I did notice libpng's detection specification is commented out and is now different from the other libraries. Also the pkg-config message tells me you are using pkg-config now. I have no experience with pkg-config but it looks interesting. Right now the old (patched) version of Imager for my website is working great. This could take me several weeks to get around to it. Unfortunately I have only a few days home that I must use to work on a different website. I'm sorry for the delays in general and hope to get back to you soon. Thanks, Justin Davis JUSTER@CPAN
Subject: Re: [rt.cpan.org #57518] [PATCH] libtiff detection fails if using non-standard lib dir
Date: Tue, 17 Aug 2010 18:34:27 -0700
To: bug-Imager [...] rt.cpan.org
From: Justin Davis <jrcd83 [...] gmail.com>
I'm sorry I re-opened your ticket, I didn't know that happened automatically. Should I create a new one for this new libpng problem?
CC: undisclosed-recipients: ;
Subject: Re: [rt.cpan.org #57518] [PATCH] libtiff detection fails if using non-standard lib dir
Date: Wed, 18 Aug 2010 15:39:37 +1000
To: Justin Davis via RT <bug-Imager [...] rt.cpan.org>
From: Tony Cook <tony [...] develop-help.com>
On Tue, Aug 17, 2010 at 09:34:38PM -0400, Justin Davis via RT wrote: Show quoted text
> Queue: Imager > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=57518 > > > I'm sorry I re-opened your ticket, I didn't know that happened automatically. Should I create a new one for this new libpng problem?
A new ticket please. Tony