libGD

GD is an open source code library for the dynamic creation of images by programmers. GD is written in C, and “wrappers” are available for Perl, PHP and other languages. GD creates PNG, JPEG and GIF images, among other formats. GD is commonly used to generate charts, graphics, thumbnails, and most anything else, on the fly. While not restricted to use on the web, the most common applications of GD involve web site development.

See the GD website for more informations.

| Tasklist |

FS#149 — Unable to install with "non-standard" library path

Attached to Project — libGD
Opened by Peter Jeremy (peter) - Thursday, 14 February 2008, 23:03 GMT+2
Last edited by Pierre Joye (Pierre) - Monday, 10 March 2008, 00:09 GMT+2
Task Type Bug Report
Category General
Status Assigned
Assigned To Pierre Joye (Pierre)
Operating System Other
Severity High
Priority Normal
Reported Version 2.0.36RC1
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No

Details

I am building on SPARC Solaris 10 in 64-bit mode. In keeping with the layout used for system libraries, I have 32-bit libraries in /usr/local/lib and 64-bit libraries in /usr/local/lib/sparcv9 - though the linker only special-cases /lib and /usr/lib and requires the full path to other libraries, rather than looking for a sparcv9 sub-directory.

The libtool built with gd has “/usr/local/lib” hard-coded in sys_lib_search_path_spec. This is incorrect because /usr/local/lib is not part of the system search path.

Whilst the initial gd build works correctly, during the “make install”, libdg.la is relinked and this fails because libtool deletes the correct ‘-L/usr/local/lib/sparcv9’ from the arguments passed to ld, whilst retaining the incorrect ‘-L/usr/local/lib’.

The same problem was encountered with 2.0.35. In that version, I also tried deleting references to /usr/local/lib from Makefile, libtool and test/Makefile after running configure. This removed the incorrect ‘-L/usr/local/lib’ but I have been unable to work out how to get libtool to use the correct library as specified on the command line.

I have examined the gd port on FreeBSD and notice that it avoids the problem by completely bypassing the supplied configure script. Having wasted a day trying to make configure work, I think the FreeBSD approach is correct.

   typescript (63.3 KiB)
This task depends upon

Comment by Pierre Joye (Pierre) - Friday, 15 February 2008, 01:35 GMT+2

Hi Jeremey, 

Whilst the initial gd build works correctly, during the “make install”, libdg.la is relinked and this fails because libtool deletes the correct 
‘-L/usr/local/lib/sparcv9’ from the arguments passed to ld, whilst retaining the incorrect ‘-L/usr/local/lib’.

Have you tried to use the libdir configure option?

I sadly have no access to a sparc to test GD (build or runtime). What do you mean by "Completely bypassing the configure script"? They don't use our scripts at all?

More generally, it would greatly appreciated if I can get a solaris access to test GD, both the build scripts and runtime.

We are moving to CMake which is supposed to work well on Solaris and some of our new features may behave differently on a sparc architecture (endianness, floating point arithmetic and rounding issues, etc.).

Thanks for your detailled report!

Comment by Pierre Joye (Pierre) - Friday, 15 February 2008, 01:36 GMT+2
  • Field changed: Due in Version (Undecided → 2.0.36)

assigned to me and add to the 2.0.36 todos

Comment by Peter Jeremy (peter) - Friday, 15 February 2008, 03:10 GMT+2

Hi Pierre,

I did specify "–libdir=/usr/local/lib/sparcv9" in the configure line (see the typescript that I attached) and it correctly assigns 'libdir' in the generated Makefile and libgd.la but it ignored by libtool.

Unfortunately, I cannot give you access to the Solaris machines I am using due to corporate security policies. I am not sure if Sun have a program to offer SPARC access for freeware development. Alternatively, the main Sun freeware site appears to be www.blastwave.org and a package of gd-2.0.33 is available there so the maintainer of that package may be in a position to help.

I am currently using gd on FreeBSD and wanted to see how they FreeBSD port got around the configure problem but when I looked I found that the port uses a pre-defined Makefile to build gd, in conjunction with some sed scripts in the port Makefile. This was implemented when the port was updated from gd-1.8.4 to gd-2.0.15 but no explanation was given for using this approach.

Comment by Pierre Joye (Pierre) - Friday, 15 February 2008, 20:53 GMT+2
I did specify "–libdir=/usr/local/lib/sparcv9" in the configure line (see the typescript that I attached) and it correctly assigns 'libdir' in the generated Makefile and libgd.la but it ignored by libtool.

I will try again with open solaris, maybe there is the same issue. However the last time I tried everything went well.

Unfortunately, I cannot give you access to the Solaris machines I am using due to corporate security policies. I am not sure if Sun have a program to offer SPARC access for freeware development. Alternatively, the main Sun freeware site appears to be www.blastwave.org and a package of gd-2.0.33 is available there so the maintainer of that package may be in a position to help.

I did not know this repository, thanks for the link! I will contact about this bug and about the outdated version they are using.

I may ask Sun if they have some tests platform, it is for their own good anyway (I do a lot for php as well :)

I will keep you informed here about our progress.

Comment by Pierre Joye (Pierre) - Monday, 10 March 2008, 00:09 GMT+2
  • Field changed: Due in Version (2.0.36 → Undecided)

hi!

Change to undecided version. I still have no access to any solaris/sparc system and it is likely to be a libtool bug.

In the meantime, can you try to contact the libtool project and see if they know this problem?

Loading...