On Mon, 23 Aug 2021 23:01:39 +0200, Bart via fpc-devel
wrote:
>On Mon, Aug 23, 2021 at 8:04 PM Bart wrote:
>
>> And, of course, the guide on how to remove this utility
>> (https://www.intel.com/content/www/us/en/support/articles/32459/processors/processor-utilities-and-programs.html)
>> do n
On Wed, Aug 25, 2021 at 11:11 AM Tomas Hajny via fpc-devel
wrote:
>
> > And, being curious: any idea why make clean failed when %PATH% was set
> > to just C:\fpc\3.2.2\bin\i386-win32 ?
>
> No idea - I just tested on a MS Win machine I have access to and 'make
> clean all' succeeded with PATH conta
On 2021-08-24 21:32, Bart via fpc-devel wrote:
On Tue, Aug 24, 2021 at 3:05 PM Sven Barth via fpc-devel
wrote:
Wrong. If it would be a 64-bit DLL in System32 of a x86_64 system then
there would be no problem. However a 64-bit DLL in the SysWOW64
directory
(thus the 32-bit System32 directory)
On Tue, Aug 24, 2021 at 3:05 PM Sven Barth via fpc-devel
wrote:
> Wrong. If it would be a 64-bit DLL in System32 of a x86_64 system then there
> would be no problem. However a 64-bit DLL in the SysWOW64 directory
> (thus the 32-bit System32 directory) *is* a problem. Same for a 32-bit DLL in
>
Bart via fpc-devel schrieb am Di., 24.
Aug. 2021, 06:31:
> On Mon, Aug 23, 2021 at 3:35 PM Yuriy Sydorov via fpc-devel
> wrote:
>
> > Just move common.dll from SysWOW64 to system32. The file is placed
> wrongly
> > by some installer.
>
> If I understand Tomas correctly then that would not make a
Am 23.08.2021 um 19:33 schrieb Bart via fpc-devel:
On Mon, Aug 23, 2021 at 7:16 PM Bart wrote:
I tried to build with only the path to the starting compiler in %PATH%:
PATH /devel/fpc/3.2.2/bin/i386-Win32
make clean
make all OPT=...
That failed on make clean:
That error goes away if I add C:
On Mon, Aug 23, 2021 at 8:04 PM Bart wrote:
> And, of course, the guide on how to remove this utility
> (https://www.intel.com/content/www/us/en/support/articles/32459/processors/processor-utilities-and-programs.html)
> do not apply.
> No XtuService in "Apps and Features", no XtuService.exe.
On Mon, Aug 23, 2021 at 8:15 PM Yuriy Sydorov via fpc-devel
wrote:
> On 64bit Windows system32 contains only 64 bit system files. syswow64
> contains only 32 bit files and is seen as system32 for 32 bit apps. For
> some reason you have the 64 bit dll in the 32 bit syswow64 folder. You need
> to m
On August 23, 2021 19:41:41 Bart via fpc-devel
wrote:
On Mon, Aug 23, 2021 at 3:35 PM Yuriy Sydorov via fpc-devel
wrote:
Just move common.dll from SysWOW64 to system32. The file is placed wrongly
by some installer.
If I understand Tomas correctly then that would not make any
difference: w
On Mon, Aug 23, 2021 at 7:45 PM Bart wrote:
> Productname: Intel(R) Extreme Tuning Utility
And, of course, the guide on how to remove this utility
(https://www.intel.com/content/www/us/en/support/articles/32459/processors/processor-utilities-and-programs.html)
do not apply.
No XtuService in
Looking with Windows Explorer at the Common.dll in question:
Productname: Intel(R) Extreme Tuning Utility
File version 7.3.0.33
Product version 7.3.0.33
Modified: 24-02-2021 (that's dd-mm-)
In the tab "Previos Version" it says: no previous version.
This must have been installed in some Windo
On Mon, Aug 23, 2021 at 7:16 PM Bart wrote:
> I tried to build with only the path to the starting compiler in %PATH%:
>
> PATH /devel/fpc/3.2.2/bin/i386-Win32
> make clean
> make all OPT=...
>
> That failed on make clean:
That error goes away if I add C:\Windows to the path.
However, then I get
On Mon, Aug 23, 2021 at 3:19 PM Bart wrote:
> Should I start the build process with a %PATH% that does NOT have
> C:\Windows\system32 in it?
I tried to build with only the path to the starting compiler in %PATH%:
PATH /devel/fpc/3.2.2/bin/i386-Win32
make clean
make all OPT=...
That failed on
On Mon, Aug 23, 2021 at 3:35 PM Yuriy Sydorov via fpc-devel
wrote:
> Just move common.dll from SysWOW64 to system32. The file is placed wrongly
> by some installer.
If I understand Tomas correctly then that would not make any
difference: wether or not that specific common.dll is in system2 or
sy
On August 23, 2021 16:17:03 Bart via fpc-devel
wrote:
On Mon, Aug 23, 2021 at 2:57 PM Tomas Hajny via fpc-devel
wrote:
The problem is that MS Windows employs a special trickery by which the
path to c:\windows\system32 (almost surely in your PATH) translates to
c:\windows\SysWOW64 _for_32-bi
On Mon, Aug 23, 2021 at 2:57 PM Tomas Hajny via fpc-devel
wrote:
> The problem is that MS Windows employs a special trickery by which the
> path to c:\windows\system32 (almost surely in your PATH) translates to
> c:\windows\SysWOW64 _for_32-bit_binaries_ (only!). So in reality, that
> directory _
On 2021-08-23 14:31, Bart via fpc-devel wrote:
On Mon, Aug 23, 2021 at 1:36 PM Werner Pamler via fpc-devel
wrote:
> Does anybody have a common.dll in \windows\system32 at all?
I don't have it, neither in system32 nor in SysWOW64.
OK.
Just pulled the current revision of fpc-trunk, and did n
On Mon, Aug 23, 2021 at 1:36 PM Werner Pamler via fpc-devel
wrote:
> > Does anybody have a common.dll in \windows\system32 at all?
>
> I don't have it, neither in system32 nor in SysWOW64.
OK.
> Just pulled the current revision of fpc-trunk, and did not observe this
> error (Win 10, fpc3.2.2 32
Am 23.08.2021 um 11:52 schrieb Bart via fpc-devel:
Does anybody have a common.dll in \windows\system32 at all?
I don't have it, neither in system32 nor in SysWOW64.
Just pulled the current revision of fpc-trunk, and did not observe this
error (Win 10, fpc3.2.2 32-bit bootstrap compiler)
__
On Mon, Aug 23, 2021 at 10:49 AM Florian Klämpfl via fpc-devel
wrote:
> Are you sure this common.dll is 32 Bit? C:\Windows\SysWOW64 may contain only
> 32 Bit DLLs.
I have no idea how to test this.
Mind you: a simple test program with {$linklib common} fails for me
for either 32 or 64, wether
> Am 22.08.2021 um 10:20 schrieb Bart via fpc-devel
> :
>
> On Sun, Aug 22, 2021 at 5:40 AM J. Gareth Moreton via fpc-devel
> wrote:
>
>> This is a problem I run into all the time Basically, the DLL is 64-bit
>> and hence is invalid in a 32-bit binary. This can be bypassd by
>> commenting o
Hi,
23.08.2021 0:46, Bart via fpc-devel:
I have now finally resorted to that.
Wrote a simple program to do that for me (no sed on windows).
Just in case:
http://gnuwin32.sourceforge.net/packages/sed.htm
Regards,
Nikolai
Then adjusted my build script to run that program, build fpc, then do
On Sun, Aug 22, 2021 at 5:40 AM J. Gareth Moreton via fpc-devel
wrote:
> This is a problem I run into all the time Basically, the DLL is 64-bit
> and hence is invalid in a 32-bit binary. This can be bypassd by
> commenting out the "{$linklib common}" line in .\oracle\src\oraoci.pp
I have now f
On Sun, Aug 22, 2021 at 10:20 AM Bart wrote:
> So, this baffles me.
As does this:
C:\devel\fpc\trunk\packages\oracle>type README.txt
These units provides interface to Oracle Call Interface.
For the older 'oraoci' unit to compile you need oracle
server installed, these units was tested and perf
On Sun, Aug 22, 2021 at 1:51 PM wkitty42--- via fpc-devel
wrote:
> if that Common.dll file is only valid for 64bit windows builds, perhaps the
> better thing to do is to wrap the $linklib line in a check to see if you are
> building 64bit... if 64bit then loadlib otherwise, noop... seems logical
On 8/22/21 1:56 AM, J. Gareth Moreton via fpc-devel wrote:
It might be to do with the order that directories are searched. If it finds the
64-bit version
ghost, then it will throw an error. I've requested to change the error to a
warning instead in the
post, but was shot down.
if that Common.
It might be to do with the order that directories are searched. If it finds the
64-bit version
ghost, then it will throw an error. I've requested to change the error to a
warning instead in the
post, but was shot down.
Gareth aka. Kit
On Sun 22/08/21 09:20 , "Bart via fpc-devel" fpc-devel@lis
On Sun, Aug 22, 2021 at 5:40 AM J. Gareth Moreton via fpc-devel
wrote:
> This is a problem I run into all the time Basically, the DLL is 64-bit
> and hence is invalid in a 32-bit binary. This can be bypassd by
> commenting out the "{$linklib common}" line in .\oracle\src\oraoci.pp
Tha cannot b
This is a problem I run into all the time Basically, the DLL is 64-bit
and hence is invalid in a 32-bit binary. This can be bypassd by
commenting out the "{$linklib common}" line in .\oracle\src\oraoci.pp
Gareth aka. Kit
On 21/08/2021 22:35, Bart via fpc-devel wrote:
Hi,
C:\devel\fpc\trun
Hi,
C:\devel\fpc\trunk>git log -1
commit a77f5221f341b32bb964c03dc61c1e80b71714dd (HEAD -> main,
origin/main, origin/HEAD)
Author: florian
Date: Sat Aug 21 20:36:29 2021 +0200
C:\devel\fpc\trunk>make clean
C:\devel\fpc\trunk>make all
...
[ 19%] Compiled package odbc
Start compiling packag
On 27.11.2011 18:48, Sergei Gorelkin wrote:
27.11.2011 19:10, Sven Barth пишет:
On 27.11.2011 16:45, Sergei Gorelkin wrote:
The fact it works with DISABLE_TLS_DIRECTORY and fails otherwise
suggests that the foreign thread raises exceptions and FPC tries to
handle them. Error 255 is most likely
27.11.2011 19:10, Sven Barth пишет:
On 27.11.2011 16:45, Sergei Gorelkin wrote:
The fact it works with DISABLE_TLS_DIRECTORY and fails otherwise
suggests that the foreign thread raises exceptions and FPC tries to
handle them. Error 255 is most likely caused by Halt(255) in
rtl/inc/except.inc lin
- Original Message -
> From: Sven Barth
> To: fpc-devel@lists.freepascal.org
> Cc:
> Sent: Sunday, November 27, 2011 1:10 PM
> Subject: Re: [fpc-devel] Building trunk on Win32
>
> On 27.11.2011 16:45, Sergei Gorelkin wrote:
>> The fact it works with DISA
On 27.11.2011 16:45, Sergei Gorelkin wrote:
The fact it works with DISABLE_TLS_DIRECTORY and fails otherwise
suggests that the foreign thread raises exceptions and FPC tries to
handle them. Error 255 is most likely caused by Halt(255) in
rtl/inc/except.inc line 200 or 303, these are the only plac
27.11.2011 16:45, Leonardo M. Ramé пишет:
Well, I found I had an e:\pp directory containing an fpc 2.5.1, and my PATH was
pointing to it, so my previous tests could have been influenced by some files
from that directory.
After deleting it, I compiled from top level directory using:
e:\fpc-bi
- Original Message -
> From: Sergei Gorelkin
> To: fpc-devel@lists.freepascal.org
> Cc:
> Sent: Sunday, November 27, 2011 9:07 AM
> Subject: Re: [fpc-devel] Building trunk on Win32
>
> 27.11.2011 13:26, Jonas Maebe пишет:
>>
>> On 27 Nov 2011
27.11.2011 13:26, Jonas Maebe пишет:
On 27 Nov 2011, at 12:19, Sergei Gorelkin wrote:
27.11.2011 13:09, Jonas Maebe пишет:
I regularly use OPT at the top level myself and I've never seen it being
ignored in that situation.
Earlier in this thread Leonardo wrote:
Sven, I added OPT="-gl" b
On 27 Nov 2011, at 12:19, Sergei Gorelkin wrote:
> 27.11.2011 13:09, Jonas Maebe пишет:
>>
>> I regularly use OPT at the top level myself and I've never seen it being
>> ignored in that situation.
>>
> Earlier in this thread Leonardo wrote:
>
> >> Sven, I added OPT="-gl" but I got exactly the
27.11.2011 13:09, Jonas Maebe пишет:
On 27 Nov 2011, at 12:05, Sergei Gorelkin wrote:
But don't execute 'make clean all OPT=-dDISABLE_TLS_DIRECTORY' at the top-level
directory, as in this case OPT is apparently ignored.
I regularly use OPT at the top level myself and I've never seen it bein
On 27 Nov 2011, at 12:05, Sergei Gorelkin wrote:
> But don't execute 'make clean all OPT=-dDISABLE_TLS_DIRECTORY' at the
> top-level directory, as in this case OPT is apparently ignored.
I regularly use OPT at the top level myself and I've never seen it being
ignored in that situation.
Jonas
27.11.2011 0:41, Leonardo M. Ramé пишет:
This is the output I get after update:
...
Well, now ppc2.exe at least starts.
Can you further try to build with OPT=-dDISABLE_TLS_DIRECTORY ?
But don't execute 'make clean all OPT=-dDISABLE_TLS_DIRECTORY' at the top-level directory, as in
this case OP
From: Sergei Gorelkin
>To: fpc-devel@lists.freepascal.org
>Sent: Saturday, November 26, 2011 6:55 PM
>Subject: Re: [fpc-devel] Building trunk on Win32
>
>26.11.2011 23:10, Leonardo M. Ramé пишет:
>
>> This machine is running Win2003 32bits as Guest on VirtualBox 4.1.2 on
26.11.2011 23:10, Leonardo M. Ramé пишет:
This machine is running Win2003 32bits as Guest on VirtualBox 4.1.2 on Ubuntu
11.10 x86_64. On Windows it is not running any antivirus and I enabled only the
default services, disabled firewall/updates/antivirus/etc.
I did a test with processexplorer
- Original Message -
> From: Sven Barth
> To: fpc-devel@lists.freepascal.org
> Cc:
> Sent: Saturday, November 26, 2011 3:40 PM
> Subject: Re: [fpc-devel] Building trunk on Win32
>
> On 26.11.2011 19:50, Sergei Gorelkin wrote:
>> 26.11.2011 17
26.11.2011 21:40, Sven Barth пишет:
On 26.11.2011 19:50, Sergei Gorelkin wrote:
26.11.2011 17:18, Leonardo M. Ramé пишет:
$0040C776 is systhrd.inc line 125 "if TLSKey=$ then RunError(226)
$0040FB59 is syswin.inc line 356, DLL_THREAD_ATTACH branch of
exec_tls_callback
This is TLS callb
On 26.11.2011 19:50, Sergei Gorelkin wrote:
26.11.2011 17:18, Leonardo M. Ramé пишет:
Runtime error 226 at $0040C776
$0040C776
$0040FB59
$7C81A1C2
$7C845A7C
$7C83FE59
$7C82EB2F
$7C828355
$0040C776 is systhrd.inc line 125 "if TLSKey=$ then RunError(226)
$0040FB59 is syswin.inc line 3
26.11.2011 17:18, Leonardo M. Ramé пишет:
Runtime error 226 at $0040C776
$0040C776
$0040FB59
$7C81A1C2
$7C845A7C
$7C83FE59
$7C82EB2F
$7C828355
$0040C776 is systhrd.inc line 125"if TLSKey=$ then RunError(226)
$0040FB59 is syswin.inc line 356,
- Original Message -
> From: Sven Barth
> To: fpc-devel@lists.freepascal.org
> Cc:
> Sent: Saturday, November 26, 2011 11:07 AM
> Subject: Re: [fpc-devel] Building trunk on Win32
>
> On 26.11.2011 14:50, Leonardo M. Ramé wrote:
>> ...
>> make[4]: En
On 26.11.2011 14:50, Leonardo M. Ramé wrote:
...
make[4]: Entering directory `E:/fpc/compiler'
e:/fpc-bin/bin/i386-win32/make rtlclean rtl
make[5]: Entering directory `E:/fpc/compiler'
e:/fpc-bin/bin/i386-win32/make -C E:/fpc/rtl clean
make[6]: Entering directory `E:/fpc/rtl'
e:/FPC-bin/bin/i386-
- Original Message -
> From: Leonardo M. Ramé
> To: FPC developers' list
> Cc:
> Sent: Saturday, November 26, 2011 10:17 AM
> Subject: Re: [fpc-devel] Building trunk on Win32
>
>>
>
>> From: Pierre Free Pa
On 26.11.2011 14:17, Leonardo M. Ramé wrote:
Hi Pierre, I uninstalled my 2.4.4 release then downloaded it again from the fpc site, and
installed, to be sure I'm using the release version. Then, went to my fpc-svn trunk directory, then
"cd compiler" and did a "e:\fpc-bin\bin\i386-win32\make clea
>
> From: Pierre Free Pascal
>To: 'Leonardo M. Ramé' ; 'FPC developers' list'
>
>Sent: Friday, November 25, 2011 6:40 PM
>Subject: RE: [fpc-devel] Building trunk on Win32
>
>
>I tired to reproduce your probl
you test by only doing a make cycle at compiler level?
Pierre Muller
De : fpc-devel-boun...@lists.freepascal.org
[mailto:fpc-devel-boun...@lists.freepascal.org] De la part de Leonardo M.
Ramé
Envoyé : vendredi 25 novembre 2011 22:01
À : FPC developers' list
Objet : [fpc-devel] Building
Hi, I'm trying to build the latest svn trunk on a Win32 machine.
e:\FPC-bin\bin\i386-win32\make.exe PP=e:\fpc-bin\bin\i386-win32\ppc386.exe all
Where e:\fpc-bin\bin\i386-win32\ppc386.exe is this revision:
E:\fpc>e:\fpc-bin\bin\i386-win32\ppc386.exeFree Pascal Compiler version 2.4.4
[2011/04/23
Hi!
Now, before I start fixing this on my own, I wanted to ask whether
somebody knows what's going wrong?
In case someone is interested: it compiles fine with the flag -OoNOCSE
(disabling of cs_opt_nodecse) set. Seems the common subexpression
elimination pass is the culprit?!
Cheers,
Will
Hi!
I tried to do a bootstrap of the compiler on my Windows 7 64bit machine
today (svn version 16015). Using the 2.4.0 win64 cross compiler from the
homepage, I got a basic build. The problems, however, start when I want
to include debug information ("-gl") as this seems to trigger an
intern
56 matches
Mail list logo
