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 at stdin. 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@@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@@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 disastrous results. 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, -- Jerry James http://www.jamezone.org/ _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
