Tonight I am trying to figure out why gfan failed the mass rebuild.
I'm a bit confused, so I'm writing in the hopes that one of you
recognizes what is going on.
The gfan library is linked with libcddgmp. Libcdd can be built with
or without gmp support. Polymake, weirdly, wants to link with both
versions, so libcdd is built without gmp support and libcddgmp is
built with gmp support. Polymake expects the gmp version to have
symbols that are suffixed with _gmp. Other cddlib consumers, such as
gfan, don't specify whether they want the gmp or non-gmp versions, and
expect the symbols to be the same in either case.
To satisfy all of the consumers, and let us use the more efficient gmp
version in the non-polymake case, we build the gmp version of libcdd
with symbol aliases. The "real" names have the _gmp suffix so that
polymake can link with both versions of the library. However, we also
alias the symbol name without the _gmp suffix to the corresponding
_gmp name, for consumers like gfan.
Yes, it's a mess, but it has worked okay ... until now. On F-26 and
earlier, there have been no problems. But gfan failed the F-27 mass
rebuild, and the reason is that two of these aliased symbols now point
If I build the gfan binary, then run "gdb gfan", before I even start
the binary running, and therefore before any of its shared objects are
loaded, I get this:
(gdb) print &dd_purezero
$1 = (<data variable, no debug info> *) 0x94a740 <stdin@(a)GLIBC_2.2.5>
(gdb) print &dd_purezero_gmp
No symbol "dd_purezero_gmp" in current context.
(gdb) print &dd_one
$2 = (<data variable, no debug info> *) 0x94a740 <stdin@(a)GLIBC_2.2.5>
(gdb) print &dd_minusone
No symbol "dd_minusone" in current context.
(gdb) print &dd_minusone_gmp
No symbol "dd_minusone_gmp" in current context.
Where dd_purezero, dd_one, and dd_minusone are all mpq_t variables
declared in libcddgmp. When the shared library is actually loaded,
all of the symbols resolve appropriately, except dd_one and
dd_purezero, which continue to point at stdin, with predictably
I can't figure out why those two names point at stdin after the
initial load of the binary. If any of you have any clues as to what
is going on here, I would really like to know. Thank you,