Fedora build challenges

Discussions on installation issues go here.

Moderator: Moderators

jamesjer
Posts: 26
Joined: 01 Mar 2012, 16:51

Fedora build challenges

Postby jamesjer » 01 Mar 2012, 17:58

I'm going to post a series of short notes about problems I've encountered while trying to make a Fedora package of polymake. Fedora cannot ship JavaView, due to its license, but can ship jReality, so I want to configure polymake --with-java and --without-javaview. This doesn't work in version 2.11 though, due to line 188 of support/configure.pl:

} elsif ($arg =~ /--without-(java|javaview|callable)/) {

When --without-javaview is supplied, the regular expression matcher matches up to --without-java and decides it has found a match. To force it to match all of --without-javaview, adding an end anchor is sufficient, as in this patch.
Attachments
polymake-config.patch
Patch to fix --without-javaview
(521 Bytes) Downloaded 316 times

User avatar
gawrilow
Main Author
Posts: 354
Joined: 25 Dec 2010, 17:40

Re: Fedora build challenges

Postby gawrilow » 02 Mar 2012, 10:21

Yes, a clear stupid bug. Thanks a lot for watching out!

jamesjer
Posts: 26
Joined: 01 Mar 2012, 16:51

Re: Fedora build challenges

Postby jamesjer » 02 Mar 2012, 22:15

Thanks for your reply. Here's the next issue. I'm building with perl 5.14.2. The build stopped like this:

make[1]: Leaving directory `/home/jamesjer/rpmbuild/BUILD/polymake-2.11/build.x86_64/apps/graph'
/usr/bin/perl perl/polymake --script configure_java
polymake: ERROR: Undefined subroutine &Polymake::User::reconfigure called at /home/jamesjer/rpmbuild/BUILD/polymake-2.11/scripts/configure_java line 21.
make: *** [compile-java-jars] Error 1

I added "use Polymake::Core::InteractiveCommands;" to scripts/configure_java to see if that would fix the problem. It did, but I have the uncomfortable feeling that that isn't right. Is there a better solution to this problem?

jamesjer
Posts: 26
Joined: 01 Mar 2012, 16:51

Re: Fedora build challenges

Postby jamesjer » 02 Mar 2012, 22:30

The callable library, libpolymake.so, has two undefined symbols:

xmlGetExternalEntityLoader
xmlSetExternalEntityLoader

I see that support/corelib.make builds Ext.so with LIBXML2_LIBS, but does not use those libraries when building the CallableLib target, which includes all of the *.o files in Ext.so.

jamesjer
Posts: 26
Joined: 01 Mar 2012, 16:51

Re: Fedora build challenges

Postby jamesjer » 02 Mar 2012, 22:39

When building with rpm, first the sources are compiled, then they are installed into a staging area where the package is created. Unfortunately, running "make install DESTDIR=$RPM_BUILD_ROOT" rewrites conf.make with the new $DESTDIR path, which leads to recompilation of a few files, with the result that paths into the staging area are compiled into the final library. I do this just before "make install" to prevent that from happening:

sed -i "/conf\.make/d" support/corelib.make

Will that have any ill effects? Is there a better way to avoid this problem? Thank you.

User avatar
gawrilow
Main Author
Posts: 354
Joined: 25 Dec 2010, 17:40

Re: Fedora build challenges

Postby gawrilow » 02 Mar 2012, 23:06

... The build stopped like this:

make[1]: Leaving directory `/home/jamesjer/rpmbuild/BUILD/polymake-2.11/build.x86_64/apps/graph'
/usr/bin/perl perl/polymake --script configure_java
polymake: ERROR: Undefined subroutine &Polymake::User::reconfigure called at /home/jamesjer/rpmbuild/BUILD/polymake-2.11/scripts/configure_java line 21.
make: *** [compile-java-jars] Error 1

I added "use Polymake::Core::InteractiveCommands;" to scripts/configure_java to see if that would fix the problem. It did, but I have the uncomfortable feeling that that isn't right. Is there a better solution to this problem?
This script should be run with an option --iscript, not --script. See the main Makefile for an example.
If it tries to ask you questions which you don't like, then you should better avoid using it at all.
JavaView seems to be kind of a dead (or zombie) project, I think we'll drop the official support for it in the next releases at all.

User avatar
gawrilow
Main Author
Posts: 354
Joined: 25 Dec 2010, 17:40

Re: Fedora build challenges

Postby gawrilow » 02 Mar 2012, 23:11

The callable library, libpolymake.so, has two undefined symbols:

xmlGetExternalEntityLoader
xmlSetExternalEntityLoader

I see that support/corelib.make builds Ext.so with LIBXML2_LIBS, but does not use those libraries when building the CallableLib target, which includes all of the *.o files in Ext.so.
Damned, you are right again! Nobody seems to have tried out loading XML files from a program linked with the callable library yet. We must add these flags to the link command for libpolymake.so. Please find attached patch.
Attachments
callable.diff
(1.06 KiB) Downloaded 340 times

jamesjer
Posts: 26
Joined: 01 Mar 2012, 16:51

Re: Fedora build challenges

Postby jamesjer » 02 Mar 2012, 23:46

... The build stopped like this:

make[1]: Leaving directory `/home/jamesjer/rpmbuild/BUILD/polymake-2.11/build.x86_64/apps/graph'
/usr/bin/perl perl/polymake --script configure_java
polymake: ERROR: Undefined subroutine &Polymake::User::reconfigure called at /home/jamesjer/rpmbuild/BUILD/polymake-2.11/scripts/configure_java line 21.
make: *** [compile-java-jars] Error 1

I added "use Polymake::Core::InteractiveCommands;" to scripts/configure_java to see if that would fix the problem. It did, but I have the uncomfortable feeling that that isn't right. Is there a better solution to this problem?
This script should be run with an option --iscript, not --script. See the main Makefile for an example.
If it tries to ask you questions which you don't like, then you should better avoid using it at all.
JavaView seems to be kind of a dead (or zombie) project, I think we'll drop the official support for it in the next releases at all.
Ah, I caused the problem myself then, by changing --iscript to --script. Well, I did that because an RPM build isn't interactive. I'm going to have to dig deeper on this, then, to see how I can be sure no questions will be asked during a build.

jamesjer
Posts: 26
Joined: 01 Mar 2012, 16:51

Re: Fedora build challenges

Postby jamesjer » 02 Mar 2012, 23:52

This is the last problem for now, I think. I see two undefined symbols in tropical.so. They are C++ symbols, which demangle to:

polymake::tropical::tropicalize(pm::Polynomial<pm::UniPolynomial<pm::Rational, pm::Rational>, int> const&)

polymake::tropical::pointlift(pm::Vector<pm::Rational> const&,
pm::Ring<pm::UniPolynomial<pm::Rational, pm::Rational>, int> const&)

I see that both are declared in apps/tropical/include/liftings.h, and are used in apps/tropical/src/points2hypersurface.c. But I don't see definitions for either.

Thanks for your replies. Regards,
Jerry James

User avatar
gawrilow
Main Author
Posts: 354
Joined: 25 Dec 2010, 17:40

Re: Fedora build challenges

Postby gawrilow » 03 Mar 2012, 00:12

When building with rpm, first the sources are compiled, then they are installed into a staging area where the package is created. Unfortunately, running "make install DESTDIR=$RPM_BUILD_ROOT" rewrites conf.make with the new $DESTDIR path, which leads to recompilation of a few files, with the result that paths into the staging area are compiled into the final library. I do this just before "make install" to prevent that from happening:

sed -i "/conf\.make/d" support/corelib.make

Will that have any ill effects? Is there a better way to avoid this problem? Thank you.
Funny enough, I could not reproduce this. Actually, the parts of the callable library depend on conf.make created by configure.pl in the working build directory, while the file being rewritten during 'make install' is its copy in the destination directory, so that they shouldn't interfere. Probably you have modified something else in the build process. If it helps you anyhow, please have a look into attached spec file I've used for OpenSUSE rpm package. Surely, it contains quite a few SUSE-specific macros, but the whole idea should be still the same.

But if nothing else helps, your fix shouldn't do any harm.
Attachments
polymake.spec.patch
Don't mind the funny suffix, it's just to fool our overly rigid forum configuration.
(3.17 KiB) Downloaded 327 times


Return to “Installing polymake”

cron