2009/11/29 Basile STARYNKEVITCH <bas...@starynkevitch.net>: > Hello All, > > I believe there are several plugin issues to fix before 4.5 releases: > > 1. use of libiberty from plugins. > > As several patches recently sent demonstrated, the current state of the > trunk does not work with plugins calling some of the libiberty functions is > IMHO not acceptable. > > we could take some of the following solutions > > a) explicitly document in plugins.texi that libiberty is not callable from > plugins (e.g. functions like pex_execute or make_temp_file, which are not > currently linked into cc1). This is the easiest to do. My feeling is that it > would be very unfortunate. Libiberty is documented as a portability layer; > if plugins cannot use it, that means that plugins will never be a way of > experimenting code which might (much latter) be (partly) proposed into the > trunk. So giving up libiberty in plugins is an important social decision; it > discourage people coding plugins to try to propose (much latter, when their > plugin has a big enough audience) their code into the trunk latter.
So, for 4.5 I think that documenting the issue might be the right thing. For 4.6 I am not sure. Do the functions you want to use keep internal state? If they don't, it should be safe to link a static (but PIC) libiberty in the plugin. The objection for a libiberty.so was that we would have to start versioning it and making sure the ABI was stable. Was there something else? If the only objection to using a libiberty.so is the ABI, maybe we could install it in a non standard place and use rpaths. That way gcc 4.4 and 4.5 can use completely different and incompatible versions of libiberty. The plugin would have to make sure that it is linked with the correct one, but that is in line with we not making any promises for backward compatibility. Are rpaths as portable as shared libraries or do we support a host architecture that has shared libraries but no equivalent to rpath? That failing, IMHO, the best proposal is to have the build system do its best at passing --whole-archive or equivalent when linking libiberty in cc1. > > Regards. > > -- > Basile STARYNKEVITCH http://starynkevitch.net/Basile/ > email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 > 8, rue de la Faiencerie, 92340 Bourg La Reine, France > *** opinions {are only mines, sont seulement les miennes} *** > Cheers, -- Rafael Ávila de Espíndola
