Graphviz Issue Tracker
Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0001015graphvizBuild/Installpublic2005-12-06 05:582011-04-28 04:03
ReporterRobert Atwood 
Assigned Toellson 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionsuspended 
PlatformOSOther-Linux-Suse 9.1OS Version
Summary0001015: Build problems on x86-64
Description



During the build process, the configured compiler flags attempt to access several
of the required libraries by absoulute path eg /usr/lib/libjpeg.so, even though the
configure script has also set the -L/usr/lib64 flag correctly. This causes the build to fail
as the linker tries to load the 32 bit symbols.



The MAKE terminates with:
<CD>
gcc -shared .libs/gd.o .libs/gdfx.o .libs/gd_security.o .libs/gd_gd.o .libs/gd_gd2.o .libs/gd_io.o .libs/gd_io_dp.o .libs/gd_gif_in.o .libs/gd_gif_out.o .libs/gd_io_file.o .libs/gd_io_ss.o .libs/gd_jpeg.o .libs/gd_png.o .libs/gd_ss.o .libs/gd_topal.o .libs/gd_wbmp.o .libs/gdcache.o .libs/gdfontg.o .libs/gdfontl.o .libs/gdfontmb.o .libs/gdfonts.o .libs/gdfontt.o .libs/gdft.o .libs/gdhelpers.o .libs/gdkanji.o .libs/gdtables.o .libs/gdxpm.o .libs/wbmp.o -L/usr/local/encap/graphviz-2.6.0/lib /usr/lib64/libfontconfig.so -L/usr/lib64 /usr/lib64/libfreetype.so /usr/lib/libjpeg.so /usr/lib64/libjpeg.so -lpng -lz -lm -Wl,-soname -Wl,libgvgd.so.2 -o .libs/libgvgd.so.2.0.0
/usr/lib/libjpeg.so: could not read symbols: Invalid operation
collect2: ld returned 1 exit status
make[3]: *** [libgvgd.la] Error 1
make[3]: Leaving directory `/hive2tmp/sources/local/graphviz-2.6/lib/gd'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/hive2tmp/sources/local/graphviz-2.6/lib'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/hive2tmp/sources/local/graphviz-2.6'
make: *** [all] Error 2
</CD>



Correcting the jpeg library location results in another one like this, etc.






The problem can be worked around by



./configure --with-gdlibdir=/usr/local/lib64 --with-jpeglibdir=/usr/lib64 --with-expatlibdir=/usr/lib64



but those less experienced that I might have trouble seeing what the problem is






But why not use -L/usr/lib64 -ljpeg for the default ???



Here are the \<A HREF=b836.txt\>config.log\</A\> and
\<A HREF=b836a.txt\>output\</A\> of make.
Additional Information

[ellson] Thats very weird. I've been building on x86_64 Fedora systems for a year and not seen this problem, and it does pick up
the /usr/lib64 versions of jpeg and expat.
It may be because I have both 64 bit and 32 bit versions of these libraries and that configure picks up one then uses the other.
Do you have both versions installed?

The configure.ac file doesn't look right. I've made this change in CVS for the graphviz-2.7 development series. It should fix
libjpeg and libexpat. I don't see any problem with gdlibdir. Since there is no gd > 2.0.33 it should be using the internal version.

<r.atwood>
If it worked building on x86_64 Fedora, perhaps it is a suse-ism then? I
have been doing a lot of distribution hopping lately and notice how the
libraries are located and linked differently on different ones. [Also ,
I did not actually check for a graphviz Suse package, I notice that it
does exist on mirror.ac.uk so I may have avoided the problem at the
expense of a less up-to-date version, 1.11.26] Of course it would be
nice if it just worked on all (sane) distributions ... My own software
is a LONG WAY from that though.

In case it helps, here's what is installed. These libraries are still
the default Suse-9.1 + any online upgrades. The system was installed by
our vendor (i.e. I did not do the original installation)

Usually I found that the link step with -L/usr/lib -L/usr/lib64
-l<somelibrary>, when producing -m64 executable, produces a warning as
it scans the 32 bit version but continues to check the 64 bit version
and succeeds. In this case I think it fails because of the entry
/usr/lib/libjpeg.so instead of -ljpeg , forcing the linking of this
library . I cannot figure out where this comes from , the closest is the
following lines in config.ac at line 1231 where the entry gets set to
/usr/lib/libjpeg.la if it exists, but not to the shared one!? In fact,
delving into the build subdirectory, I find that the Makefile in lib/gd
has exactly that, so it is a mystery to me where it gets libgd.so from.
Probably your patch will fix the behaviour as /usr/lib should be changed
to /usr/lib64 , but would it not be better to use the -static flag to
gcc if you want to force a static link, then it should use the usual
search path ? Perhaps I don't understand the rationale for trying to
force the .la library here.

Having never used autoconf/automake/ I have no idea how to get the
configure script to do that.

<CD>
(lib/gd/Makefile after ./configure) :
JPEG_LIBS = /usr/lib/libjpeg.la -ljpeg


(configure.ac as in the 2.6 download)

   1226 if test "$JPEG_LIBDIR" != "/usr/lib"; then
   1227 JPEG_LIBS="-L$JPEG_LIBDIR"
   1228 LDFLAGS="$LDFLAGS $JPEG_LIBS"
   1229 fi
   1230 if test -f "$JPEG_LIBDIR/libjpeg.la"; then
   1231 JPEG_LIBS="$JPEG_LIBDIR/libjpeg.la"
   1232 fi

[email protected]:~/ca_working/ca_head> ls -l /usr/lib64/libjp*
-rw-r--r-- 1 root root 216602 2004-04-06 04:24 /usr/lib64/libjpeg.a
-rwxr-xr-x 1 root root 471 2004-04-06 04:24 /usr/lib64/libjpeg.la
lrwxrwxrwx 1 root root 17 2005-12-06 11:27 /usr/lib64/libjpeg.so ->
libjpeg.so.62.0.0
lrwxrwxrwx 1 root root 17 2005-12-06 11:27 /usr/lib64/libjpeg.so.62
-> libjpeg.so.62.0.0
-rwxr-xr-x 1 root root 150419 2004-04-06 04:24
/usr/lib64/libjpeg.so.62.0.0
[email protected]:~/ca_working/ca_head> ls -l /usr/lib/libjp*
-rw-r--r-- 1 root root 162536 2004-04-06 02:07 /usr/lib/libjpeg.a
-rwxr-xr-x 1 root root 469 2004-04-06 02:07 /usr/lib/libjpeg.la
lrwxrwxrwx 1 root root 17 2005-12-06 11:27 /usr/lib/libjpeg.so ->
libjpeg.so.62.0.0
lrwxrwxrwx 1 root root 16 2005-05-19 12:30 /usr/lib/libjpeg.so.6 ->
libjpeg.so.6.0.1
-rwxr-xr-x 1 root root 155043 2001-07-07 07:25
/usr/lib/libjpeg.so.6.0.1
lrwxrwxrwx 1 root root 17 2005-12-06 11:27 /usr/lib/libjpeg.so.62
-> libjpeg.so.62.0.0
-rwxr-xr-x 1 root root 137404 2004-04-06 02:07
/usr/lib/libjpeg.so.62.0.0
[email protected]:~/ca_working/ca_head>
</CD>

[ellson]
<CD>
I suspect some minor suse-ism is what exposed the problem, or perhaps more fairly
it is some fedora-ism that has kept it hidden until this point.

>
>
> In case it helps, here's what is installed. These libraries are still
> the default Suse-9.1 + any online upgrades. The system was installed by
> our vendor (i.e. I did not do the original installation)
>

I don't have a working suse boxe, so I'm relying on you and other suse users to
report problems like this. Graphviz has built in the past on suse, and I would
like it to again.

> Usually I found that the link step with -L/usr/lib -L/usr/lib64
> -l<somelibrary>, when producing -m64 executable, produces a warning as
> it scans the 32 bit version but continues to check the 64 bit version
> and succeeds.

Doesn't seem very clean. It would be better to just pick up the right one.

> In this case I think it fails because of the entry
> /usr/lib/libjpeg.so instead of -ljpeg , forcing the linking of this
> library . I cannot figure out where this comes from , the closest is the
> following lines in config.ac at line 1231 where the entry gets set to
> /usr/lib/libjpeg.la if it exists, but not to the shared one!?

Do you have both /usr/lib/libjpeg.a and /usr/lib64/libjpeg.a ?

You might want to add ---disable-static to your config options. I only ship shared
in binary packages. Both shared and static are built when building from source,
but mostly so that I can see what problems occur. The user doesn't need the static version
on Linux distros.

> In fact,
> delving into the build subdirectory, I find that the Makefile in lib/gd
> has exactly that, so it is a mystery to me where it gets libgd.so from.
>

It should be building an internal version of libgd, called libgvgd. It is supposed to
ignore any installed version of gd <2.0.34 which hasn't been released yet.

> Probably your patch will fix the behaviour as /usr/lib should be changed
> to /usr/lib64 , but would it not be better to use the -static flag to
> gcc if you want to force a static link, then it should use the usual
> search path ? Perhaps I don't understand the rationale for trying to
> force the .la library here.

Lets not go off on a -static sidetrack. You don't need it. If the problem seems to be related to
static building, please add --disable-static and verify that the shared build works ok.
After that we can investigate any static issues.
</CD>

TagsNo tags attached.
AUXILLARY-FILEShttp://www.graphviz.org/bugs/b836.txt [^] http://www.graphviz.org/bugs/b836a.txt [^]
DATE-FIXED
FIX-COMMENT
FORMER-ID836
INPUT-FILE
OUTPUT-FILE
STATUS-COMMENTInactive
VERSION     2.6
Attached Files

- Relationships

-  Notes
There are no notes attached to this issue.

- Issue History
Date Modified Username Field Change
2011-04-28 04:03 user1 New Issue
2011-04-28 04:03 user1 Assigned To => user695


MantisBT 1.2.5[^]
Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker