Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2008-04

backport 2.3.1 fix to 2.2.x fixes branch?

5 messages · 2 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Seth Grover

(Apology ahead of time if my question is bad etiquette...)

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?

Barring that, does anyone know of a way I can manually make sure the initialization code gets called? Can I directly call "initialize" somehow?

Thanks a lot,

Seth Grover

Good news, everyone! Seth Grover sethdgrover[at]gmail[dot]com http://grovers.us/seth
Jonas Maebe
to Seth Grover
Seth Grover wrote 14 lines
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

Seth Grover
Show quoted text 8 lines
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.

Jonas,

Thank you for your response! I grabbed 2.3.1 from subversion and ran both tests attached to bug 9089. The initialization code in the .so's are indeed being called now. Finalization is not, but I read somewhere else that that is another known issue, and, for me at least, that's not as big a deal.

I would have reported these results in the bug itself, but I can't seem to find a way for mantis to let me comment on them now that it's closed.

My setup is Free Pascal Compiler version 2.3.1 [2008/04/01] for i386, running on Ubuntu Linux 2.6.22-14-generic 7.10 kernel.

Thanks again for your help and for explaining how the merge process works. Hopefully in a while we'll see it merged back!

Cheers,

Seth

Jonas Maebe
to Seth Grover
Seth Grover wrote 14 lines
> 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. > Thank you for your response! I grabbed 2.3.1 from subversion and ran both tests attached to bug 9089. The initialization code in the .so's are indeed being called now. Finalization is not, but I read somewhere else that that is another known issue, and, for me at least, that's not as big a deal.

Actually, finalization should also work in the mean time. But I mainly meant verifying the fix with your own program. The tests themselves are run automatically every night.

I would have reported these results in the bug itself, but I can't seem to find a way for mantis to let me comment on them now that it's closed.

No, that's indeed not possible.

Jonas

Jonas Maebe
to Jonas Maebe
Jonas Maebe wrote
Actually, finalization should also work in the mean time.

I had forgotten to commit one file, causing this not to work yet for FPC-compiled programs (it worked fine when using an FPC-compiled library within a C program). I've committed that file now as well, and also merged everything to 2.2.1.

Jonas