[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