<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 23/06/15 23:06, luiz americo pereira
camara wrote:<br>
</div>
<blockquote
cite="mid:CAMa0j614shhWR665d+iuRWa1Wt-0xR+g0j5S2ym4kmX_YEEXUA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>Take a look at <a moz-do-not-send="true"
href="https://msdn.microsoft.com/pl-pl/library/vstudio/7dz62kfh%28v=vs.110%29.aspx">https://msdn.microsoft.com/pl-pl/library/vstudio/7dz62kfh(v=vs.110).aspx</a>
(it suggests a cvtres.exe tool)</div>
<div><br>
</div>
<div>Ask to fpc guru if is possible to use manually an different
linker like <a moz-do-not-send="true"
href="http://www.digitalmars.com/ctg/optlink.html">http://www.digitalmars.com/ctg/optlink.html</a></div>
<div><br>
</div>
In the end, i would try to compile a delphi dll and access it in
fpc.
<div><br>
</div>
<div>Another try (don't know if is possible) is to use delphi to
compile <span style="font-size:12.8000001907349px">spromeps.pas</span> as
a obj in COFF</div>
</div>
</blockquote>
I have discovered potential bugs in the 3rd party tool objconv.exe
that converts from omf to coff, and most importantly in fpc's
internal linker.<br>
<br>
I provided Bo Berglund with a workaround for objconv that seems to
work, and advised him to use the external linker (-Xe switch). The
exception has vanished and basic tests have succeeded. I will file a
bug report against fpc's internal linker soon.<br>
<br>
Stephano<br>
</body>
</html>