I propose a workaround that instead of defining GC_INNER to __attribute__((__visibility__("hidden"))) define it to __attribute__((deprecated)). Actually, the symbols are only hidden for "if __GNUC__ >= 4" and a few other preprocessor conditionals for not building in Windows. Also, the GC_EXTERN definition appears suspicious: #define GC_EXTERN extern GC_INNER but the exported functions are now tagged GC_API. This should have been a work in progress upstream to make part of the api/abi not visible, but it is only exercised with gcc >= 4 (and should be on Windows builds, where GC_API uses some dll attributes for those functions). But the fact that gc-7.2alpha (since Fedora 15) did expert these symbols, and there is no library major bump makes at least solving an issue with the ecl package difficult to handle, as cannot create a gc package for a lower library major, and using a bundled copy of gc is not a good solution either. This problem also affects Fedora 17, that now has a broken ecl package. My interest on ecl working is because it is a core component of my work on packaging sagemath for Fedora. Spec URL: http://kenobi.mandriva.com/~pcpa/gc.spec SRPM URL: http://kenobi.mandriva.com/~pcpa/gc-7.2-2.fc18.src.rpm
Thanks! I'll take a look soon. In the meantime, if you've interest in committing it yourself, and co-maintaining gc going forward, feel free to apply for commit acls: https://admin.fedoraproject.org/pkgdb/acls/name
(In reply to comment #1) > Thanks! > > I'll take a look soon. > > In the meantime, if you've interest in committing it yourself, and > co-maintaining gc going forward, feel free to apply for commit acls: > https://admin.fedoraproject.org/pkgdb/acls/name Ok. I applied for commit acl, but I will wait for (more) upstream comments, as upstream replied my bug report/comment to the gc mailing list, asked for further information and commented about some changes they can do, not sorting out my suggestion.
I did a check on rawhide to see if any other package was broken, and after testing all of them, only ecl is broken, and need the tip of the patches I suggested upstream at https://github.com/pcpa/bdwgc I will wait a bit more for upstream that does not want to change the public gc-7.2 api (besides the symbols became hidden from gc-7.2 alpha to gc-7.2 release...). Discussion about my suggested patches can be seen at http://blog.gmane.org/gmane.comp.programming.garbage-collection.boehmgc/day=20120527 I need ecl working to then RFE maxima-ecl :-) both required by sagemath. From the check of what requires gc, I found: Macaulay2 asymptote bigloo ecl hop inkscape iwhd kaya nekovm synopsis w3m xz
OK, I'm about to update rawhide to gc-7.2b. In the meantime, you have my blessing to patch our build as you see fit to make it work with ecl. I'm curious however, why the insistence on maxima-ecl, when we already have several other usable maxima backends (sbcl in particular)?
(In reply to comment #4) > OK, I'm about to update rawhide to gc-7.2b. > > In the meantime, you have my blessing to patch our build as you see fit to > make it work with ecl. Thanks. I should only need to replace GC_INNER with GC_API to, I think 5 symbols of gc-7.2, or 3 of gc-7.3alpha, so that GC_INNER does not make those symbols required by ecl hidden. Building ecl with its bundled copy of gc should not be an option. > I'm curious however, why the insistence on maxima-ecl, when we already have > several other usable maxima backends (sbcl in particular)? It is the only maxima interface supported by sagemath. In mandriva I made it work with all maxima backends, but it may break and go unnoticed for some time due to unrelated updates. I did need to write patches in maxima and sagemath for clisp, and sagemath for gcl. Sbcl and ecl did work, but may have issues if not using the same version as sage, as not the same build options. For clisp, it was required a patch, part of the archives: http://comments.gmane.org/gmane.lisp.clisp.devel/20708 but that also requires a patch in maxima for when using clisp as backend.
Upstream's ChangeLog says this: == [7.2c] (to be released) == * Fix CORD_cat_char_star to prevent SEGV in case of out-of-memory. * Fix GC_FirstDLOpenedLinkMap() for NetBSD 6 release. * Fix GC_scratch_alloc and GC_get_maps invocations to prevent SEGV. * Fix visibility of GC_clear/set_mark_bit (unhide symbols). * Fix visibility of GC_push_all/conditional, GC_push_other_roots symbols. I'm not sure what "(to be released)" means, but if it is possible to incorporate upstream's fix, we can move forward. Paulo, I'm very sorry to have been so slow dealing with your bug reports. I work for a little startup that is about to launch its product, and my free time has shrunk to almost nothing. I'll keep addressing the problems you've encountered as quickly as I can, though. If neither of you has time to fix this, I can probably sneak some time in to fix it tonight.
%changelog * Fri Jun 15 2012 Rex Dieter <rdieter> - 7.2b-2 - backport patches from gc-7_2-hotfix-2 branch in lieu of 7.2c release - gc 7.2 final abi broken when changing several symbols to hidden (#825473) - gc: malloc() and calloc() overflows (CVE-2012-2673, #828881)
fyi, did a build too for f17 testing it out, before issuing any updates. considering doing fc16/f15 too, due to security issue (bug #828881)
Thanks, Rex. I have rebuilt ecl for Rawhide. Could you submit the F17 build of gc as a buildroot override so that I can rebuild ecl there, too? Thanks.
ok, override submitted
(In reply to comment #6) > Upstream's ChangeLog says this: > > == [7.2c] (to be released) == > > * Fix CORD_cat_char_star to prevent SEGV in case of out-of-memory. > * Fix GC_FirstDLOpenedLinkMap() for NetBSD 6 release. > * Fix GC_scratch_alloc and GC_get_maps invocations to prevent SEGV. > * Fix visibility of GC_clear/set_mark_bit (unhide symbols). > * Fix visibility of GC_push_all/conditional, GC_push_other_roots symbols. > > > I'm not sure what "(to be released)" means, but if it is possible to > incorporate upstream's fix, we can move forward. > > Paulo, I'm very sorry to have been so slow dealing with your bug reports. I > work for a little startup that is about to launch its product, and my free > time has shrunk to almost nothing. I'll keep addressing the problems you've > encountered as quickly as I can, though. No problems. Actually, I was very sick, in hospital and in intensive care (for the first time in my life) since 13th up to yesterday, without internet access, etc, catching up now (somewhat slowly) and hoping to not get sick again... > If neither of you has time to fix this, I can probably sneak some time in to > fix it tonight. It appears to work fine now (with gc 7.2c). I am updating my sage 5.0.rc0 to 5.0.1, and soon should update any open bug reports.