bug-glpk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug-glpk] Re: [Pkg-octave-devel] Bug#310226: octave2.9: FTBFS: linking


From: Rafael Laboissiere
Subject: [Bug-glpk] Re: [Pkg-octave-devel] Bug#310226: octave2.9: FTBFS: linking a shared lib to a static lib fails.
Date: Tue, 24 May 2005 09:14:59 +0200
User-agent: Mutt/1.5.6+20040907i

[ This is a reply to a bug report filled against the octave2.9 Debian
  package, which depends on glpk.  For further information, please see
  http://bugs.debian.org/310226 ]

* Kurt Roeckx <address@hidden> [2005-05-22 16:23]:

> Package: octave2.9
> Version: 2.9.2-2
> Severity: serious
> 
> Hi,
> 
> Your package is failing to build on a few arches (atleast hppa
> and amd64) because when you're creating the shared lib you're
> linking to a static version.  Static version should be compiled
> without -fPIC while shared version must be compiled with it.
> (See policy section 10.2)
> 
> This is giving the following error:
> /usr/bin/g++ -shared -o __glpk__.oct pic/__glpk__.o -L../libcruft -lcruft 
> -L../
> liboctave -loctave -L. -loctinterp -llapack-3 -lblas-3 -lfftw3 -lamd -lumfpack
> -lreadline  -lncurses -ldl -lhdf5 -lz -lm  
> -L/usr/lib/gcc-lib/x86_64-linux/3.3.
> 6 -L/usr/lib/gcc-lib/x86_64-linux/3.3.6/../../../../lib64 
> -L/usr/lib/gcc-lib/x8
> 6_64-linux/3.3.6/../../.. -L/lib/../lib64 -L/usr/lib/../lib64 -lhdf5 -lz 
> -lfrtb
> egin -lg2c -lm -lgcc_s -lglpk
> /usr/bin/ld: 
> /usr/lib/gcc-lib/x86_64-linux/3.3.6/../../../../lib64/libglpk.a(gl
> plib2.o): relocation R_X86_64_32 can not be used when making a shared object; 
> r
> ecompile with -fPIC
> /usr/lib/gcc-lib/x86_64-linux/3.3.6/../../../../lib64/libglpk.a: could not 
> read
>  symbols: Bad value
> collect2: ld returned 1 exit status
> 
> There are some solutions for this:
> - Ask the glpk maintainer to provide a shared lib.  This
>   is ussually the prefered solution.
> - Ask the glpk maintainer to provide a special static pic
>   (libglpk-pic.a or something) version and link to that
>   version.  This solution ussually isn't want you want.

This is actually an upstream problem.  It is trivial nowadays to add
Libtool support to a package and have shared libraries available.  I am
attaching below two slim patches for the glpk package which add Libtool
support.  The first patch regards only the upstream files, while the
second is for the Debian specific files.

After applying the patch, the usual "aclocal; libtoolize; automake;
autoconf" must be run, of course.  The built package contains:

$ debc | grep /usr/lib
drwxr-xr-x root/root         0 2005-05-24 08:58:22 ./usr/lib/
-rw-r--r-- root/root    520060 2005-05-24 08:58:22 ./usr/lib/libglpk.so.0.0.0
-rw-r--r-- root/root       802 2005-05-24 08:58:20 ./usr/lib/libglpk.la
-rw-r--r-- root/root    661238 2005-05-24 08:58:22 ./usr/lib/libglpk.a
lrwxrwxrwx root/root         0 2005-05-24 08:58:20 ./usr/lib/libglpk.so.0 ->
libglpk.so.0.0.0
lrwxrwxrwx root/root         0 2005-05-24 08:58:20 ./usr/lib/libglpk.so ->
libglpk.so.0.0.0



Please consider applying this patch either upstream or in the Debian
package.

-- 
Rafael

Attachment: glpk-libtool-upstream.patch
Description: Text document

Attachment: glpk-libtool-debian.patch
Description: Text document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]