igraph-help
[Top][All Lists]
Advanced

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

Re: [igraph] Import error in Python


From: Tamás Nepusz
Subject: Re: [igraph] Import error in Python
Date: Sun, 23 Mar 2014 20:35:44 +0100

Hi Pietro,

Sorry for the late reply -- the last few days have been quite busy for me at 
work. Anyway, I haven’t been following recent developments in the Debian 
package repos lately so I wasn’t aware that our packages (that we mainly build 
for Ubuntu Linux and not Debian) do not work with the most recent Debian 
release -- they used to work for quite a long time.

Anyway, I’m installing Debian in a VM now and I’ll read your emails carefully. 
Hopefully I’ll be able to figure out what’s wrong soon and then I’ll send you 
an updated package (and probably send a patch to the Debian project as well).

All the best,
--  
T.

------------------------------------------------------
From: Pietro Battiston address@hidden
Reply: Pietro Battiston address@hidden
Date: 20 March 2014 at 10:33:15
To: Tamás Nepusz address@hidden
Cc: Help for igraph users address@hidden
Subject:  Re: [igraph] Import error in Python

> Il giorno mer, 19/03/2014 alle 23.49 +0100, Tamás Nepusz ha scritto:
> > Hello,
> >
> > Can you please try the packages from
> > https://launchpad.net/~igraph/+archive/ppa instead of the official
> > Debian repos?
>  
> If I simply install the python-igraph package from there, (with or
> without recompiling it), I get the same exact problem.
>  
> If I try to install your version of libigraph0-dev in order to recompile
> it, I'm asked to install the corresponding version of libigraph0, (which
> makes sense).
>  
> If I try to install the corresponding version of libigraph0, I am stuck
> with a dependency, libglpk0, which is not present in the (debian
> testing) archives.
>  
> If I try to remove the dependency and rebuild libigraph0-dev, I get an
> error "dpkg-source: error: can't build with source format '3.0
> (native)': native package version may not have a revision".
>  
> If I change the content of debian/format/source to "3.0 (quilt)" and
> again rebuild, I get an error "dpkg-source: error: can't build with
> source format '3.0 (quilt)': no upstream tarball found
> at ../igraph_0.6.5.orig.tar.{bz2,gz,lzma,xz}"
>  
> If I give "ln -s igraph_0.6.5-4~ubuntu13.04.1.tar.gz
> igraph_0.6.5.orig.tar.gz" in the parent directory and again rebuild, the
> build process goes on a bit, then stops with
> "libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -g -O2
> -I/usr/include/libxml2 -I../include -I../include -Wall -g -O2
> -I/usr/include/libxml2 -c foreign-ncol-parser.c -o
> libigraph_la-foreign-ncol-parser.o >/dev/null 2>&1
> /bin/bash ../ylwrap foreign-ncol-lexer.l lex.yy.c foreign-ncol-lexer.c
> -- flex
> /bin/bash ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I.
> -I.. -g -O2 -I/usr/include/libxml2 -I../include -I../include -Wall -g
> -O2 -I/usr/include/libxml2 -c -o libigraph_la-foreign-ncol-lexer.lo
> `test -f 'foreign-ncol-lexer.c' || echo './'`foreign-ncol-lexer.c
> libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -g -O2
> -I/usr/include/libxml2 -I../include -I../include -Wall -g -O2
> -I/usr/include/libxml2 -c foreign-ncol-lexer.c -fPIC -DPIC
> -o .libs/libigraph_la-foreign-ncol-lexer.o
> In file included from foreign-ncol-lexer.l:49:0:
> foreign-ncol-parser.h:88:26: error: unknown type name
> 'igraph_i_ncol_parsedata_t'
> int igraph_ncol_yyparse (igraph_i_ncol_parsedata_t* context);
> ^
> make[4]: *** [libigraph_la-foreign-ncol-lexer.lo] Error 1
> make[4]: Leaving directory
> `/home/pietro/cancellami/versione_ubuntu/igraph-0.6.5/src'
> make[3]: *** [all] Error 2
> make[3]: Leaving directory
> `/home/pietro/cancellami/versione_ubuntu/igraph-0.6.5/src'
> make[2]: *** [all-recursive] Error 1
> make[2]: Leaving directory
> `/home/pietro/cancellami/versione_ubuntu/igraph-0.6.5'
> make[1]: *** [all] Error 2
> make[1]: Leaving directory
> `/home/pietro/cancellami/versione_ubuntu/igraph-0.6.5'
> dh_auto_build: make -j1 returned exit code 2
> make: *** [build] Error 2
> dpkg-buildpackage: error: debian/rules build gave error exit status 2
> "
>  
> At this point I gave up - I will simply wait and hope for the Debian bug
> to be solved, and in the meanwhile find some other solution.
>  
> By the way: I may be wrong, but to the best of my understanding, the
> line "dh $@ --with python2" in the debian/rules of your igraph package
> does not make much sense - this is not a python package. The
> corresponding line in the official debian package is "dh $@ --parallel
> --with autoreconf".
>  
> By the way, the debian/rules of your igraph package and Debian's
> official one apparently only differ for two things:
> 1) yours has "[ -f configure ] || ./bootstrap.sh" in
> override_dh_auto_configure
> 2) Debian's has the flag "--enable-gmp".
>  
> Curiously, however, the debian package compiles correctly, and does so
> even if I add the line in 1) and remove the flag in 2)!
> ... but then, the original error persists.
>  
> By the way: the debian/rules of the python-igraph from the official
> archives is _much_ cleaner, you may want to take a look at/copypaste it.
>  
> > The ones in the Debian repos are prepared by the Debian Python Modules
> > Team as far as I know so we cannot do anything with it.
>  
> I totally respect and admire your work on igraph, and I guess you have
> good reasons to only focus on your PPA's packages... but this particular
> claim is slightly laughable: you could certainly provide a patch.
>  
> All the best,
>  
> Pietro
>  
>  
> > The ones on Launchpad are built by us.
> >
> > > I also tried a hack analogous to what suggested here:
> > > http://byeworld.blogspot.it/2009/01/libf2cso-undefined-reference-to-main.html
> > >   
> > > with the only result of changing the error message to:
> > > ImportError: /home/pietro/mylib/libf2c.so.2: invalid ELF header
> > That won’t work in your case; it would be useful if you compiled the igraph 
> > library on  
> your own -- the hack on that page basically replaces the dynamic version of 
> the libf2c  
> library with the static version, which essentially means that any code being 
> compiled  
> and linked to libf2c will automatically link to its static version even if 
> the compiler  
> requested the dynamic version.
> >
> > Best,
> > T.
>  
>  
>  




reply via email to

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