Forum > Beginners

Command line compilation to windows 64 bit target

<< < (2/3) > >>

DenReq:
Thank you very much again.

Unfortunately the compilation fails in rtl\win64, with this message:

Makefile:216: *** The Makefile doesn't support target i386-win64, please run fpcmake first.  Stop.

It's quite complicated to understand for a novice how to fix this problem... I've tried to do different things by digging in the docs, but without success so far.

Maybe I should give up rebuilding the units? Actually I only need to be able to set a low level callback when an exception is raised, so I can log all exceptions. If this is possible without rebuilding system and sysutils, it would certainly be much easier for me. But I haven't seen how I could do that yet.

marcov:

--- Quote from: DenReq on May 16, 2022, 04:27:50 pm ---Thank you very much again.

Unfortunately the compilation fails in rtl\win64, with this message:

Makefile:216: *** The Makefile doesn't support target i386-win64, please run fpcmake first.  Stop.

--- End quote ---

Somehow the CPU_TARGET bit hasn't been passed. Please post your exact commandline and the info of "make info"


--- Quote ---It's quite complicated to understand for a novice how to fix this problem... I've tried to do different things by digging in the docs, but without success so far.

--- End quote ---

Most novices use the prebuild versions, specially on Windows. One of the problems with own build on Windows is other copies (in the %path%) of certain core binaries.


--- Quote ---Maybe I should give up rebuilding the units? Actually I only need to be able to set a low level callback when an exception is raised, so I can log all exceptions. If this is possible without rebuilding system and sysutils, it would certainly be much easier for me. But I haven't seen how I could do that yet.

--- End quote ---

Exceptions are usually not logged on pointer of creation. Doing so might slow down your program, as e.g. EConvertError might be called a lot during running, but is usually locally handled.

Exceptions are usually logged when it bubbles up to the toplevel core loop, and using Application.onexception is fine for e.g. the main thread. Or a simple top level try.. except  frame if you are a console application.

DenReq:
Thank you Marcov.

I've made some progress and can now compile what I need, after understanding better how to use fpcmake.

For the logs, I plan to use a system allowing to manage the recording in an asynchronous way, that I had developed with an old version of FPC (in 2005).

Otherwise I have a problem that looks like a bug. If two divisions by 0 occur consecutively in a thread, only the 1st one generates an exception, the next one returns in the result +Inf. I see this in a test DLL that I compile with FPC, without any particular code. The problem disappears if I comment out the loading of the MXCSR register in SysResetFPU (file x86_64.inc).


--- Code: Pascal  [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---{$define FPC_SYSTEM_HAS_SYSRESETFPU}Procedure SysResetFPU;  var    { these locals are so we don't have to hack pic code in the assembler }    localmxcsr: dword;    localfpucw: word;  begin    localfpucw:=Default8087CW;    localmxcsr:=DefaultMXCSR;    asm      fninit      fwait      fldcw   localfpucw      //ldmxcsr localmxcsr    end;  end; 
I'm not sure what to think about this problem, can disabling the reloading of the register cause other problems? I don't plan to use the SSE instructions in my program.

PascalDragon:
Hmm, it seems that for some reason the FPU exception mask is not initialized correctly for a new thread (at least on i386-win32 and x86_64-win64). I'll have to check that.

Using Math.SetExceptionMask you can control per thread whether floating point exceptions are supposed to happen or not (this will then also be used for the next SysResetFPU). Modifying SysResetFPU should not be necessary.


--- Quote from: DenReq on May 17, 2022, 11:56:05 am ---I don't plan to use the SSE instructions in my program.

--- End quote ---

But you're using floating point types and thus - at least on x86_64-win64 - you're implicitly using SSE.

Edit: SetExceptionMask is not per thread.

DenReq:
Thank you, I think I understand where the problem can come from.

In my case, the threads are created in the host application (not FPC) and call functions located in a DLL compiled with FPC. So the thread-specific FPU initialization code is not called, so it seems logical.

I'll probably have to take some of the thread initialization code and call it at the beginning of these functions...

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version