[fpc-pascal] backport 2.3.1 fix to 2.2.x fixes branch?
Jonas Maebe
jonas.maebe at elis.ugent.be
Wed Apr 2 10:42:43 CEST 2008
On 02 Apr 2008, at 01:22, Seth Grover wrote:
> I've been tracking an issue for a while:
> http://bugs.freepascal.org/view.php?id=8730
> http://bugs.freepascal.org/view.php?id=9089
> and am delighted to see it's been marked as fixed in 2.3.1.
>
> I grabbed the fixes_2_2 branch in hopes the change had been
> backported, but it doesn't appear the issue is resolved in that
> branch. I'm trying to facilitate a switch from kylix to freepascal in
> my company, and being able to have libraries initialize correctly is
> really important, but I'm reluctant to suggest we use the 2.3.x trunk
> in production.
>
> So my question is, how generally does a fix get backported to the
> fixes branch?
If the fix is not too invasive (i.e., its effects are generally
overseeable), and if it has been in 2.3.1 for a while and no bad
effects are reported, then it will be merged after a while. These
particular fixes will be merged at some time in the future, but I
don't know when yet exactly. If you can test the fixes in trunk and
report whether or not everything indeed works now for you, that would
be very helpful.
> Barring that, does anyone know of a way I can manually make sure the
> initialization code gets called? Can I directly call "initialize"
> somehow?
The problem was not that initialize wasn't called, but that many
symbols in libraries were bound to same-named symbols in the main
program (or in other libraries). There is no quick fix available,
except possibly compiling the libraries with -k-Bsymbolic (although
that breaks if you try to export variables from a library, see http://bugs.freepascal.org/view.php?id=8397)
Jonas
More information about the fpc-pascal
mailing list