Sign in Join

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

Mailing lists / fpc-devel / 2012-05

Build failure on win64

3 messages · 2 people ·

Reply by email Subscribe to this list Your subscription

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

Sergei Gorelkin

Hello,

I've just encountered 'make clean all OPT=-dTEST_WIN64_SEH' in trunk failure:

make ./msg2inc.exe
make[5]: Entering directory `C:/trunk/compiler'
C:/trunk/compiler/ppc3.exe -Ur -Xs -O2 -n -Fux86_64 -Fusystems -FuC:/trunk/rtl/units/x86_64-win64 -Fix86_64 -FE. -FUx86_64/units/x86_64-win64 -dRELEASE -dTEST_WIN64_SEH -dx86_64 -dGDB -dBROWSERLOG -Fux86 -Sew -Owdevirtcalls,optvmts -FwC:/trunk/compiler/pp1.wpo -OWdevirtcalls,optvmts -FWC:/trunk/compiler/pp2.wpo -dx86_64 -dGDB -dBROWSERLOG -Fux86 -Sew -FE. utils/msg2inc.pp msg2inc.pp(823,1) Error: Undefined symbol: SYSUTILS$_$TMULTIREADEXCLUSIVEWRITESYNCHRONIZER_$__$$_DESTROY msg2inc.pp(823,1) Fatal: There were 1 errors compiling module, stopping

While I'm not entirely sure whether this is caused by my local changes, the failed command looks 't it plain wrong to use WPO information from compiler to optimize msg2inc, a completely independent executable?

Regards,
Sergei

Reply by email

Jonas Maebe
to Sergei Gorelkin
Sergei Gorelkin wrote 10 lines
I've just encountered 'make clean all OPT=-dTEST_WIN64_SEH' in trunk failure: make ./msg2inc.exe make[5]: Entering directory `C:/trunk/compiler' C:/trunk/compiler/ppc3.exe -Ur -Xs -O2 -n -Fux86_64 -Fusystems -FuC:/trunk/rtl/units/x86_64-win64 -Fix86_64 -FE. -FUx86_64/units/x86_64-win64 -dRELEASE -dTEST_WIN64_SEH -dx86_64 -dGDB -dBROWSERLOG -Fux86 -Sew -Owdevirtcalls,optvmts -FwC:/trunk/compiler/pp1.wpo -OWdevirtcalls,optvmts -FWC:/trunk/compiler/pp2.wpo -dx86_64 -dGDB -dBROWSERLOG -Fux86 -Sew -FE. utils/msg2inc.pp msg2inc.pp(823,1) Error: Undefined symbol: SYSUTILS$_$TMULTIREADEXCLUSIVEWRITESYNCHRONIZER_$__$$_DESTROY msg2inc.pp(823,1) Fatal: There were 1 errors compiling module, stopping While I'm not entirely sure whether this is caused by my local changes, the failed command looks suspicious at least. Isn't it plain wrong to use WPO information from compiler to optimize msg2inc, a completely independent executable?

It indeed shouldn't be used for that. On the other hand, I don't understand why it would be recompiled during the WPO cycle, since how can the message files have changed since the last compilation of the regular cycle? (msg2inc should only be compiled if the message include files have to be regenerated)

Jonas

Reply by email

Sergei Gorelkin
to Jonas Maebe

17.05.2012 15:44, Jonas Maebe пишет:

Show quoted text 16 lines
On 17 May 2012, at 13:39, Sergei Gorelkin wrote: > I've just encountered 'make clean all OPT=-dTEST_WIN64_SEH' in trunk failure: > > make ./msg2inc.exe > make[5]: Entering directory `C:/trunk/compiler' > C:/trunk/compiler/ppc3.exe -Ur -Xs -O2 -n -Fux86_64 -Fusystems -FuC:/trunk/rtl/units/x86_64-win64 -Fix86_64 -FE. -FUx86_64/units/x86_64-win64 -dRELEASE -dTEST_WIN64_SEH -dx86_64 -dGDB -dBROWSERLOG -Fux86 -Sew -Owdevirtcalls,optvmts -FwC:/trunk/compiler/pp1.wpo -OWdevirtcalls,optvmts -FWC:/trunk/compiler/pp2.wpo -dx86_64 -dGDB -dBROWSERLOG -Fux86 -Sew -FE. utils/msg2inc.pp > msg2inc.pp(823,1) Error: Undefined symbol: SYSUTILS$_$TMULTIREADEXCLUSIVEWRITESYNCHRONIZER_$__$$_DESTROY > msg2inc.pp(823,1) Fatal: There were 1 errors compiling module, stopping > > While I'm not entirely sure whether this is caused by my local changes, the failed command looks suspicious at least. > Isn't it plain wrong to use WPO information from compiler to optimize msg2inc, a completely independent executable? It indeed shouldn't be used for that. On the other hand, I don't understand why it would be recompiled during the WPO cycle, since how can the message files have changed since the last compilation of the regular cycle? (msg2inc should only be compiled if the message include files have to be regenerated)

This turned out to be a bug in 64-bit 'make' program that I was using. For some reason it started thinking that errore.msg is always newer than msgtxt.inc (although it was working fine last 8 months). Using 32-bit make, the trunk builds successfully. This software is truly a never-ending source of surprises...

Regards,
Sergei

Reply by email