Re: [fpc-devel] Request for an interim release of the 3.0 branch
On 4/28/2017 10:16 PM, Florian Klämpfl wrote: Am 28.04.2017 um 16:05 schrieb Marco van de Voort: In our previous episode, Benito van der Zander said: r35545, too ? (http://bugs.freepascal.org/view.php?id=31135) I need some report on the safety of merging from a compiler dev for that, I don't merge compiler revs on my own It is invasive, but so far arm builds look good to me. If you merge r35545, you need also merge r35552 - it is a post-fix for r35545. Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Staticaly link C/C++ library (.lib) into FreePascal on Windows
On 3/16/2017 1:12 PM, LacaK wrote: Then I get: test_IPP.lpr(17,1) Error: undefined reference to `ippGetLibVersion' (I have tried also: _ippGetLibVersion, _ippGetLibVersion@0 ...) I've downloaded the IPP libs and did some tests to make sure that static linking is possible. Thank you very much for your effort! You use cdecl, but in header files is stated stdcall for Windows, isn't it problem ? You are right. The headers use stdcall. You need also use stdcall and add "_" before names - use the same names as reported by objdump. function ippGetLibVersion: PIppLibraryVersion; stdcall; external name '_ippGetLibVersion@0'; Besides that it does not work for me, when I add another two functions. Attached my example. I get error: .\Intel_IPP\\ippcoremt.lib(C:/commander/production/ipp201702gold/windows_ia32/.build/windows/obj/ia32/core/s/st/owncpufeatures.obj):(.text[_ownGetMaskFeatures]+0x35): undefined reference to `__security_cookie' Looks like you need to include the bufferoverflow.lib See here: http://stackoverflow.com/questions/21627607/gcc-linker-error-undefined-reference-to-security-cookie Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Staticaly link C/C++ library (.lib) into FreePascal on Windows
On 3/16/2017 12:01 PM, LacaK wrote:
Then I get:
test_IPP.lpr(17,1) Error: undefined reference to `ippGetLibVersion'
(I have tried also: _ippGetLibVersion, _ippGetLibVersion@0 ...)
I've downloaded the IPP libs and did some tests to make sure that static
linking is possible.
The working declaration is:
{$L ippcoremt.lib}
function ippGetLibVersion: PIppLibraryVersion; cdecl; external name
'ippGetLibVersion@0';
You need to use the external linker via the -Xe option, since internal
linker does not support static libraries. Only single object files can
be linked.
ippGetLibVersion@0 - is the C++ mangled name used by MS VC++. FPC
supports then "cppdecl" calling convention, but only for the GCC
compiler, which uses different name mangling algorithm. So you need to
use cdecl and manually specify the name. Function names can be found
using "objdump -t ippcoremt.lib". You should specify the name without
the "_" prefix. It is added automatically when cdecl is used.
Yury.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Staticaly link C/C++ library (.lib) into FreePascal on Windows
On 3/15/2017 6:06 PM, LacaK wrote: >> >> >> Yes, you can statically link a COFF library created by other compiler. >> >> Use objdump as explained earlier to find out the name of ippiThreshold function in the static library. It may be prefixed with "_". > > But does it works also on Windows ? (as far as I does not have "objdump" utility there?) > L. objdump is distributed as part of a FPC or Lazarus release. Thank you! Now I can use "objdump -t ippcore.lib" and I get something like this: ippcore.dll: file format pei-i386 SYMBOL TABLE: [ 0](sec 0)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x .idata$4 ippcore.lib is just an import library for ippcore.dll. You should not use it for static linking. According to the Intel's site you should use the following libs for static linking: ippimt.lib ippsmt.lib ippcorelmt.lib Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Staticaly link C/C++ library (.lib) into FreePascal on Windows
On 3/14/2017 4:47 PM, Ladislav Karrach wrote: Did you try this: function ippiThreshold(pSrcDst: PIpp8u; srcDstStep: int; roiSize: IppiSize; thresholdLT: Ipp8u; valueLT: Ipp8u; thresholdGT: Ipp8u; valueGT: Ipp8u): IppStatus; external 'ippi.dll' name 'ippiThreshold_LTValGTVal_8u_C1IR'; You should use objdump -p ippi.dll to get the names of the exported procedures/functions. Yes I know, this work: external 'ippi.dll' (I have added also "stdcall") But my question was regarding how to staticaly link provided libraries into my EXE (so I do not want distribute also all DLLs) Just like one can do it in C/C++ Yes, you can statically link a COFF library created by other compiler. Use objdump as explained earlier to find out the name of ippiThreshold function in the static library. It may be prefixed with "_". Then insert the proper name in the external declaration: function ippiThreshold(pSrcDst: PIpp8u; srcDstStep: int; roiSize: IppiSize; thresholdLT: Ipp8u; valueLT: Ipp8u; thresholdGT: Ipp8u; valueGT: Ipp8u): IppStatus; external name ''; Also specify proper calling convention: cdecl or stdcall. But it does not affect linking if name is explicitly specified. Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] aarch64-android target support
Hi, As the primary android target maintainer, I can review the patches and apply them if all is ok. But it will be better if the original author create a bug ticket and post the patches there. It will be possible to discuss any issues in the bug tracker. Yury Sidorov. On 1/24/2017 11:12 AM, Alfred wrote: Good news ! I got in contact with Artur directly. He will update me with aarch64 patches shortly (if and when his time permits: couple of days) ! -- Origineel bericht -- Van: "Florian Klämpfl" <flor...@freepascal.org> Aan: "Alfred" <alf...@consulab.nl>; "FPC developers' list" <fpc-devel@lists.freepascal.org> Verzonden: 22-1-2017 21:21:43 Onderwerp: Re: [fpc-devel] aarch64-android target support So far I am not aware of any patch regarding this. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] About building JNI library for arm-linux
On 11/1/2016 3:42 AM, Gennady Agranov wrote: Why do you use LCL in your JNI library? Try a simple library without LCL and check if it loads. It works! Great Thanks! Does anyone know what to do about: Java HotSpot(TM) Client VM warning: You have loaded library /media/pi/Transcend/cypress-release/pas2jni_policing64/policing64/policing.so which might have disabled stack guard. The VM will try to fix the stack guard now. It's highly recommended that you fix the library with 'execstack -c ', or link it with '-z noexecstack'. Should I run execstack? Should I run every time I build a shared object - or there is a better way? Just pass this option the linker using the following FPC switch: -k"-z noexecstack" Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] About building JNI library for arm-linux
On 10/31/2016 10:01 PM, Gennady Agranov wrote:
I have an issue with loading JNI library for Raspberry :(
I do compile with -Cg -WX and stack checking on (and also without).
But even this method is not called :(
function JNI_OnLoad(vm: PJavaVM; reserved: pointer): jint; {$ifdef
linux}cdecl{$else}stdcall{$endif};
begin
writeln('lll');
exit(0);
end;
Any suggestions?
Thanks,
Gennady
Java HotSpot(TM) Client VM warning: You have loaded library
/media/pi/Transcend/cypress-release/pas2jni_policing64/policing64/policing.so
which might have disabled stack guard. The VM will try to fix the stack
guard now.
It's highly recommended that you fix the library with 'execstack -c
', or link it with '-z noexecstack'.
[FORMS.PP] ExceptionOccurred
Why do you use LCL in your JNI library?
Try a simple library without LCL and check if it loads.
Also do not add any extra compiler switches.
In FPC 3.0 -Cg is broken for ARM.
Yury.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] aarch64-andriod target support
Hello, Please provide your patches and I'll review them and apply. Thanks. Yury Sidorov. On 8/29/2016 10:21 AM, Artur Huhtaniemi wrote: Hi! I have written missing rtl initialization part for aarch64-android target with all the necessary modifications in the compiler sources. This was necessary as our code is written in cross-platform manner and we targeting android as our primary platform. I wish to submit the path to fpc repository, so we don't need to maintain it ourselves, and it might benefit others too. How could I accomplish this? (any interest in this topic whatsoever?) Artur. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Bug 29760 on FPC 3.0 Win64
On 3/10/2016 1:06 PM, Jy V wrote: This happens only on Win64 with FPC 3.0 Can somebody please check and confirm ? compiled with official Lazarus 1.6 (SVN revision as displayed in the about box: 51630) console output of your program is: 1.234500E+02* 1.E+002= 1.234500E+08 I've tested FPC trunk on win64 and it works correctly. 1.234500E+02* 1.E+002= 1.234500E+04 Looks like my fix in r32054 also applies for this case. The bug affected all targets where currency is 64-bit integer. Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Bug 29760 on FPC 3.0 Win64
On 3/10/2016 11:33 AM, Michael Van Canneyt wrote: On Thu, 10 Mar 2016, LacaK wrote: Hi, investigating bug #29760 I reduced bug to: var c: currency; d: double; begin c := 123.45; d := 100; writeln(c, '*', d, '=', c*d); // result of multiply is wrong = 12345 end. This happens only on Win64 with FPC 3.0 Can somebody please check and confirm ? If confirmed, then I think this is enough reason to start a 3.0.2 release :/ I've fixed similar issue for ARM several months ago. http://bugs.freepascal.org/view.php?id=28748 But the bug possibly had affected all 64-bit integer currency targets. Does the bug exist in trunk? Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Exception problems in FPC 3.0.0
On 10/29/2015 1:22 PM, Sergio Flores wrote: I've never experienced such issues. You should try to use different NDK versions. I use ndk-r8d. It is stable. I got the latest ndk download, it works fine, most of my problems were derived from using Mingw, switching to Cygwin solved the issues. Actually there is no need to use mingw or cygwin at all. All needed build tools are bundled with win32 fpc release. No extra tools are needed to build FPC from sources. Do you use static .a libs? I generate a .a lib that contains all pascal code, which is then loaded by java "dynamically" at the app startup. I'm not sure if there's other alternative approaches that allow mixing Java and Pascal in Android (I know how it possible to create a pure NDK app in Pascal, however lots of Java SDKs that I use that don't play well with that). You build a dynamic .so library not a static .a library. You can not load a static library from Java. The issue seems to be specific for your environment only. If you not try to find out the reason, it will never be fixed. Sure, I'll try again if I find some precompiled release with hard float support so I can understand better where the problem is. As for now, I'll keep using the old compiler, as it works fine and I don't need the new features that were introduced in 3.0. I've performed more tests and found out that arm hard float exceptions are not handled at all in Android. It seems there is no need to mask them. Looks like you have some installation issue. You can try to install FPC 3.0 on some clear system and build your library. Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Exception problems in FPC 3.0.0
On 10/28/2015 3:07 PM, Sergio Flores wrote: Building a cross compiler is a trivial task even on Windows. Read here ho to do that:http://wiki.freepascal.org/Android I know how to build a crosscompiler, the problem is that doing it in Windows you sometimes get very weird errors (like the building process stopping with error message saying CreateProcess(null) failed without any other explanation) or the NDK linker just hangs. I've never experienced such issues. You should try to use different NDK versions. I use ndk-r8d. It is stable. Nevertheless I was now able to build FPC crosscompiler from the latest sources it with hard float support. And now the compiled app crashes at startup with linking errors, saying it cant find my own functions in the library. It's very weird. After investigating it, during the compilation some perfectly innocent functions are reporting invalid instructions (I dont have the log here, but it was instructions that started with Vsomething, if thats a clue). However a .a lib is still generated and the compilation ends with 'sucess'... Do you use static .a libs? For the time I've returned to use the old crosscompiler I compiled myself with hard float support around 1 year ago, which works fine, with that I can run the app without any crashes. The issue seems to be specific for your environment only. If you not try to find out the reason, it will never be fixed. I've read the link about the crosscompiler, I'm using the same compiler switches etc, all seems correct. Maybe something in the ARM7 code generation got broken in the last months? The 3.0 branch was created in January. Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Exception problems in FPC 3.0.0
On 10/27/2015 4:29 PM, Sergio Flores wrote: Yury, I think you're right, I'm using the precompiled binary that indeed seems to been compiled in soft-fpu mode, so that would explain everything, as OpenGL is probably triggering hard fpu exceptions that are not being caught. I tried your asm function, however adding it makes the app crash at startup. I added it to initialization of my OpenGLES unit, Seems that just having the function laying around, even without calling it, causes the crash. Checking the android log, it says the following: E/AndroidRuntime(10684): java.lang.UnsatisfiedLinkError: dlopen failed: cannot locate symbol "TERRA_OPENGLES_$$_LOADOPENGL" referenced by "libterra.so"... LoadOpenGL() is the only pascal function that is contained in this unit (it just loads the opengles library dynamically and assigns function pointers). For some reason, adding the assembler function to this unit makes this function disappear, what causes this very weird behaviour? Full unit code here: http://pastebin.com/h2gCcikd Commenting both the function and the function call makes the game startup again without crashing (albeit still crashes whevener a float exception happens) I've provided wrong code. Try this one: procedure VFP_MaskExceptions; assembler; nostackframe; asm .long 0xeef10a10// fmrx r0,fpscr bic r0,r0,#0x1F00 .long 0xeee10a10// fmxr fpscr,r0 end; Probably recompiling FPC with hard float support would be the best solution, however compiling FPC in Windows is a frustrating game of trial and errors. I had written a .bat file that I used with 2.6.2, but it no longer works in 3.0.0. Once I have some free time I guess I will have to try discovering whats problem. Or if anyone has 3.0.1 compiled with hard-floats and can provide a download link, i would be thankful. Building a cross compiler is a trivial task even on Windows. Read here ho to do that: http://wiki.freepascal.org/Android Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Exception problems in FPC 3.0.0
On 10/26/2015 9:38 PM, Sergio Flores wrote: Hi guys, congrats for the 3.0 release! However after upgrading FPC, my Android game now crashes with division by zero exceptions (it happens always in the same place). I changed nothing in the code, only the compiler changed from a 2.7.x to 3.0.0 (cross compiler windows to Arm binary version obtained from the link that was distributed in the mailing list last week). If I revert to using the old compiler, no exceptions happen. Note that I have this line in one of my units: Initialization SetExceptionMask([exInvalidOp, exDenormalized, exZeroDivide, exOverflow, exUnderflow, exPrecision]); End. I masking all of those stuff because it is a requisite for OpenGL graphics. Looking at the breaking changes section of the wiki, I dont see anything related. Anyone has an idea of what changed that could cause this or at least how I can debug it? I suppose your issue is caused by the following: The 3.0 release arm-android cross compiler is bundled with units compiled with the soft float FPU emulation. In such case SetExceptionMask() masks only softfloat exceptions. And if the OpenGL library uses true FPU code, its exceptions are not masked. You can: - build FPC units from sources with FPU support. or - use the following code to mask FPU exceptions: procedure VFP_SetCW(cw : dword); nostackframe; assembler; asm fmxr fpscr,r0 end; ... VFP_SetCW($1F00); // Mask all FPU exceptions ... Yury Sidorov. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Win CE CreateFile
On 10/19/2015 4:20 PM, Carsten Bager wrote: The function system.CreateFile sometimes return a negative value (LongInt) under Win CE when used together with COM ports. When I typecast to LongWord everything works. Is it ment to be that way. Of course a negative value of type LongInt becomes positive value when type casted to LongWord. You need to inspect GetLastError to find out why CreateFile fails. Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] re : FPC app crash with "has text relocations" / android 6.0
Hello, It seems Android 6.0 forces usage of PIC-enabled shared libraries only. Currently the Android FPC target is not PIC compatible, since the startup assembler code is needed to be converted to PIC. You need to use targetSdkVersion <= 22 until PIC is fixed for the Android target. Yury Sidorov. On 9/9/2015 10:43 PM, Dmitry Boyarintsev wrote: On Wed, Sep 9, 2015 at 3:40 PM, Maciej Izak <hnb.c...@gmail.com <mailto:hnb.c...@gmail.com>> wrote: still unreadable ... :( needs to be replaced with the space, obviously 2015-09-09 18:35 GMT+02:00 크레딕스 최원식 <simons...@naver.com <mailto:simons...@naver.com>>: Oh Sorry More Testing - Test Env. FPC 3.1.1 (svn 31577) Case 1. Java Loading Shared Lib (JNI) until targetSdkVersion = 22 -> OK, when targetSdkVersion = 23 -> Crash Case 2. Java Loading C Shared Obj (JNI) and C Shared Lib loading Pascal Lib by dlOpen 2.1 targetSdkVersion <= 22 All Works 2.2. targetSDKVersion = 23 - Java Load C Library - C Library Loading Pascal Library ( dlOpen / Fail ) - Other Helpful Link http://slowbutdeadly.blogspot.kr/2015/09/javalangunsatisfiedlinkerror-dlopen.html - In My Result Android 6.0 can't loading so file when so file has text relocations // Dynamic section at offset 0x42f424 contains 32 entries: // TagTypeName/Value // 0x0016 (TEXTREL) 0x0// If TEXTREL exists then Crash ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC Android crashes in Tegra CPUs
Hi, To find out an offending instruction it is needed to create a simple console app. Compile it with the -gl switch and run in the Android console. You will get a stack back trace. If the instruction in the RTL, it is needed to recompile it with the -O- -g switches. Yury Sidorov, j...@cp-lab.com On 12/25/2014 2:06 AM, peter green wrote: Sergio Flores wrote: Eg: Calling lnxp1(x) with x1 results in a SIGILL crash. . I've got an Android app in Play Store with around 300 thousand downloads, and from what I've gathered, this crash happens in any Tegra based device, and only on those. AIUI many tegra devices don't support neon, I wonder if a neon instruction is being used either because of incorrect compiler settings or because of incorrect inline assembler code. If this was happening on regular linux i'd suggest using gdb to get a backtrace and a dissasembly of the sigill location but i'm not sure how possible that is on andriod or how easy it is to get a suitable tegra device running regular linux to experiment on. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC and Windows Phone 8
On 24.03.2014 21:36, Vsevolod Alekseyev wrote: Thanks. But the Android build is acting funny now, and I'm not sure why. make clean all OS_TARGET=android CROSSOPT=-CpARMv7A -CfVFPV3_D16 -CIthumb CPU_TARGET=arm INSTALL_PREFIX=C:\FPC\2.7.1 ... D:\android-ndk-r9d\toolchains\arm-linux-androideabi-4.8\prebuilt\windows-x86_64\ bin\arm-linux-androideabi-ld.bfd.exe: cannot find crtbegin_dynamic.o D:\android-ndk-r9d\toolchains\arm-linux-androideabi-4.8\prebuilt\windows-x86_64\ bin\arm-linux-androideabi-ld.bfd.exe: cannot find -lc pp.pas(238,36) Error: Error while linking pp.pas(238,36) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted Use make clean crossall ... In such case the native fpc binaries will not be built. Only cross compiler and cross units will be built. See: http://wiki.freepascal.org/Android Yury Sidorov, j...@cp-lab.com ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Problem with fpcmake when doing crossbuild
Fixed in r24626. Your guesswork is right :) Yury. - Original Message - From: Michael Ring To: fpc-devel@lists.freepascal.org Sent: Tuesday, May 28, 2013 1:24 PM Subject: Re: [fpc-devel] Problem with fpcmake when doing crossbuild In case my guesswork was right this would be the fix to Makefile.fpc: Index: Makefile.fpc === --- Makefile.fpc(revision 24625) +++ Makefile.fpc(working copy) @@ -169,8 +169,12 @@ # Always use newly created fpcmake ifndef FPCMAKENEW +ifdef CROSSINSTALL +FPCMAKENEW=$(BASEDIR)/utils/fpcm/fpcmake$(SRCEXEEXT) +else FPCMAKENEW=$(BASEDIR)/utils/fpcm/bin/$(SOURCESUFFIX)/fpcmake$(SRCEXEEXT) endif+endif # Build/install options CLEANOPTS=FPC=$(PPNEW)@@ -316,6 +320,11 @@ base.$(BUILDSTAMP): # create new compiler $(MAKE) compiler_cycle RELEASE=1+ifdef CROSSCOMPILE+# Buld a new native fpcmake when cross-compiling.+# Fresh native compiler and RTL are ready at this stage.+$(MAKE) -C utils/fpcm bootstrap $(BUILDOPTS)+endif # clean $(MAKE) rtl_clean $(CLEANOPTS) # build everythingAm 28.05.13 10:59, schrieb Michael Ring:I was having troubles today installing ppcrossarm from trunk, I have aworkarround for the problem but I question myself how to really fixthe problem:SUBARCH=armv7mmake clean buildbase CROSSINSTALL=1 OS_TARGET=embedded CPU_TARGET=armSUBARCH=$SUBARCH CROSSOPT=-godwarfsets -gw2 -O-BINUTILSPREFIX=arm-none-eabi-works fine. But then installation goes wrong because fpcmake was notbuild, but it is needed for installation (Question is why it isnecessary to invoke fpcmake at all;-)).I can fix this by adding:make -C utils/fpcm bootstrap 'FPC=/Users/ring/devel/fpc/compiler/ppc'OS_TARGET=darwin CPU_TARGET=i386to my buildscript, but my guess is that this should better be added tothe buildbase rule, there's an entry for that in the build ruleifdef CROSSCOMPILE$(MAKE) -C utils/fpcm bootstrap $(BUILDOPTS)endifI have added this rule to my makefile, seems to work. I have no ideaif I break anything by adding this to the makefilefpcmake is now created in directory utils/fpcm/fpcmakeNow installation nearly works, last problem is that FPCMAKE path getsdefined wrong as:make -C embedded all/Users/ring/devel/fpc/utils/fpcm/bin/i386-darwin/fpcmake -p -Tarm-embedded Makefile.fpcmake[2]: /Users/ring/devel/fpc/utils/fpcm/bin/i386-darwin/fpcmake: Nosuch file or directoryI can fix this by defining FPCMAKENEW to the real position of fpcmakeafter the build:sudo make installbase CROSSINSTALL=1 OS_TARGET=embeddedCPU_TARGET=arm SUBARCH=$SUBARCH CROSSOPT=-godwarfsets -gw2 -O-BINUTILSPREFIX=arm-none-eabi-FPCMAKENEW=/Users/ring/devel/fpc/utils/fpcm/fpcmakeAt this point I ask myself if this error exists because I didsomething wrong building fpcmake.Any ideas?TnX,Michael___fpc-devel maillist - fpc-devel@lists.freepascal.orghttp://lists.freepascal.org/mailman/listinfo/fpc-devel___fpc-devel maillist - fpc-devel@lists.freepascal.orghttp://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] assumed bug in the RTL with ARM v5 regarding loadingdynamic libraries
From: Michael Schnell mschn...@lumino.de Hi fpc RTL experts. My project uses Synapse but features link problems and crashes when I resolve same. Tracking this down: Synapse uses the unit dynlibs dynlibs uses the unit dl dl does not have a uses clause, so the problem seems to be here. When in a dedicated test project I just do uses dl, I get the linker message about _fini and _init, that I feature with any use of Synapse. It seems you have libdl statically linked to your executable. That's why you have such linker errors. Probably the linker is unable to find libdl.so but finds only libdl.a Anyway static linking should work too, but you need to link with libc. If you get segfaults when linking to libc, then cprt0.as for arm-linux is buggy. Yury Sidorov. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC statusy
From: Marco van de Voort mar...@stack.nl In our previous episode, Sven Barth said: and linked about 10 times as fast as FPC. AFAIK Delphi's command line compiler does not allow you to skip the assembling and linking phase, so the fairest comparison would be to compare the compilation of a single unit as there the linking phase is skipped. If Delphi is still better there then there are two possibilities: improve the internal assembler or the parser/code generator. Please keep in mind though that FPC's code generator is written in such a way that the backend can be switched rather easily. As we learned with the developer's blog entries about Delphi XE2 this wasn't the case with Delphi XE and older. So it could be that you can never reach the speed of Delphi 7's compiler as FPC is more portable. The numbers Martin names (up till 10 times slower, even without linking) are the numbers I have in mind too. IMHO denial without tests is unfair. I had a setup where I compiled zeos with FPC and Delphi (which doesn't link), and iirc the results were also 7-10times, with delphi XE. I also got similar results few years ago. Also I made some profiling and found a bottleneck in FPC. It is HUGE number of creations of small (or even tiny) objects (various compiler nodes). Each object creation allocates small chunk of memory and zero fills it. It is very time consuming. It is possible to seed-up compilation by allocating memory for nodes from some zero pre-filled memory pool to avoid costly calls to heap manager and avoid zero filling of small memory chunks. A base class for various FPC nodes should be modified to handle aloocation from the pool... Yury Sidorov, j...@cp-lab.com ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC statusy
From: Florian Klaempfl flor...@freepascal.org Am 25.12.2012 13:39, schrieb Yury Sidorov: It is possible to seed-up compilation by allocating memory for nodes from some zero pre-filled memory pool to avoid costly calls to heap manager and avoid zero filling of small memory chunks. A base class for various FPC nodes should be modified to handle aloocation from the pool... The heap manager itself does already pooling so I don't see much gain in doing so ... Still zero-filling a million of small memory chunks is very time consuming. It is better to pre-zerofill big pool blocks first and then assueme that memory already zero fillled in custom object init code. Although FPC heap manager is good, but custom pool memory allocation will be much faster, since it will be very simple: Result:=CurPoolPtr; Inc(CurPoolPtr, BlockSize); if CurPoolPtr MaxPoolPtr then AllocNewZeroFilledPool(); It is not needed to handle memory releases during object destruction. Since all nodes are available during whole compiling phase (parsing, code generation, etc) and released only at the end of a phase, it is possible just to release whole pool blocks at the end of a phase. Such pooled base class for compiler nodes should inrease performanse a lot. Yury Sidorov, j...@cp-lab.com ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC statusy
From: Yury Sidorov j...@cp-lab.com From: Florian Klaempfl flor...@freepascal.org Am 25.12.2012 13:39, schrieb Yury Sidorov: It is possible to seed-up compilation by allocating memory for nodes from some zero pre-filled memory pool to avoid costly calls to heap manager and avoid zero filling of small memory chunks. A base class for various FPC nodes should be modified to handle aloocation from the pool... The heap manager itself does already pooling so I don't see much gain in doing so ... Still zero-filling a million of small memory chunks is very time consuming. It is better to pre-zerofill big pool blocks first and then assueme that memory already zero fillled in custom object init code. Although FPC heap manager is good, but custom pool memory allocation will be much faster, since it will be very simple: Result:=CurPoolPtr; Inc(CurPoolPtr, BlockSize); if CurPoolPtr MaxPoolPtr then AllocNewZeroFilledPool(); It is not needed to handle memory releases during object destruction. Since all nodes are available during whole compiling phase (parsing, code generation, etc) and released only at the end of a phase, it is possible just to release whole pool blocks at the end of a phase. Such pooled base class for compiler nodes should inrease performanse a lot. Hmm, Seems to be a false alarm :( I've made some tests just now with memory allocation and found that such pooling will not speed up the compiler too much. Only minor improvement such as 10-20% :( Yury Sidorov, j...@cp-lab.com ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC statusy
From: Paul Ishenin paul.ishe...@gmail.com 25.12.12, 21:59, Yury Sidorov пишет: Hmm, Seems to be a false alarm :( I've made some tests just now with memory allocation and found that such pooling will not speed up the compiler too much. Only minor improvement such as 10-20% :( 10-20% is still much better than nothing. Sure, but I would be happy to expect at least 2X increase :) In such case I would start coding the fix right now :) Yury Sidorov, j...@cp-lab.com ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] registry changes
Hi, OK. I'll add needed defines to registry unit for Windows using this method: HKEY_LOCAL_MACHINE= windows.HKEY_LOCAL_MACHINE Yury Sidorov, j...@cp-lab.com - Original Message - From: Martin To: FPC developers' list Sent: Monday, December 24, 2012 1:13 PM Subject: [fpc-devel] registry changes Writing this from my laptop I do not currently have all the various checkouts to look at the exact changes myself. But enquiring based on the reports I have read. http://bugs.freepascal.org/view.php?id=23523 From FPC trunk r23202 log: * Include regdef.inc only if XMLREG is defined (non-Windows platforms). On Windows it is not needed since the Windows unit is included and it has all necessary declarations. Keeping duplicate declarations in regdef.inc on Windows is dangerous since it leads to out of sync problems. * Cleanup regdef.inc to contain only necessary types and constants to work with registry unit on non-Windows platforms. --- I could not find any remarks on the user changes for trunk It appears this change breaks existing units. Technically easy to fix, it complicates user code by adding a need for fidef in the uses clause, so that compiling on windows includes the windows unit (which would break compiling on none windows.) I understand that code duplication should be avoided. Given that before registry code only required one unit, and no undef, I did wonder if a simple forward declaration (as replacement) was considered, and if so, why if was not chosen. That is as an example in 2.4 the include file in unit registry defines it's own HKEY_LOCAL_MACHINE= HKEY($8002); That of course is not good, as it duplicates the define in windows, with the risk of not being updated, should the value change. But it could have defined HKEY_LOCAL_MACHINE= windows.HKEY_LOCAL_MACHINE Then the compilation of other units would not have been broken ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unwanted finalization
Hi, Funny, but I have also encountered the problem in this place yesterday :) But with PVariant(VarResult)^ in my case. Yes, the declaration of ITypeInfo.Invoke() should be changed to eliminate unwanted compiler magic with managed types when a nil is passed. I'll commit the required changes today or tomorrow. Best Regards! Yury Sidorov. - Original Message - From: Ludo Brands ludo.bra...@free.fr To: 'FPC developers' list' fpc-devel@lists.freepascal.org Sent: Saturday, October 13, 2012 6:34 PM Subject: [fpc-devel] Unwanted finalization Dear all, In comobj.pp I'm getting sometimes a SIGSEGV in the following code: function TAutoObject.Invoke(DispID: LongInt; const iid: TGUID; LocaleID: longint; Flags: Word; var params; VarResult, ExcepInfo, ArgErr: pointer): HResult; stdcall; ... begin ... Result := TAutoObjectFactory(Factory).DispTypeInfo.Invoke(Pointer( PtrUint(Self) + TAutoObjectFactory(Factory).DispIntfEntry^.IOffset), DispID, Flags, TDispParams(Params), PVariant(VarResult)^, PExcepInfo(ExcepInfo)^, PUINT(ArgErr)^); ... end; The interface method called (ITypeInfo::Invoke) is defined in activex.pp as Function Invoke(pvInstance: Pointer; memid: MEMBERID; wFlags: WORD; VAR pDispParams: DISPPARAMS; OUT pVarResult: VARIANT; OUT pExcepInfo: EXCEPINFO; OUT puArgErr: UINT):HResult;StdCall; The problem is with the ExcepInfo parameter which is a record. ITypeInfo::Invoke can have a null pExcepInfo parameter and the PExcepInfo(ExcepInfo)^ cast causes a call to fpc_finalize with a null pointer. Is there a way to avoid the finalisation of PExcepInfo(ExcepInfo)^ ? EXCEPINFO has a widestring member... IMO the ITypeInfo::Invoke method should be changed to Function Invoke(pvInstance: Pointer; memid: MEMBERID; wFlags: WORD; VAR pDispParams: DISPPARAMS; pVarResult: PVARIANT; pExcepInfo: PEXCEPINFO; puArgErr: PUINT):HResult;StdCall; but that requires changing all the code that calls this method. On the other hand I'm afraid that any code calling this method with the current definition will have potentially the same problem with the finalization of the EXCEPINFO record. Ludo ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unwanted finalization
Hello, The declaration of ITypeInfo.Invoke() is broken now anyway. Some of out parametrs should accept nil values and it is not possible with the current declaration. I doubt that ITypeInfo.Invoke() is used directly by user code. Especially in this broken form. Yury Sidorov, j...@cp-lab.com - Original Message - From: Jonas Maebe jonas.ma...@elis.ugent.be To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Saturday, October 13, 2012 7:05 PM Subject: Re: [fpc-devel] Unwanted finalization On 13 Oct 2012, at 18:01, Yury Sidorov wrote: Funny, but I have also encountered the problem in this place yesterday :) But with PVariant(VarResult)^ in my case. Yes, the declaration of ITypeInfo.Invoke() should be changed to eliminate unwanted compiler magic with managed types when a nil is passed. I'll commit the required changes today or tomorrow. Can't you add an overloaded version to avoid breaking backward compatibility? Or does this problem occur all the time, so that it's better to break compilation than have people hunt all over the source code to find all possible problem locations? Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unwanted finalization
Committed in r22638. Thanks. - Original Message - From: Ludo Brands ludo.bra...@free.fr To: 'FPC developers' list' fpc-devel@lists.freepascal.org Sent: Saturday, October 13, 2012 7:26 PM Subject: Re: [fpc-devel] Unwanted finalization Hello, The declaration of ITypeInfo.Invoke() is broken now anyway. Some of out parametrs should accept nil values and it is not possible with the current declaration. I doubt that ITypeInfo.Invoke() is used directly by user code. Especially in this broken form. I completely agree. According the MSDN the last 3 out parametes can be nil. Attached is the patch that works for me. I'm writing a fpc COM server called with late binding from PHP. Ludo ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] big resource
From: Dariusz Mazur dar...@emadar.com
Michael Van Canneyt pisze:
On Mon, 6 Jul 2009, Dariusz Mazur wrote:
Hi
I include res file to executed file. Res is compiled by brcc32
from RC. Till now everything work OK.
But when i try extract big PNG picture from RES I had wrong size
of file.
File has length 136303.
When I read it from res length is 5321. This seems size of res
is 16 bit.
This is intentional that size of resource is limited ?
Not intentionally, at least not that I am aware of. Maybe there is
a bug ?
I use {$R file.res}
How prepare testcase: should I attach big PNG+RC+RES file?
You should try FPC 2.3.1 first. It has rewritten resources support and
may work properly.
Yury.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] path for *.res file
From: Vincent Snijders vsnijd...@vodafonevast.nl Jonas Maebe schreef: On 22 May 2009, at 23:00, Dariusz Mazur wrote: How to tell compiler where are *.res files. You can't. As you noticed, they are always searched relative to the directory of the main source file (unless the resource file is specified using an absolute path) And that means, it is really impossible to include a *.rc file in a unit and distrubute the *.res file as compiled resource with your compiled unit. .rc files are searched relative to the current unit path. .res files are placed into units output folder specified by -FU switch. After that you can distribute compiled units with compiled .res files without sources. Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] path for *.res file
From: Dariusz Mazur dar...@emadar.com Jonas Maebe pisze: On 23 May 2009, at 11:05, Vincent Snijders wrote: Can't the searching be extended to the unit directory. It would make the file C:\fpc\2.2.4\units\i386-win32\fcl-base\fclel.res really useful, now have to copy it to my program dir to be able to use deamonapp unit. WDDD? (What Does Delphi Do) If Delphi also somehow has support for resource search paths (via the unit search path or otherwise), it doesn't make sense to implement a different solution. (since in that case someone will probably file a bug report at some point asking for also supporting it in a Delphi-compatible way). I have all *.res files in one separate directory in Delphi (via search path). Now I try to use *.res in Linux. Everything goes fine, FPC can handle ordinary *.res, although *.rc has to be compiled by brcc32 You can get/build crossbinutils for i386-win32. Then rename i386-win32-windres to windres. After that fpc will compile .rc files for you using that windres. Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] How to call windres with parameters that are shortpathwith forward slashes
From: Vincent Snijders vsnijd...@vodafonevast.nl Vincent Snijders schreef: Hi, separator. Can you give me some guidelines how to write a patch for the compiler? Please review the patch attached to http://bugs.freepascal.org/view.php?id=12645 Looks good to me. Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode and UTF8String
From: Michael Schnell [EMAIL PROTECTED] And yes, if you lazy, you lose performance due to automatic conversions. It has always been that way (also when mixing short and ansistring) Of course you are very right here ! If you are lazy and write your code like you are used to, you will not get optimum performance with a new compiler that now allows for Unicode. But the code still needs to be working as expected (as with a compiler version that does not allow for Unicode, but simply uses ANSI or whatever OS and locale depending 8-Bit code). In most programs that will not be a problem at all as doing extensive string calculations in user-code is not necessary. Of course, if you want to take real advantage of Unicode (using characters outside your current locale) or if you want to optimize (for speed or for memory size) you need to be aware of the Unicode stuff and write your code appropriately. It is planned to allow users to build ANSI version of RTL which will be fully compatible with existing user code. But if you choose to use unicode RTL, you must keep in mind all unicode specific things... Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode support in RTL - Roadmap
From: Michael Schnell [EMAIL PROTECTED] It is works for win32 only for now. Only system unit is finished. Work in progress... Sounds great so far ! Is there a document on how exactly it is going to work (will a common String type get a dynamic coding specification or will there be different String types for any coding variants ? No docoment is available yet. This branch is still experimental. It introduces RtlString - string type which is native to RTL on corresponding target. RtlString=utf16string on windows, RtlString=utf8string for unix, etc. Also RtlString can be ansistring. In this case RTL will be ANSI only and 100% compatible with existing ANSI user code. It is planned to allow users to build unicode or ansi RTL. Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode support in RTL - Roadmap
From: Florian Klaempfl [EMAIL PROTECTED] Folks, before your waste your time again with endless discussions, have a look at Yury's work on an unicode rtl, test it and help with patches and suggestions, it's available in svn at http://svn.freepascal.org/svn/fpc/branches/unicodertl It is works for win32 only for now. Only system unit is finished. Work in progress... Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Bug in FPC and declaring distinct types
From: Florian Klaempfl [EMAIL PROTECTED]
Michael Van Canneyt schrieb:
On Thu, 18 Sep 2008, Graeme Geldenhuys wrote:
Hi,
I was following a discussion in the delphi.non-technical
newsgroup.
They raised an issue about distinct types. I tried the following
example under FPC and unexpectedly, FPC doesn't raise any errors!
If you declare a distinct type as follows:
type TMyInteger = type Integer;
The type TMyInteger Integer so you are not supposed to be
allowed
to assign one to the other. Yet you can. See the following
program.
But obviously delphi also allows it ? It compiles everything,
just not as a var parameter.
The whole 'Type' thing is a bit ridiculous: the only reason they
did it
is so they can have different type pointers in the RTTI for
something which
is the same 'type' anyway. For the rest it is extremely badly
designed, and not really consistent. It serves no purpose. FPC
introduced it to be able to compile Delphi code, no other reason.
This is not true. The main purpose is to be able to overload
functions/operators:
type
TUTF8String = type ansistring;
enables you to overload all procedure already defined for
ansistrings with UTF8String functions but reusing ansistring support
functionality and this is supported for years. Because nobody used
this yet to make an utf-8 unit, I never took the unicode string
support serious :)
Yes. But it works only partially. For example the following code is
not compilable:
//--
type
TUTF8String = type ansistring;
procedure DoTest(const s: ansistring); overload;
begin
end;
procedure DoTest(const s: TUTF8String); overload;
begin
end;
begin
DoTest('1234');
end.
//--
Yury Sidorov.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Bug in FPC and declaring distinct types
From: Florian Klaempfl [EMAIL PROTECTED]
Yury Sidorov schrieb:
From: Florian Klaempfl [EMAIL PROTECTED]
Michael Van Canneyt schrieb:
On Thu, 18 Sep 2008, Graeme Geldenhuys wrote:
Hi,
I was following a discussion in the delphi.non-technical
newsgroup.
They raised an issue about distinct types. I tried the following
example under FPC and unexpectedly, FPC doesn't raise any
errors!
If you declare a distinct type as follows:
type TMyInteger = type Integer;
The type TMyInteger Integer so you are not supposed to be
allowed
to assign one to the other. Yet you can. See the following
program.
But obviously delphi also allows it ? It compiles everything,
just not as a var parameter.
The whole 'Type' thing is a bit ridiculous: the only reason they
did it
is so they can have different type pointers in the RTTI for
something which
is the same 'type' anyway. For the rest it is extremely badly
designed, and not really consistent. It serves no purpose. FPC
introduced it to be able to compile Delphi code, no other reason.
This is not true. The main purpose is to be able to overload
functions/operators:
type
TUTF8String = type ansistring;
enables you to overload all procedure already defined for
ansistrings with UTF8String functions but reusing ansistring
support functionality and this is supported for years. Because
nobody used this yet to make an utf-8 unit, I never took the
unicode string support serious :)
Yes. But it works only partially. For example the following code is
not compilable:
Well, I wouldn't know either what you expect :)
I expect that compiler will choose DoTest with ansistring parameter in
that case.
//--
type
TUTF8String = type ansistring;
procedure DoTest(const s: ansistring); overload;
begin
end;
procedure DoTest(const s: TUTF8String); overload;
begin
end;
begin
DoTest('1234');
end.
//--
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Bug in FPC and declaring distinct types
From: Florian Klaempfl [EMAIL PROTECTED]
To: FPC developers' list fpc-devel@lists.freepascal.org
Sent: Thursday, September 18, 2008 4:14 PM
Subject: Re: [fpc-devel] Bug in FPC and declaring distinct types
Yury Sidorov schrieb:
Yes. But it works only partially. For example the following code
is not compilable:
Well, I wouldn't know either what you expect :)
I expect that compiler will choose DoTest with ansistring parameter
in that case.
What rule do you apply to say this?
Compiler treats '1234' as ansistring constant. Therefore ansistring
overload must be choosen here.
Like in this case:
const
sss: ansistring = '1234';
...
DoTest(sss);
//--
type
TUTF8String = type ansistring;
procedure DoTest(const s: ansistring); overload;
begin
end;
procedure DoTest(const s: TUTF8String); overload;
begin
end;
begin
DoTest('1234');
end.
//--
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Bug in FPC and declaring distinct types
From: Florian Klaempfl [EMAIL PROTECTED]
Yury Sidorov schrieb:
From: Florian Klaempfl [EMAIL PROTECTED]
To: FPC developers' list fpc-devel@lists.freepascal.org
Sent: Thursday, September 18, 2008 4:14 PM
Subject: Re: [fpc-devel] Bug in FPC and declaring distinct types
Yury Sidorov schrieb:
Yes. But it works only partially. For example the following
code is not compilable:
Well, I wouldn't know either what you expect :)
I expect that compiler will choose DoTest with ansistring
parameter in that case.
What rule do you apply to say this?
Compiler treats '1234' as ansistring constant. Therefore ansistring
overload must be choosen here.
No, '1234' is taken as generic string constant.
Yes, I just tried to explain possible logic :)
Also the following code is not possible currently:
//--
operator := (const s: ansistring) r: TUTF8String;
begin
end;
operator := (const s: TUTF8String) r: ansistring;
begin
end;
//--
It makes implementation of utf8string impossible using this
approach...
//--
type
TUTF8String = type ansistring;
procedure DoTest(const s: ansistring); overload;
begin
end;
procedure DoTest(const s: TUTF8String); overload;
begin
end;
begin
DoTest('1234');
end.
//--
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Bug in FPC and declaring distinct types
From: Florian Klaempfl [EMAIL PROTECTED] Yury Sidorov schrieb: From: Florian Klaempfl [EMAIL PROTECTED] Yury Sidorov schrieb: From: Florian Klaempfl [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Thursday, September 18, 2008 4:14 PM Subject: Re: [fpc-devel] Bug in FPC and declaring distinct types Yury Sidorov schrieb: Yes. But it works only partially. For example the following code is not compilable: Well, I wouldn't know either what you expect :) I expect that compiler will choose DoTest with ansistring parameter in that case. What rule do you apply to say this? Compiler treats '1234' as ansistring constant. Therefore ansistring overload must be choosen here. No, '1234' is taken as generic string constant. Yes, I just tried to explain possible logic :) Also the following code is not possible currently: //-- operator := (const s: ansistring) r: TUTF8String; begin end; operator := (const s: TUTF8String) r: ansistring; begin end; //-- It makes implementation of utf8string impossible using this approach... We discussed this once and concluded, that something like this hurts more than it helps because an overloaded assignment operator allows the compiler always to mess really around :) Maybe. But you stated that it is possible to create fully functional utf8string type from ansistring. :) Unfortunately it is not true :( Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] winmobile 6.1 problem?
No idea. I use FPC 2.2.0 as starting compiler for 'make cycle' and it works. Yury. - Original Message - From: Roozbeh GHolizadeh To: FPC developers' list Sent: Monday, July 21, 2008 10:20 AM Subject: Re: [fpc-devel] winmobile 6.1 problem? Thanks, by the way why i need to define VER2_2 to compile successfully compiler? it gives me error in base.inc file,i have to define that,although my compiler version is 2.3.1 --- On Mon, 7/21/08, Yury Sidorov [EMAIL PROTECTED] wrote: From: Yury Sidorov [EMAIL PROTECTED] Subject: Re: [fpc-devel] winmobile 6.1 problem? To: FPC developers' list fpc-devel@lists.freepascal.org Date: Monday, July 21, 2008, 1:23 AM Hi,I fixed the problem in rev. 11421.Funny thing that I started to investigate this problem in morning today before your e-mails :)Not funny thing is that took whole day to find out what caused the problem :(Damn WM6.1!!!Yury.- Original Message - From: Roozbeh GHolizadehTo: FPC developers' listSent: Sunday, July 20, 2008 9:37 PMSubject: Re: [fpc-devel] winmobile 6.1 problem?Well,i come to this.dlls built with fpc does not work under wm6.1.i am using ppcrossarm 2.3.1 from todays svnbuilding simple dll with one export function and linking to it all with fpc,makes program not to run under wm6.1,but works fine under older oses!so?--- On Sun, 7/20/08, Carolos [EMAIL PROTECTED] wrote:From: Carolos [EMAIL PROTECTED]Subject: Re: [fpc-devel] winmobile 6.1 problem?To: FPC developers' list fpc-devel@lists.freepascal.orgDate: Sunday, July 20, 2008, 7:50 PMOut of interest, what switches are you using to compile dll?On Sun, Jul 20, 2008 at 12:23 PM, Roozbeh GHolizadeh [EMAIL PROTECTED] wrote:Hi,i have a dll compiled with fpc which i load it from my another dll compiled with vc++ using loadlibrary function.So far there was no problem,but with winmo 6.1 using loadlibrary will cause crashes and return NULL.so it doesnt load it at all!I was wondering how can i pinpoint the problem.my dll,uses units with initialization sections,could if any crash happen there causes library not to load?because i guess loading library doesnt do anything but just moving it into memory space?(or does those initialization sectiors end up in dllmain,attach_process?)So?Regards,Roozbeh GHolizadeh___fpc-devel maillist - [EMAIL PROTECTED]://lists.freepascal.org/mailman/listinfo/fpc-devel___fpc-devel maillist - [EMAIL PROTECTED]://lists.freepascal.org/mailman/listinfo/fpc-devel___fpc-devel maillist - [EMAIL PROTECTED]://lists.freepascal.org/mailman/listinfo/fpc-devel ___fpc-devel maillist - [EMAIL PROTECTED]://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] winmobile 6.1 problem?
Hi, I fixed the problem in rev. 11421. Funny thing that I started to investigate this problem in morning today before your e-mails :) Not funny thing is that took whole day to find out what caused the problem :( Damn WM6.1!!! Yury. - Original Message - From: Roozbeh GHolizadeh To: FPC developers' list Sent: Sunday, July 20, 2008 9:37 PM Subject: Re: [fpc-devel] winmobile 6.1 problem? Well,i come to this. dlls built with fpc does not work under wm6.1. i am using ppcrossarm 2.3.1 from todays svn building simple dll with one export function and linking to it all with fpc,makes program not to run under wm6.1,but works fine under older oses! so? --- On Sun, 7/20/08, Carolos [EMAIL PROTECTED] wrote: From: Carolos [EMAIL PROTECTED] Subject: Re: [fpc-devel] winmobile 6.1 problem? To: FPC developers' list fpc-devel@lists.freepascal.org Date: Sunday, July 20, 2008, 7:50 PM Out of interest, what switches are you using to compile dll? On Sun, Jul 20, 2008 at 12:23 PM, Roozbeh GHolizadeh [EMAIL PROTECTED] wrote: Hi, i have a dll compiled with fpc which i load it from my another dll compiled with vc++ using loadlibrary function. So far there was no problem,but with winmo 6.1 using loadlibrary will cause crashes and return NULL.so it doesnt load it at all! I was wondering how can i pinpoint the problem. my dll,uses units with initialization sections,could if any crash happen there causes library not to load? because i guess loading library doesnt do anything but just moving it into memory space?(or does those initialization sectiors end up in dllmain,attach_process?) So? Regards, Roozbeh GHolizadeh ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___fpc-devel maillist - [EMAIL PROTECTED]://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FreePascal on ARM Linux ,SoftFloat and EABI issues
From: Nataraj S Narayan Hi Florian and other friends I am involved in porting existing C code to Arm Linux for AT91SAM9263 Ek board with 340x220 display. I need to write lots of console kinda apps. I am using a qemu-system-arm emulated Armel Debian machine on a Debian x86 Lenny distro for writing code. I installed fpc-2.2.0.arm-linux.tar on the emulated linux.Which compiling a simple helloworld.pas , i get the classic error of System.o being EABI 0 while target is EABI 4. I have got the svn download of fpc, and trying to compile it in the emulated machine for ARM for the past 2 days. I have given :-make clean all ARCH=arm OPT=-CfSoft.Its compiling for quite long and finally comes to rest endlessly while compiling system.pp.Let me remind you that i am dont use a Cross compiler, but an emulated Arm machine. Try to crosscompile fpc 2.2.1 or 2.3.1 compiler binary and then use this binary as starting compiler on arm machine. Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Please fix the ARMv5 runtime detection in fpc 2.2.1
From: Bernd Mueller [EMAIL PROTECTED] Hello, The ARMv5 runtime detection is fixed in fpc 2.3.1. Could you please apply this fix to fpc 2.2.1 too? The procedure fpc_cpucodeinit in rtl/arm/arm.inc is affected. I merged it to 2.2.1 Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Patch, font rendering on Arm-Linux devices.
From: Daniël Mantione [EMAIL PROTECTED] Instead unaligned will simulate an unaligned load with two loads and some rotation etc. On the ARM, where every mnemonic can rotate operands, this is isn't that bad of a penalty. Therefore, I wouldn't be surprised that even on ARM, arrays with packed structures are faster than arrays with unpacked structures. That's possible. Why would it be faster, btw? Better cache coherency? Like I mentioned, unliek modern x86 processors, ARM processors cannot detect an array traversal and preload the array into the cache. If the array is not in cache, you get cache miss after cache miss. A cache miss is very expensive with latencies of modern memory. A smaller array results in less cache misses. I run my benchmark on ARM mobile and got the following results: 2080ms - for non-packed 4450ms - for packed It clearly shows that ualigned access kills performance on ARM... Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Patch, font rendering on Arm-Linux devices.
From: Daniël Mantione [EMAIL PROTECTED] On Thursday 28 February 2008 09:16, Daniël Mantione wrote: Memory access. What happens is that the non-packed version causes more cache misses. Please elaborate. If the (unaligned) data is crossing a cache-line, thus causing two full cache-line reads, I'd understand that, but once it's in the cache, it wouldn't matter anymore? Yes, but if you have an array of them (as we have in this case), considerably more of these records will fit in the cache. Therefore you will have considerably less cache misses. This becomes even more serious when the processor in question does not have prefetching; in such case, traversing the array will cause cache miss after cache miss, a smaller array will then have less of these misses. You are right. Array of packed records is a bit more effective than array of non-packed records, at least on modern x86 CPUs. I do some benchmarks and got on Core Duo: 2070ms - for non-packed 1910ms - for packed But for CPUs which do not support misaligned data access - packed records are speed killers and need to be used as the last resort. Also if record is not element of large array it is better do declare it as non-packed for all CPUs. Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Patch, font rendering on Arm-Linux devices.
From: Daniël Mantione [EMAIL PROTECTED] Bernd Mueller schreef: Hello, the attached patch avoids misaligned data access (bus errors), during font rendering (with the graph unit) on Arm-Linux devices. Instead of testing for arm cpu, you could use FPC_REQUIRES_PROPER_ALIGNMENT too. So it is fixed for sparc as well. Well, packed records are usually used when speed is unimportant. If the code is speed critical, packed should not be used for aby platform. Therefore I would like Bernd to consider the use of the 'unaligned' pseudo-function, ifdefs make code less readable. The patch removes packed record for some platforms. IMO packed can be removed for all platforms. It will gain some speed. Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compilation failure on wince
From: Felipe Monteiro de Carvalho [EMAIL PROTECTED] Hello, I am trying to build the latest fixes wince cross-compiler (2.2.1) using FPC 2.2.0 as a starting compiler. It fails when I try to build packages, particularly fcl-process Here is my script: cd packages PATH=C:\Programas\lazarus220\fpc\2.2.0\bin\i386-win32 make clean all CPU_TARGET=arm OS_TARGET=wince PP=ppcrossarm.exe OPT=-FUC:\Programas\lazarus220\fpc\2.2.1\units\arm-wince cd .. pause And the error: make[1]: Leaving directory `C:/Programas/fpc_fixes/packages/fcl-base' make -C fcl-process all make[1]: Entering directory `C:/Programas/fpc_fixes/packages/fcl-process' ppcrossarm.exe -Twince -Parm -XParm-wince- -Xr -S2h -Fu../../rtl/units/arm-wince -Fisrc/wince -Fisrc -Fisrc/win -FE. -FUunits/arm-wince -FUC:\Programas\lazarus2 20\fpc\2.2.1\units\arm-wince -darm src/pipes.pp Free Pascal Compiler version 2.2.1 [2008/01/10] for arm Copyright (c) 1993-2007 by Florian Klaempfl Target OS: WinCE for ARM Compiling src\pipes.pp pipes.pp(81,22) Error: Identifier not found WriteNotImplemented pipes.pp(81,22) Error: Illegal expression pipes.pp(122,21) Error: Identifier not found ReadNotImplemented pipes.pp(122,21) Error: Illegal expression pipes.pp(134) Fatal: There were 4 errors compiling module, stopping Fatal: Compilation aborted make[1]: *** [pipes.ppu] Error 1 make[1]: Leaving directory `C:/Programas/fpc_fixes/packages/fcl-process' make: *** [fcl-process_all] Error 2 The latest fixes_2_2 branch compiles fine for arm-wince for me. Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] ppcrossarm build fails to compile rtl and packages
From: [EMAIL PROTECTED] I'm trying to build an arm/wince cross-compiler from a Windows XP host from 2.2.1 SVN (rev 10079). I can build a working ppcrossarm.exe from the fpc source folder by: make compiler_cycle CPU_TARGET=arm OS_TARGET=wince FPC=ppc386.exe However, when I try to build the RTL and packages with the following: make -C rtl clean FPC=ppcrossarm.exe make rtl packages FPC=ppcrossarm.exe OPT=-g The process terminates at the instruction to build the package FV: Fixed now. Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] PocketCMD for Windows CE devices
From: Florian Klaempfl [EMAIL PROTECTED] Graeme Geldenhuys schrieb: Hi, The following website isn't working anymore... Could somebody please email me a copy of PocketCMD or have an alternative link I can download if from. http://www.symbolictools.de/public/pocketconsole/applications/PocketCMD/index.htm Problem is that it works not anymore on Windows Mobile 5 or 6. It works with some registry tweaks like: To make PocketConsole run on Windows Mobile 5, you have to change the registry entry HKEY_LOCAL_MACHINE\Drivers\Console\OutputTo to value 0. It dont work well on VGA devices... Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] PocketCMD for Windows CE devices
From: Graeme Geldenhuys [EMAIL PROTECTED] On 19/01/2008, Florian Klaempfl [EMAIL PROTECTED] wrote: Problem is that it works not anymore on Windows Mobile 5 or 6. I want to develop (fpGUI Toolkit) for my iQue M5 PDA which runs Windows Mobile 2003 2nd edition. So it should be ok. Anybody know where I can get a Windows Mobile 2003 2nd Edition emulator? I'm not sure if it's a good idea to try and run apps directly on my PDA first time round. The only link I could find in Microsoft's site is for Windows Mobile 6 SDK (which I think includes a emulator). PS: I'm a total newbie to PocketPC development - I've never done it before. You can safely develop on WM5 or WM6 emulator. The program will run on WM2003 in most cases. You can test it on real WM2003 device from time to time. Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] PocketCMD for Windows CE devices
From: Graeme Geldenhuys [EMAIL PROTECTED] On 19/01/2008, Yury Sidorov [EMAIL PROTECTED] wrote: You can safely develop on WM5 or WM6 emulator. The program will run on WM2003 in most cases. You can test it on real WM2003 device from time to time. That's good to know, thanks Yury. PS: Any change you can email me a copy of PocketConsole (or PocketCMD - not sure if it's the same thing). From reviews on the internet I believe it is free, but the original website doesn't exist anymore or is currently down. I e-mailed it to you. Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] PocketCMD for Windows CE devices
From: Graeme Geldenhuys [EMAIL PROTECTED] On 19/01/2008, Felipe Monteiro de Carvalho [EMAIL PROTECTED] wrote: On Jan 19, 2008 10:47 AM, Graeme Geldenhuys [EMAIL PROTECTED] wrote: Anybody know where I can get a Windows Mobile 2003 2nd Edition emulator? I may be wrong, but it's possible that the only solution is going back in time and get them from MS website =) I found Windows Mobile 2003 2nd Edition image (emulator) on the Microsoft site. I'm not sure what's the difference between them, but am currently downloading the first link. The WM5 and WM6 emulators require Windows XP and I only have Windows 2000. This images are for old x86 emulator, not ARM emulator. Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Threads not working in console application
From: Graeme Geldenhuys [EMAIL PROTECTED] Hi, I've created a while back a thread based Timer. At the time I developed the timer, I tested it in a Lazarus (LCL) GUI application and everything worked perfectly. Just tested it now and it still works fine. Today I tried to use that Timer in a Console application and a fpGUI based application and the timer doesn't work for some reason! I'm using FPC 2.2.0 under Linux. I attached a Console test project and the threadtimer.pas unit. Has anybody got any ideas as to why it doesn't work in a console app? BTW: To get the console app to continue running, I have a loop checking for a file or sleeps for 500 ms. The timer is enabled before that loop starts, so I am supposed to see output to the console. I added some debug writeln()'s to know when the time starts or stops and which events file (application loop or timer event). The thread itself works, but not Synchronize() method. You need to call CheckSynchronize inside main loop. Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TClientDataset (was: Dnamic packages support)
From: Michael Van Canneyt [EMAIL PROTECTED] We could try to compile Borlands' VCL code with FPC, of course, but then there is the problem that the midas library is a black box, available only for windows i386, which kind of defeats the purpose of the whole exercise.. There is open source midas.dll implementation called HyperBase. http://www.vglib.com/link-4.html It can be made compilable by FPC to different platforms... Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Seems gtk2 package contains small bug in declarationof TGtkScrolledWindow
From: Paul Ishenin [EMAIL PROTECTED] Any chance to have this patch commited? Applied. Thanks. Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Apache header translation Patch
From: Inoussa OUEDRAOGO [EMAIL PROTECTED] Hi, These patchs correct the cmd_func type in http_config.inc : - 2.2-http_config.inc.diff for apache 2.2 - 2.0-http_config.inc.diff for apache 2.0 After your patch a warning appeared when compiling httpd-2.2: http_config.inc(135,3) Warning: cdecl'ared functions have no high parameter Please take a look on it. Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Apache header translation Patch
From: Felipe Monteiro de Carvalho [EMAIL PROTECTED] On 11/1/07, Yury Sidorov [EMAIL PROTECTED] wrote: After your patch a warning appeared when compiling httpd-2.2: http_config.inc(135,3) Warning: cdecl'ared functions have no high parameter I just built it with fpc 2.3 and I see no warning ... strange Probably you have warning turned off. I get the following: Free Pascal Compiler version 2.3.1 [2007/11/01] for i386 Copyright (c) 1993-2007 by Florian Klaempfl Target OS: Win32 for i386 Compiling httpd.pas http_config.inc(134,3) Warning: cdecl'ared functions have no high parameter httpd.pas(158,32) Warning: Converting pointers to signed integers may result in wrong comparison results and range errors, use an unsigned type instead. httpd.pas(165,28) Warning: Converting pointers to signed integers may result in wrong comparison results and range errors, use an unsigned type instead. 9395 lines compiled, 0.2 sec 3 warning(s) issued Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] More on arm4, armi and thumb
From: Felipe Monteiro de Carvalho [EMAIL PROTECTED] It seams that building arm4 software isn't supported for Symbian OS. At least for third-party software, and any example build for it crashes on startup. So I was investigating other solutions. I was reading the nokia wiki: http://wiki.forum.nokia.com/index.php/ARM4,_ARMI__THUMB http://wiki.forum.nokia.com/index.php/Build_Targets Quoting: ARMI is the 32-bit instruction set with extra logic to allow it to call THUMB code in addition to other 32-bit code. ARMI is known as ARM interchange format. It seams that ARMI could be a solution. Executables built for ARMI actually work normally, but there seams to be a lack of information of what exactly is ARMI. The descriptions found are not detailed enougth. My greatest doubt is: Can I just compile normal arm4 object files with fpc and link them together with armi compiled object files to get the final executable? I have a fealing this could work, even if FPC doesn't do that extra logic to call THUMB, because we don't call the OS routines directly, but rather thougth a c wrapper. I will, of course, just test, but it will be a lot of work, and if someone knows in advance this should theoretically work, or shouldn't, that could speed things up =) The solution is to create wrapper library for OS calls. The library will do arm-thumb interworking. It will switch to thumb mode before OS call and switch back to ARM mode after OS call. Also startup code for FPC program should switch CPU to ARM mode. Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] More on arm4, armi and thumb
From: Felipe Monteiro de Carvalho [EMAIL PROTECTED] On 11/1/07, Marco van de Voort [EMAIL PROTECTED] wrote: It seems that when you branch, in the instruction you can encode if the instructionset of the target is thumb or not. So, currently fpc set's all branches to use arm4 mode And C++ apps compiled could check what the system is using and use a if to either call in arm4 or call in thumb mode. The strange thing is that this is a bit arbitrary. There is nothing special about an OS call, it's just a call like any other. I wonder where does the compiler get the information of if the function is in arm4 or thumb mode. FPC just do calls using BL command. It expects that all procedures are ARM4. C compilers has option called thumb interworking which wraps each procedure call with code which checks for procedure mode and performs necessary mode swithes. It will slowdown calls. Also as Marco said interworking code can be added or not depending of object file instruction set. Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Seems gtk2 package contains small bug in declarationofTGtkScrolledWindow
From: Paul Ishenin [EMAIL PROTECTED] Yury Sidorov пишет: From: Paul Ishenin [EMAIL PROTECTED] Any chance to have this patch commited? Applied. Thanks. Big thanks. Any chance to have this patch merged into 2.2 :) ? Done :) Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] ARM4 and THUMB instruction sets
From: Daniël Mantione [EMAIL PROTECTED] Op Wed, 17 Oct 2007, schreef Felipe Monteiro de Carvalho: so it may be useful to see of we can easely support thumb. Since we always use an external assembler for arm, I wounder: Wouldn't be supporting arm4/thumb just a question of switching a switch when calling the assembler? No, thumb assembler code is different from generating normal assembler code. You need serious code generator modifications. Even worse. Thumb is completely different instruction set with different number of registers. Completely new code generator is needed for thumb. Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] resource compilation fails, if cpp is not on the path
From: Vincent Snijders [EMAIL PROTECTED] Vincent Snijders schreef: Thanks for the review. I committed the patch in r8670. Can this be merged to the fixes branch for fpc 2.2.1? Fine for me. Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] resource compilation fails, if cpp is not on the path
From: Vincent Snijders [EMAIL PROTECTED] Yury Sidorov schreef: Yes. It is known issue. Compiler can search for cpp tool the same way as other tools like as, ld and then pass --preprocessor switch to windres if cpp was found. I created the attached patch. What do you think? Use FindFile and FindExe functions to search for cpp. The same way as windres binary is searched above: resfound:=false; if utilsdirectory'' then resfound:=FindFile(utilsprefix+bin+source_info.exeext,utilsdirectory,false,resbin); if not resfound then resfound:=FindExe(utilsprefix+bin,false,resbin); Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] resource compilation fails, if cpp is not on the path
From: Vincent Snijders [EMAIL PROTECTED] Yury Sidorov schreef: From: Vincent Snijders [EMAIL PROTECTED] Yury Sidorov schreef: Yes. It is known issue. Compiler can search for cpp tool the same way as other tools like as, ld and then pass --preprocessor switch to windres if cpp was found. I created the attached patch. What do you think? Use FindFile and FindExe functions to search for cpp. The same way as windres binary is searched above: resfound:=false; if utilsdirectory'' then resfound:=FindFile(utilsprefix+bin+source_info.exeext,utilsdirectory,false,resbin); if not resfound then resfound:=FindExe(utilsprefix+bin,false,resbin); utilsprefix is not necessary, don't you think? Or do you have i386-win32-cpp on linux for cross compilation? You are right. There is no need for prefix or path search in case of cpp. Your patch is correct. Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] resource compilation fails, if cpp is not on the path
From: Vincent Snijders [EMAIL PROTECTED]
Consider the following application:
program rescomp;
{$R lazarus.rc}
begin
end.
If I have an empty path variable and I call the compiler with an
absolute path, it fails, see below. The solution would be to add
the --preprocessor parameter to windres, as is done below. The
cpp.exe should be located in the same directory as windres. How can
this be done?
Vincent
D:\lazarus\bugs\rescompSET PATH=
D:\lazarus\bugs\rescompd:\fpc\2.3.1\bin\i386-win32\fpc rescomp.pas
Free Pascal Compiler version 2.3.1 [2007/07/12] for i386
Copyright (c) 1993-2007 by Florian Klaempfl
Target OS: Win32 for i386
Compiling rescomp.pas
Compiling resource lazarus.rc
gcc: installation problem, cannot exec `cpp': No such file or
directory
d:\FPC\2.3.1\bin\i386-win32\windres.exe: no resources
rescomp.pas(6,1) Error: Error while linking
rescomp.pas(6,1) Fatal: There were 1 errors compiling module,
stopping
Fatal: Compilation aborted
Error: d:\fpc\2.3.1\bin\i386-win32\ppc386.exe returned an error
exitcode (normal
if you did not specify a source file to be compiled)
D:\lazarus\bugs\rescompd:\fpc\2.3.1\bin\i386-win32\windres
lazarus.rc lazarus.r
es
gcc: installation problem, cannot exec `cpp': No such file or
directory
d:\fpc\2.3.1\bin\i386-win32\windres: no resources
D:\lazarus\bugs\rescompd:\fpc\2.3.1\bin\i386-win32\windres --preprocessor=d:\fp
c\2.3.1\bin\i386-win32\cpp.exe lazarus.rc lazarus.res
Yes. It is known issue. Compiler can search for cpp tool the same
way as other tools like as, ld and then pass --preprocessor switch
to windres if cpp was found.
Yury.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] internal linker import by index patch (xbox)
From: Andrew Haines [EMAIL PROTECTED] Hi, This patch is not ready yet, but can anyone give comments on the correctness of the third hunk in the patch dealing with AOrdNr? I've been working on getting fpc able to make xbox(1) programs and on the xbox there are no libraries but only kernel imports which are imported by number. A short explanation: An xbox exe is very similar to a win32 exe. It only links to the xbox kernel and imports functions by index. If an exe is generated that doesn't link to the standard win32 libs like kernel32.dll, then the program can be converted to an xbe(xbox executable) using a program called cxbe. So... with the third hunk applied and a bare system unit and a bunch of small changes here and there, I've been able to make a xbox program with fpc that I converted with cxbe. (all it does is write to video memory and then reboot) Is the patch correct? I suspect that importing by ordinal is not currently working for regular exe's made with the internal linker. Actually import by ordinal is implemented in works. Look at line 2416 of ogcoff.pas When AOrdNr 0 it indicates that import is by name, but ordinal number is specified as hint. Whan AOrdNr 0 then import by ordinal only. The patch changes so that the Import address table is putting $8000 or'ed against the import number instead of an RVA pointing to the import number(which is incorrect since a RVA is used here only if it is an import by name) Sorry if none of this makes sense, I think I may have overloaded my brain on this one :) Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] internal linker import by index patch (xbox)
From: Andrew Haines [EMAIL PROTECTED] Yury Sidorov wrote: Actually import by ordinal is implemented in works. Look at line 2416 of ogcoff.pas When AOrdNr 0 it indicates that import is by name, but ordinal number is specified as hint. Whan AOrdNr 0 then import by ordinal only. Okay yes I see that, but that is for the import lookup table not the import address table, the import address table is the same format as the import lookup table. Here is the behavior I observed: I import a function by index function SomeFunction: stdcall; external 'xboxkrnl.exe' index '1'; when it is compiled the start of the .idata section looks like this: ImportLookupTablePtr DateTimeStamp Junk PtrToLibName ImportAddressTablePtr The Import Lookup Table is written correctly with the ordinal name as expected. When I look at the Import Address Table, the entries are *not the same* as the lookup table, as they should be, but instead *point* to an address that contains the ordinal(not or'ed), when it should contain $8000 or'ed against the import ordinal. From the MS docs talking about the Import Address Table: Import Address Table RVA(Thunk Table): The RVA of the import address table. The contents of this table are identical to the contents of the lookup table until the image is bound. So even if my confusing explanation doesn't make sense, the Address Table should mirror the Lookup Table which it doesn't. It looks like maybe you are writing a Hint/Name table entry for an ordinal which is only done when importing by name. Yes. You are right. Import Address Table should contain the same data as Import Lookup Table. Currently it contains different data when importing by ordinal. It should be fixed, but it currently this bug has no effect on win32/64/CE. EXEs with ordinal imports are loaded properly. Does it afeect xbox? Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Small patch for messages
From: Felipe Monteiro de Carvalho [EMAIL PROTECTED] Hi, Attached patch fixes a typo when Unicode define is set, and adds two new windows messages I couldn't find in the rtl. Please review. Applied. Thanks. Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] DLL WIN64: Entry point not found
From: Mark - WBIsoft.COM [EMAIL PROTECTED] I had the same behaviour with a WIN64 DLL being loaded by WINLOGON.EXE, it fails to work - GetProcAddress calls fail, however, the same DLL loaded by an FPC app worked fine !!! I'm trying to build a simple demo DLL but with Gina replacement it's not that simple !!! I think there is some issue with the DLL image generated by FPC, just not sure what it is yet !? You need to upgrade to the latest svn version (or download snapshot) of FPC 2.1.5. DLL bugs were fixed after 2007/05/31. Yury Sidorov. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] DLL WIN64: Entry point not found
The problem can be caused by relocation. Try to force a dll to relocate in all cases by using -WB0 command line switch. Then create sample host application using fpc and try to reproduce the problem. Yury. - Original Message - From: Mark - WBIsoft.COM [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Thursday, July 19, 2007 4:58 PM Subject: Re: [fpc-devel] DLL WIN64: Entry point not found I am, the only problem is the sample needs to be a complete gina - as it's the loading by WINLOGON.EXE that causes it to break !! - Original Message - From: Yury Sidorov [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Thursday, July 19, 2007 2:46 PM Subject: Re: [fpc-devel] DLL WIN64: Entry point not found From: Luc Vigato, Sita Software [EMAIL PROTECTED] I have downloaded the latest snapshot. The error is thill there. With the test dll which I have send yesterday it's work fine now, but the finall DLL wich contains over 20 exported function I have an error. Try to create sample dll which reproduces the problem and submit bug report. Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.9/907 - Release Date: 18/07/2007 15:30 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Please merge SSE detecion fix to fixes_2_2
From: Jonas Maebe [EMAIL PROTECTED] On 15 Jul 2007, at 07:27, Martin Schreiber wrote: Can the fix for Mantis 9242 (Debugging broken on win32 with PII) be merged to fixes_2_2? Independent from this, I would encourage you to submit a bug report against gdb for win32. If they don't know this is broken, they can't fix it. Maybe it is fixed in new gdb 6.6. It can be downloaded from mingw site. Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] twide3.pp on windows
From: Jonas Maebe [EMAIL PROTECTED] On 16 Jul 2007, at 16:32, Vincent Snijders wrote: How is the twide3.pp test supposed to work? It assumes that the testsuite environment is configured to use utf8. I don't know how to make it encoding-independent, nor how to configure a Windows console session to always use utf8 (the testsuite scripts of the automated testsuite runs on Linux, Solaris and Mac OS X all explicitly set the LANG environment variable to ensure this). Our Windows RTL use current ansi code page to perform widestring-ansistring conversions. utf8 can not be used. Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] twide3.pp on windows
From: Daniël Mantione [EMAIL PROTECTED] Op Mon, 16 Jul 2007, schreef Yury Sidorov: The code page (locale) is set in Control Panel for whole user session (or whole system). It is not possible to set utf8 as locale. I know. How do you set it to a specific locale for the current application? widestring to ansistring conversion is performed using WideCharToMultiByte. Currently it is done using ANSI code page specified in Control Panel. There is no per application code page setting in Windows. We can create flag in System unit which control how widestring-ansistring should be performed to enable utf8 on Windows. No, you cannot (at least not with full functionality), since uppercasing and compare operations on UTF-8 ansistrings you need a Unicode library, which Windows does only provide in UTF-16 flavour. WideCharToMultiByte can convert from widestring to utf8 if corresponding flag is specified. This flag is available in Windows 98/Me, Windows NT 4.0 and later. MultiByteToWideChar do reverse conversion. This functions already used in System unit for Windows. Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] twide3.pp on windows
From: Daniël Mantione [EMAIL PROTECTED] Op Mon, 16 Jul 2007, schreef Yury Sidorov: There must be, because the CRT unit currently seems to do such vodoo (which is questionable behaviour by the way). Yes. It is possible to specify code pages for console, gui controls, etc. But application must do it in runtime. Perfect, this is what twide3 needs. It is not possible to change code page used for wideansi translation per applicaton. Oh, yes it will not work on Windows, because utf8 is not supported here. Then, twide3.pp should be skipped on Windows, since it is not possible to do it in locale independant way. Well, the test could be adapted to use some kind of code page. It could work on all platforms then. This test will work on Windows only if utf8 support will be added to Windows rtl. Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] how to compile RTL for ARM-Linux since r8006
From: Bernd Mueller [EMAIL PROTECTED] Hello, can anyone please tell me, how to compile the RTL for ARM-Linux since revision 8006? I tried to verify the bug fix 8967 (thank you Yury Sidorov) on my system, but I am not able to compile the RTL anymore. Adding the -Sg switch seems to be required to compile softfpu, but I get now: PPU Loading ..\..\rtl\units\arm-linux\dos.ppu Trying to use a unit which was compiled with a different FPU mode objects.pp(734,9) Fatal: Can't find unit dos used by Objects Fatal: Compilation aborted I would like to compile with softfloat disabled. So far, I used following make call: make CPU_TAGET=arm OS_TARGET=linux PP=ppcrossarm OPT=-Tlinux -CX -Sg Try to force hardware FPU mode by using -CfFPA switch. Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] how to compile RTL for ARM-Linux since r8006
From: Bernd Mueller [EMAIL PROTECTED] Marco van de Voort wrote: So far, I used following make call: make CPU_TAGET=arm OS_TARGET=linux PP=ppcrossarm OPT=-Tlinux -CX -Sg Try to force hardware FPU mode by using -CfFPA switch. no, it does not help. I get exactly the same error. Perhaps something changed in the build process for the cross compiler? I still use FPC 2.0.4 as starting compiler to build the cross compiler. I am building the cross compiler with following make call: make clean make PPC_TARGET=arm Did you also recompile the RTL with soft support? this compiles without errors. But I would like to get a hardfloat enabled RTL again. What host OS do you use? Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] win32 debugging broken in fixes_2_2?
From: Martin Schreiber [EMAIL PROTECTED] Hi, Every program compiled with fixes_2_2 rev. 8006 crashes in gdb: GNU gdb 6.6 Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i686-pc-mingw32... (gdb) run Starting program: G:\testcase\mse\console/console.exe Loaded symbols for C:\WINNT\system32\KERNEL32.DLL Loaded symbols for C:\WINNT\system32\OLEAUT32.DLL Loaded symbols for C:\WINNT\system32\OLE32.DLL Loaded symbols for C:\WINNT\system32\rpcrt4.dll Loaded symbols for C:\WINNT\system32\ADVAPI32.DLL Loaded symbols for C:\WINNT\system32\GDI32.DLL Loaded symbols for C:\WINNT\system32\USER32.DLL Program received signal SIGILL, Illegal instruction. 0x00402091 in SYSTEM_FPC_CPUCODEINIT () (gdb) bt #0 0x00402091 in SYSTEM_FPC_CPUCODEINIT () #1 0x0040a504 in SYSTEM_init () #2 0x00406114 in fpc_initializeunits () #3 0x7ffdf000 in ?? () #4 0x in ?? () (gdb) The programs work without gdb. System: win2000, PII. The problem seems not to exist on another PC with win2000 and an AMD Athlon. Any hints? If CPU have no SSE support an exception occurs, but it handled properly by program. If running under gdb, it catches this exception. Maybe other way to detect SSE support exists... Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] how to compile RTL for ARM-Linux since r8006
From: Bernd Mueller [EMAIL PROTECTED] this compiles without errors. But I would like to get a hardfloat enabled RTL again. What host OS do you use? I am using Windows 98SE for cross compiling. Where arm-linux cross binutils for win32 can be downloaded? Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] how to compile RTL for ARM-Linux since r8006
From: Bernd Mueller [EMAIL PROTECTED] Yury Sidorov wrote: From: Bernd Mueller [EMAIL PROTECTED] this compiles without errors. But I would like to get a hardfloat enabled RTL again. What host OS do you use? I am using Windows 98SE for cross compiling. Where arm-linux cross binutils for win32 can be downloaded? I lost the source ;-( but I am going to seek for the download location again. Shall I upload/mail (2.5 MB zipped) the binutils somewhere? I compiled binutils myself and yes, the problem is present. It does not happen when doing make cycle on real arm-linux box. I will fix this issue. Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LoadLibrary fails if called from a DLL
Hello,
How old is snapshot you are using?
Yury Sidorov.
- Original Message -
From: Mark - WBIsoft.COM
To: fpc-devel@lists.freepascal.org
Sent: Saturday, July 07, 2007 11:51 AM
Subject: [fpc-devel] LoadLibrary fails if called from a DLL
Hi,
I'm having a strange issue with the LoadLibrary call in the 64bit beta version
of the free pascal compiler (fpc 2.1.5 with lazarus 0.9.23 beta) - standard
install from the sourceforge download and installed in the default c:\lazarus
directory.
I have written a function in FPC that I have used in Delphi for many many years
with out problem. Ok, here's a simple piece of code
function myfunction(a, var b : dword) : boolean;
var dllh : cardinal;
fun : function (a : dword; var b : dword) : boolean; stdcall;
begin
result := false;
dllh := loadlibrary('c:\windows\system32\somelib.dll');
if dllh 0 then
begin
fun := nil;
fun := getprocaddress(dllh,'someproc');
if fun nil then result := fun(a,b);
end
else
result := false;
end;
Now here's my problem - very simply if I compile this into a standard console
application it works fine, however, if I compile it into the DLL I am planing
to run it in it fails - the loadlibrary call ALWAYS returns 0x7C37 which
appears to be a memory address rather than a handle - the result is that the
getprocaddress returns an invalid address and fails.
So, why is the loadlibrary call failing (or returning this memory address) when
in a DLL but NOT when it's in a console app.
Any help would be great, as I cannot seem to find an implementation of
GETLASTERROR to pass to SYSERRORMESSAGE to display any error from the OS if
there is one !
Thanks folks
Mark
Kind regards
Mark Cook
WBIsoft.COM
Any opinions expressed in this message are those of the individual and not
necessarily the company. This message and any files transmitted with it are
confidential and solely for the use of the intended recipient. If you are not
the intended recipient or the person responsible for delivering to the intended
recipient, be advised that you have received this message in error and that any
use is strictly prohibited.
This email was scanned for viruses when sent, however we advise you to carry
out your own virus check before opening any attachment(s) as we cannot accept
liability for any damage sustained as a result of any software viruses.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LoadLibrary fails if called from a DLL
Hi,
I fixed DLL related a few weeks ago. You need to get more fresh snapshot and
test it.
Yury.
- Original Message -
From: Mark - WBIsoft.COM
To: FPC developers' list
Sent: Sunday, July 08, 2007 7:59 PM
Subject: Re: [fpc-devel] LoadLibrary fails if called from a DLL
Hi Yury,
specifically the file was lazarus-0.9.23-fpc-2.1.5-20070531-win64.exe
Hope this helps ?
Mark
- Original Message -
From: Yury Sidorov
To: FPC developers' list
Sent: Sunday, July 08, 2007 5:28 PM
Subject: Re: [fpc-devel] LoadLibrary fails if called from a DLL
Hello,
How old is snapshot you are using?
Yury Sidorov.
- Original Message -
From: Mark - WBIsoft.COM
To: fpc-devel@lists.freepascal.org
Sent: Saturday, July 07, 2007 11:51 AM
Subject: [fpc-devel] LoadLibrary fails if called from a DLL
Hi,
I'm having a strange issue with the LoadLibrary call in the 64bit beta
version of the free pascal compiler (fpc 2.1.5 with lazarus 0.9.23 beta) -
standard install from the sourceforge download and installed in the default
c:\lazarus directory.
I have written a function in FPC that I have used in Delphi for many many
years with out problem. Ok, here's a simple piece of code
function myfunction(a, var b : dword) : boolean;
var dllh : cardinal;
fun : function (a : dword; var b : dword) : boolean; stdcall;
begin
result := false;
dllh := loadlibrary('c:\windows\system32\somelib.dll');
if dllh 0 then
begin
fun := nil;
fun := getprocaddress(dllh,'someproc');
if fun nil then result := fun(a,b);
end
else
result := false;
end;
Now here's my problem - very simply if I compile this into a standard console
application it works fine, however, if I compile it into the DLL I am planing
to run it in it fails - the loadlibrary call ALWAYS returns 0x7C37 which
appears to be a memory address rather than a handle - the result is that the
getprocaddress returns an invalid address and fails.
So, why is the loadlibrary call failing (or returning this memory address)
when in a DLL but NOT when it's in a console app.
Any help would be great, as I cannot seem to find an implementation of
GETLASTERROR to pass to SYSERRORMESSAGE to display any error from the OS if
there is one !
Thanks folks
Mark
Kind regards
Mark Cook
WBIsoft.COM
Any opinions expressed in this message are those of the individual and not
necessarily the company. This message and any files transmitted with it are
confidential and solely for the use of the intended recipient. If you are not
the intended recipient or the person responsible for delivering to the intended
recipient, be advised that you have received this message in error and that any
use is strictly prohibited.
This email was scanned for viruses when sent, however we advise you to carry
out your own virus check before opening any attachment(s) as we cannot accept
liability for any damage sustained as a result of any software viruses.
--
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
--
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.476 / Virus Database: 269.10.2/890 - Release Date: 07/07/2007
15:26
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LoadLibrary fails if called from a DLL
Go to sources folder and execute:
make distclean
make all
make install SNAPSHOT=1 INSTALL_PREFIX=C:/some_folder
Yury.
- Original Message -
From: Mark - WBIsoft.COM
To: FPC developers' list
Sent: Sunday, July 08, 2007 8:15 PM
Subject: Re: [fpc-devel] LoadLibrary fails if called from a DLL
THanks, one final (i hope) question
I assume I need to grab the entire folder and recompile it - if so I assume I
can compile with FPC itself
Mark
- Original Message -
From: Yury Sidorov
To: FPC developers' list
Sent: Sunday, July 08, 2007 6:12 PM
Subject: Re: [fpc-devel] LoadLibrary fails if called from a DLL
Get sources from svn using this path:
http://svn.freepascal.org/svn/fpc/branches/fixes_2_2
I dont know where snapshots can be found.
Yury.
- Original Message -
From: Mark - WBIsoft.COM
To: FPC developers' list
Sent: Sunday, July 08, 2007 8:06 PM
Subject: Re: [fpc-devel] LoadLibrary fails if called from a DLL
Thanks,
can you suggest the best way (ie. the correct url) for me to run with the
svn.exe command to get the latest snapshot as I'm unsure where the x86_64 stuff
is - esp as it would appear to have vanished from the sourceforge page ?
What's the current x86_64 snapshot version ?
Thanks
Mark
- Original Message -
From: Yury Sidorov
To: FPC developers' list
Sent: Sunday, July 08, 2007 6:05 PM
Subject: Re: [fpc-devel] LoadLibrary fails if called from a DLL
Hi,
I fixed DLL related a few weeks ago. You need to get more fresh snapshot
and test it.
Yury.
- Original Message -
From: Mark - WBIsoft.COM
To: FPC developers' list
Sent: Sunday, July 08, 2007 7:59 PM
Subject: Re: [fpc-devel] LoadLibrary fails if called from a DLL
Hi Yury,
specifically the file was lazarus-0.9.23-fpc-2.1.5-20070531-win64.exe
Hope this helps ?
Mark
- Original Message -
From: Yury Sidorov
To: FPC developers' list
Sent: Sunday, July 08, 2007 5:28 PM
Subject: Re: [fpc-devel] LoadLibrary fails if called from a DLL
Hello,
How old is snapshot you are using?
Yury Sidorov.
- Original Message -
From: Mark - WBIsoft.COM
To: fpc-devel@lists.freepascal.org
Sent: Saturday, July 07, 2007 11:51 AM
Subject: [fpc-devel] LoadLibrary fails if called from a DLL
Hi,
I'm having a strange issue with the LoadLibrary call in the 64bit beta
version of the free pascal compiler (fpc 2.1.5 with lazarus 0.9.23 beta) -
standard install from the sourceforge download and installed in the default
c:\lazarus directory.
I have written a function in FPC that I have used in Delphi for many many
years with out problem. Ok, here's a simple piece of code
function myfunction(a, var b : dword) : boolean;
var dllh : cardinal;
fun : function (a : dword; var b : dword) : boolean; stdcall;
begin
result := false;
dllh := loadlibrary('c:\windows\system32\somelib.dll');
if dllh 0 then
begin
fun := nil;
fun := getprocaddress(dllh,'someproc');
if fun nil then result := fun(a,b);
end
else
result := false;
end;
Now here's my problem - very simply if I compile this into a standard
console application it works fine, however, if I compile it into the DLL I am
planing to run it in it fails - the loadlibrary call ALWAYS returns 0x7C37
which appears to be a memory address rather than a handle - the result is that
the getprocaddress returns an invalid address and fails.
So, why is the loadlibrary call failing (or returning this memory
address) when in a DLL but NOT when it's in a console app.
Any help would be great, as I cannot seem to find an implementation of
GETLASTERROR to pass to SYSERRORMESSAGE to display any error from the OS if
there is one !
Thanks folks
Mark
Kind regards
Mark Cook
WBIsoft.COM
Any opinions expressed in this message are those of the individual and
not necessarily the company. This message and any files transmitted with it are
confidential and solely for the use of the intended recipient. If you are not
the intended recipient or the person responsible for delivering to the intended
recipient, be advised that you have received this message in error and that any
use is strictly prohibited.
This email was scanned for viruses when sent, however we advise you to
carry out your own virus check before opening any attachment(s) as we cannot
accept liability for any damage sustained as a result of any software viruses.
--
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http
Re: [fpc-devel] Errors linking Symbian OS applications
From: Felipe Monteiro de Carvalho [EMAIL PROTECTED] Hi, I am compiling a symbian os application for the first time since 1 month or so, and now the linking stage fails with: mwldsym2.exe: Undefined symbol: '__data_start__' mwldsym2.exe: referenced from '.text' in system.o mwldsym2.exe: referenced from '.text' in system.o mwldsym2.exe: referenced from '.text' in system.o mwldsym2.exe: referenced from '.text' in system.o mwldsym2.exe: Undefined symbol: '__data_end__' mwldsym2.exe: referenced from '.text' in system.o mwldsym2.exe: referenced from '.text' in system.o mwldsym2.exe: referenced from '.text' in system.o mwldsym2.exe: referenced from '.text' in system.o It worked fine before. Remove tf_winlikewidestring flag for symbian. Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Erroneous finalizing of const widestring array
From: Martin Schreiber [EMAIL PROTECTED] On Saturday 30 June 2007 14.46, Yury Sidorov wrote: Martin, please inform us when FPC 2.1.5 will work as expected with your code and no more bugs will be left. After that 2.2 release can be launched. I worked now one hour with MSEide compiled with win32 FPC fixes_2_2 rev. 7933, no more problems found up to now. :-) Thanks a lot! That's great. I hope no major bugs will be found after 2.2 release :) Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.2 - Delphi 7
From: Martin Schreiber [EMAIL PROTECTED] Comparison FPC 2.2 - Delphi 7. MSEide aps\ide\mseide.pas without database support: Compile time FPC: 17.9s Delphi: 1.28s Exe size FPC: 2.27MB Delphi: 1.87MB Commandline FPC: \fpc\svn\fixes_2_2\compiler\ppc386.exe -O2 -CX -XX -Xs -B -Fi..\.. -XX and -CX are useless on Win32. Internal linker always do smartlinking and external linker does not do it. Try to pass -g- option to see if compile time will be reduced. Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Erroneous finalizing of const widestring array
From: Joao Morais [EMAIL PROTECTED] Yury Sidorov wrote: That's great. I hope no major bugs will be found after 2.2 release :) Provided that you don't use class method reference and optimization :-( What bug report do you mean? Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.2 - Delphi 7
From: Micha Nelissen [EMAIL PROTECTED] Jonas Maebe wrote: The main reduction in compile time would probably come from using -O-1 -Ooregvar instead of -O2. I don't think the resulting code will be much slower either in most cases. No, the main reduction is not outputting anything to console: from 18.5 sec to 15.9 sec vs. 18.5 sec to 17.5 sec. I used 'compile-fpc | grep compiled'. Where compile-fpc is a batch file. I think it is because you run compilation for the second time and files were in cache. Here mu number for the second run without deletion of compiled unit files (to ensure that source files are cached): FPC with -O2: 14.7s; FPC with -O-: 11.4s; D7:1.6s. Results are sad :( It is a good reason to find out why FPC is so slow even without optimizations. Linking time is less then 1s, so it is not slow. Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] using gorc on win64 as resource compiler
From: [EMAIL PROTECTED]
- Original Message -
From: Yury Sidorov [EMAIL PROTECTED]
Date: Monday, July 2, 2007 1:00 pm
Subject: Re: [fpc-devel] using gorc on win64 as resource compiler
From: [EMAIL PROTECTED]
Hi,
Thanks for fixing the coff loading on win64.
Attached patch enables the use of gorc on win64 in the compiler:
adding {$R lazarus.rc} includes this resource into the Lazarus
executable, giving it a main icon and a XP look.
Applied. Thanks.
Can the GoRC executable be added to the fpcbuild repository?
It is ok to me, but what other core developers think?
Yury.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Erroneous finalizing of const widestring array
From: Yury Sidorov [EMAIL PROTECTED] From: Martin Schreiber [EMAIL PROTECTED] Possible show stopper for FPC 2.2: http://www.freepascal.org/mantis/view.php?id=9170 I suspect there are more problems, I can only debug one by one. Fixed and merged to fixes. Martin, please inform us when FPC 2.1.5 will work as expected with your code and no more bugs will be left. After that 2.2 release can be launched. Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Erroneous finalizing of const widestring array
From: Martin Schreiber [EMAIL PROTECTED] Here is the next one (win32 widestring copy error): http://www.freepascal.org/mantis/view.php?id=9187 Thanks for the fast reaction :-) Fixed and merged to 2.2 branch. Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] DLL function exits without exception or other notice
From: Felipe Monteiro de Carvalho [EMAIL PROTECTED] I have a code on a Dll which when executed causes the funtion to simply exit without raising an exception or anything. It just exits without notice, and also quits from the function that called it, like if it was an Exception, except that a try...except...end block doesn't catch anything. Here is the code layout bellow. The first message box is shown, but the second is never shown: Try to copy this function to main .exe and test it. Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] linking resources on win64
From: Jonas Maebe [EMAIL PROTECTED]
On 29 jun 2007, at 11:12, [EMAIL PROTECTED] wrote:
Then I added this line to my program:
{$LINK lazarus.obj}
I got this error message
C:\lazarus\source\lazarus\ide\lazarus.pp(119,1) Error: Error
reading COFF Symtable while reading lazarus.obj
Isn't this because we don't support the Microsoft .obj format? (the
same reason why we can't link other .obj files)
MS COFF .obj files are supported for win32 and wince. But it was not
tested for win64...
Vincent, please create bug report so it will be fixed in future.
Yury.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Freepascal made chm compiler test file
From: Michael Van Canneyt [EMAIL PROTECTED] On Wed, 27 Jun 2007, Micha Nelissen wrote: Andrew Haines wrote: Hi, I've been working on a chm compiler that uses no external libs so it Please let me know if this file works for you. It doesn't seem to work for me: I get 'Action canceled' error in Internet Explorer. I get the same error in Windows 2000, IE 5. I got 'Action canceled' until I open file properites and unblock it. After that it opened as expected. WinXP/SP2. It will be better to put .chm into archive to prevent Windows from adding block to it. Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Freepascal made chm compiler test file
From: Micha Nelissen [EMAIL PROTECTED] Yury Sidorov wrote: I got 'Action canceled' until I open file properites and unblock it. After that it opened as expected. WinXP/SP2. I can't find it: where is the unblock property ? I have this at the bottom of the first page of file properties. Under file attributes. When file is not blocked there is empty area in this place. The file is blocked by Outlook Express when attachment is saved. If you are using other e-mail client the file will not be blocked. Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Freepascal made chm compiler test file
From: Micha Nelissen [EMAIL PROTECTED] Yury Sidorov wrote: I have this at the bottom of the first page of file properties. Under file attributes. When file is not blocked there is empty area in this place. Hmm the area is empty there, but it gave me an idea. I copied the file to C:\, and then it *did* work. I had it on a network drive at first. What kind of security is that ?!? It is well known issue. How to fix it: http://www.helpscribble.com/chmnetwork.html Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Help: Converting Header for WinCE
From: Carolos Foscolos [EMAIL PROTECTED] I converted windbase.h from ms wince sdk, and would like to include it to rtl for wince in fpc... Are the comments copyright ms, so do I remove them or leave them? And who can I talk to, to include my windbase.pp to rtl\wince\ Also some of the functions of windbase.h are in coredll.inc so do I split the windbase.pp file and add its data types to struct.inc and functions to coredll.inc Please add add missing functions/declarations to existing .inc files and send me a patch. Yury Sidorov. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] multiply resource files bug (commit 7515)
From: Vincent Snijders [EMAIL PROTECTED] Vincent Snijders schreef: Yury Sidorov schreef: From: Michael Van Canneyt [EMAIL PROTECTED] On Wed, 30 May 2007, Yury Sidorov wrote: From: Павел Ишенин [EMAIL PROTECTED] Hello, FPC developers' list I've noticed today that Yury resolved old and extremly bad for lazarus bug with multiply resource files. And now it is possible to use more than one res in application. I dont know magic words, but maybe it is possible to merge this fix into future 2.2 version? This help us to solve some problems in lazarus (xp manifest injection, using res instead of lrs). I would like to see this fix in 2.2 as well. What other core developers think about it? The answer is the same as for Graeme's request to merge some fpcunit fixes: Normally not, and since it's a rather big change which can have some as yet unknown side-effects, I'd say this one is even less likely. I dont surprised with the answer :) The bugfix is really changes a lot of code. Let's wait for 2.2.2. Yury. I might have encountered one of the side-effects. I compiled Lazarus with some components (rxnew for example), and windres used 470 MB Virtual memory in the task manager. After a while I got this message: Compiling resource ..\units\i386-win32\fpc-res.res D:\FPC\2.0.2\bin\i386-Win32\windres.exe: D:\FPC\2.0.2\bin\i386-Win32\windres.exe : ..\units\i386-win32\fpc-res.res: unexpected end of file Error: Error while linking Update: using windres from fpcbuild\trunk\install\binw32 I have no such problem. It may be windres bug or some of collected .res files is not fully correct... What version each windres have? Can you send me this fpc-res.res file? Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] multiply resource files bug (commit 7515)
From: Vincent Snijders [EMAIL PROTECTED] I compiled Lazarus with some components (rxnew for example), and windres used 470 MB Virtual memory in the task manager. After a while I got this message: Compiling resource ..\units\i386-win32\fpc-res.res D:\FPC\2.0.2\bin\i386-Win32\windres.exe: D:\FPC\2.0.2\bin\i386-Win32\windres.exe : ..\units\i386-win32\fpc-res.res: unexpected end of file Error: Error while linking Update: using windres from fpcbuild\trunk\install\binw32 I have no such problem. It may be windres bug or some of collected .res files is not fully correct... What version each windres have? Can you send me this fpc-res.res file? Working version (from fpc 2.3.1): GNU windres 2.16.91 20050827 Copyright 2005 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. Not working version (from fpc 2.0.2): GNU windres 2.9.5 Copyright 1997, 1998, 1999 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. Attached is the used fpc-res.res file. Looking at the version, I think windres is just too old. I never had fpc 2.0.4 installed on this computer, so I am still using the binutils from fpc 2.0.2. Yes. I found that windres 2.9.5 is buggy. It compiles .rc files not 100% properly and this causes crash if several .res files are merged together. windres 2.16.91 should be used. You need to update your binutils. Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
