Re: [fpc-pascal] is it safe to use v.2.2.1 for production use?
Op Thu, 8 Nov 2007, schreef Bee: > Hi all, > > I know latest stable release of fpc is v.2.2.0. But the latest updates and bug > fixes are done on v.2.2.1. I found some serious updates and bug fixes are > already done on v.2.2.1. But, is it safe to use v.2.2.1 for production use? Or > should I stick with v.2.2.0 for production use? Generally 2.2.1 is reliable, but bugfixes can have unforseen effects. You will have to weigh the advantage of the bugfixes against unforseen effects by those fixes. We cannot make that choice for you. Daniël___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] is it safe to use v.2.2.1 for production use?
Generally 2.2.1 is reliable, but bugfixes can have unforseen effects. You will have to weigh the advantage of the bugfixes against unforseen effects by those fixes. We cannot make that choice for you. Understood. Say I'd like to apply some updates/fixes (into my v.2.2.0 installation) but reject some other updates/fixes, then what should I do? SVN seems to get ALL updates/fixes. -Bee- has Bee.ography at: http://beeography.wordpress.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] What about to support of automation technologies (UNO, COM) ?
Am Donnerstag, den 08.11.2007, 12:11 +0300 schrieb Andrey Gusev: > * Marc Santhoff <[EMAIL PROTECTED]> [Thu, 08 Nov 2007 05:47:06 > +0100]: > > But what about the other ones? > > I cannot get even the clean comprehension - may fpc operate automated > interfaces or not (in delphi style or somehow yet, fully or partially) ? > FPC 2.2 reference, pg.40: "Remark: Dispatch interface support for > variants is currently broken in the compiler." > I cannot compile sources both Delphi-UNO and OOSDK-InstertTables - > compiler sayed that he cannot process variants calls. > But Florian Klaempfl say "Using the delphi units coming with the OO SDK > I was able to create documents with OO"! I really don't know for sure. The last time I used Windows-specific OLE stuff has been years ago. I remember using the programs from the SDK somewhen in the past and they did work - that doesn't tell anything about todays fpc. But all this OLE Automation stuff is windows only. For being cross platform you have to use a bridge between the compiler in use and the office software. This bridge is compiler specific, each compiler has to have it's own. The one from sourceforge currently does not work with fpc, and asking for "the other ones" was a reply to Marco writing: > There appear to be several bridges. I tried Clootie's one. It is a mess, and > I didn't even succeed to use it in Delphi without packages. So there seem to be other bridges that I don't know but would like to. Thats why I asked for the links pointing to these other bridge implementations. HTH, Marc ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] is it safe to use v.2.2.1 for production use?
Hi all, I know latest stable release of fpc is v.2.2.0. But the latest updates and bug fixes are done on v.2.2.1. I found some serious updates and bug fixes are already done on v.2.2.1. But, is it safe to use v.2.2.1 for production use? Or should I stick with v.2.2.0 for production use? I know I shouldn't use new development release (v.2.3.1) for production use since it contains new features that perhaps still not fully tested or buggy. TIA. -Bee- has Bee.ography at: http://beeography.wordpress.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] What about to support of automation technologies (UNO, COM) ?
* Marc Santhoff <[EMAIL PROTECTED]> [Thu, 08 Nov 2007 11:37:11 +0100]: But all this OLE Automation stuff is windows only. For being cross platform you have to use a bridge between the compiler in use and the office software. I remember of it. Thetefore i have thus obstination regarding to UNO. So there seem to be other bridges that I don't know but would like to. Thats why I asked for the links pointing to these other bridge implementations. Scarcely that i have know more about such bridges than You. But, i intend to solve this problem (Pascal_ReportGenerator -> OpenOffice coupling), however without elaboration of fpc, or with available facilities only, it will have a time. OpenSource and cross-platform solution both need to me. Way with ODF/XML still actual - in perl it works acceptable. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpnanosleep (again)
If you know the Processor Speed (MHz) then there is an assembler command which reads the cpu cycles (for example a 1MHz Processor has 1.000.000 cycles/second) so you can do it in this way. http://en.wikipedia.org/wiki/RDTSC Rainer Am Mittwoch, 7. November 2007 23:27 schrieb John Coppens: > Hi all. > > I need a small delay in my program, which bitbangs an i2c interface > connected to the parallel port. This is mainly for educational purposes, > so please don't question the wiseness of this decision. > > Is there any simple way (short of writing a kernel module) of delaying > less than the HZ value? Weirdly, fpNanosleep seems to delay 8.3 ms > minimally (weird, 'cause that's less than the HZ value). > > I'm using a 2.6 kernel. > > John > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] PCRE
On 08 Nov 2007, at 00:16, L wrote: Because of the ridiculous GPL license which freepascal uses, which isn't as free as a BSD/NRCOL/MIT license. Please take your license flaming elsewhere, it is completely off topic on this list. Jonas FPC lists moderator ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] What about to support of automation technologies (UNO, COM) ?
* Marc Santhoff <[EMAIL PROTECTED]> [Thu, 08 Nov 2007 05:47:06 +0100]: But what about the other ones? I cannot get even the clean comprehension - may fpc operate automated interfaces or not (in delphi style or somehow yet, fully or partially) ? FPC 2.2 reference, pg.40: "Remark: Dispatch interface support for variants is currently broken in the compiler." I cannot compile sources both Delphi-UNO and OOSDK-InstertTables - compiler sayed that he cannot process variants calls. But Florian Klaempfl say "Using the delphi units coming with the OO SDK I was able to create documents with OO"! I make direct post to Florian Klaempfl - he keep silence. It seems nobody to know anything definitely about automation and Variants. What left to me ? - examination (with microscope) of the fpc sources ? My way to make whatever (with programming at least) is the comprehension at first, and the actions at next. But get the clean comprehension is heavy when people keep secret somewhat important from you... Or, may be, it is honour of poineer occured to me ?... I will try somewhat yet (i.e. "another ones"), if i will know somewhat wort then i will (of course) give that to community. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ppcrossarm 220
Carsten Bager schrieb:
> I have built a Win32 ppcrossarm.exe (2.20) compiler. The compiler works
> ok. The output from the Linux and the Win32 compiler when I use the -sh
> directive is exactly the same. The downside is I have some problems
> finding a Win32 linker that I can use.
>
> If I compile a Hallow World program, it works ok, but when I try to compile a
> program that uses uLibc, the Win32 linker and the Linux linker dos not do
> exactly the same.
>
> When I run the output from the Win32 linker on my arm platform it stops
> with
> Segmentation fault
Did you load it in GDB? Where does it exactly crash?
> The output from the Linux linker runs ok
>
> If I look in the map file the only difference I can see is (see at the end of
> this mail)
>
> Linux: 0x80d4. = (0x8000 + SIZEOF_HEADERS)
> Win32: 0x8000. = 0x8000
>
> I have several versions of Win32 linkers (215,216,217) and Linux linkers
> (215,216,217,218). I have also seen this problem with a Linux linker (217)
>
> One of the Win32 linkers I have used if from
> ftp://ftp.freepascal.org/pub/fpc/contrib/cross/mingw/binutils-2.15.94-win32-
> arm-linux.zip
I guess it is linker script related. Unfortunatly FPC comes with an
integrated linker script however it seems there is no generic one.
Try to compare the various linker scripts to narrow it down. From ld you
get it with
ld --verbose
>From FPC you get it when compiling with -s:
it's the SECTIONS { ... }part of the resulting link.res
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] What about to support of automation technologies (UNO, COM) ?
* Andrey Gusev <[EMAIL PROTECTED]> [Thu, 08 Nov 2007 12:11:44 +0300]: I make direct post to Florian Klaempfl - he keep silence. It seems Correction: meanwhile i write the previous post - i get post from Florian... ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ppcrossarm 220
> I guess it is linker script related. Unfortunatly FPC comes with an
> integrated linker script however it seems there is no generic one.
>
> Try to compare the various linker scripts to narrow it down. From ld you
> get it with
> ld --verbose
> From FPC you get it when compiling with -s:
> it's the SECTIONS { ... }part of the resulting link.res
The scripts (.res files) produced by the Linux compiler and the win32 compiler
are 100% the
same.
The output form the 2 linkers are deferent but what it means ??
Again the first thing that is different is the line
Linux PROVIDE (__executable_start = 0x8000); . =0x8000+SIZEOF_HEADERS;
Win32 PROVIDE (__executable_start = 0x8000); . = 0x8000;
My conclusion is, the problem is the win32 linker, but is there a way I can get
it to behave
like the Linux linker.
Regards
Carsten
--- The Win32 Linker
---
GNU ld version 2.16.91 20060320
Supported emulations:
armelf
using internal linker script:
==
/* Script for -z combreloc: combine and sort reloc sections */
OUTPUT_FORMAT("elf32-littlearm", "elf32-bigarm",
"elf32-littlearm")
OUTPUT_ARCH(arm)
ENTRY(_start)
SEARCH_DIR("/c/gcc-build/install/arm-unknown-elf/lib");
SECTIONS
{
/* Read-only sections, merged into text segment: */
PROVIDE (__executable_start = 0x8000); . = 0x8000;
.interp : { *(.interp) }
.hash : { *(.hash) }
.dynsym : { *(.dynsym) }
.dynstr : { *(.dynstr) }
.gnu.version: { *(.gnu.version) }
.gnu.version_d : { *(.gnu.version_d) }
.gnu.version_r : { *(.gnu.version_r) }
.rel.dyn:
{
*(.rel.init)
*(.rel.text .rel.text.* .rel.gnu.linkonce.t.*)
*(.rel.fini)
*(.rel.rodata .rel.rodata.* .rel.gnu.linkonce.r.*)
*(.rel.data.rel.ro* .rel.gnu.linkonce.d.rel.ro.*)
*(.rel.data .rel.data.* .rel.gnu.linkonce.d.*)
*(.rel.tdata .rel.tdata.* .rel.gnu.linkonce.td.*)
*(.rel.tbss .rel.tbss.* .rel.gnu.linkonce.tb.*)
*(.rel.ctors)
*(.rel.dtors)
*(.rel.got)
*(.rel.bss .rel.bss.* .rel.gnu.linkonce.b.*)
}
.rela.dyn :
{
*(.rela.init)
*(.rela.text .rela.text.* .rela.gnu.linkonce.t.*)
*(.rela.fini)
*(.rela.rodata .rela.rodata.* .rela.gnu.linkonce.r.*)
*(.rela.data .rela.data.* .rela.gnu.linkonce.d.*)
*(.rela.tdata .rela.tdata.* .rela.gnu.linkonce.td.*)
*(.rela.tbss .rela.tbss.* .rela.gnu.linkonce.tb.*)
*(.rela.ctors)
*(.rela.dtors)
*(.rela.got)
*(.rela.bss .rela.bss.* .rela.gnu.linkonce.b.*)
}
.rel.plt: { *(.rel.plt) }
.rela.plt : { *(.rela.plt) }
.init :
{
KEEP (*(.init))
} =0
.plt: { *(.plt) }
.text :
{
*(.text .stub .text.* .gnu.linkonce.t.*)
KEEP (*(.text.*personality*))
/* .gnu.warning sections are handled specially by elf32.em. */
*(.gnu.warning)
*(.glue_7t) *(.glue_7)
} =0
.fini :
{
KEEP (*(.fini))
} =0
PROVIDE (__etext = .);
PROVIDE (_etext = .);
PROVIDE (etext = .);
.rodata : { *(.rodata .rodata.* .gnu.linkonce.r.*) }
.rodata1: { *(.rodata1) }
.ARM.extab : { *(.ARM.extab* .gnu.linkonce.armextab.*) }
__exidx_start = .;
.ARM.exidx : { *(.ARM.exidx* .gnu.linkonce.armexidx.*) }
__exidx_end = .;
.eh_frame_hdr : { *(.eh_frame_hdr) }
.eh_frame : ONLY_IF_RO { KEEP (*(.eh_frame)) }
.gcc_except_table : ONLY_IF_RO { *(.gcc_except_table .gcc_except_table.*) }
/* Adjust the address for the data segment. We want to adjust up to
the same address within the page on the next page up. */
. = ALIGN(256) + (. & (256 - 1));
/* Exception handling */
.eh_frame : ONLY_IF_RW { KEEP (*(.eh_frame)) }
.gcc_except_table : ONLY_IF_RW { *(.gcc_except_table .gcc_except_table.*) }
/* Thread Local Storage sections */
.tdata : { *(.tdata .tdata.* .gnu.linkonce.td.*) }
.tbss : { *(.tbss .tbss.* .gnu.linkonce.tb.*) *(.tcommon) }
.preinit_array :
{
PROVIDE_HIDDEN (__preinit_array_start = .);
KEEP (*(.preinit_array))
PROVIDE_HIDDEN (__preinit_array_end = .);
}
.init_array :
{
PROVIDE_HIDDEN (__init_array_start = .);
KEEP (*(SORT(.init_array.*)))
KEEP (*(.init_array))
PROVIDE_HIDDEN (__init_array_end = .);
}
.fini_array :
{
PROVIDE_HIDDEN (__fini_array_start = .);
KEEP (*(.fini_array))
KEEP (*(SORT(.fini_array.*)))
PROVIDE_HIDDEN (__fini_array_end = .);
}
.ctors :
{
/* gcc uses crtbegin.o to find the start of
the constructors, so we make sure it is
first. Because this is a wildcard, it
doesn't matter if the user does not
actually link against crtbegin.o; the
linker won't look for a file to match a
wildcard. The wildcard also means that it
do
Re: [fpc-pascal] ppcrossarm 220
Carsten Bager schrieb: > I have built a Win32 ppcrossarm.exe (2.20) compiler. The compiler works > ok. The output from the Linux and the Win32 compiler when I use the -sh > directive is exactly the same. The downside is I have some problems > finding a Win32 linker that I can use. > > If I compile a Hallow World program, it works ok, but when I try to compile a > program that uses uLibc, the Win32 linker and the Linux linker dos not do > exactly the same. > > When I run the output from the Win32 linker on my arm platform it stops > with > Segmentation fault > The output from the Linux linker runs ok > > If I look in the map file the only difference I can see is (see at the end of > this mail) > > Linux: 0x80d4. = (0x8000 + SIZEOF_HEADERS) > Win32: 0x8000. = 0x8000 > > I have several versions of Win32 linkers (215,216,217) and Linux linkers > (215,216,217,218). I have also seen this problem with a Linux linker (217) > > One of the Win32 linkers I have used if from > ftp://ftp.freepascal.org/pub/fpc/contrib/cross/mingw/binutils-2.15.94-win32- > arm-linux.zip > > Has anyone got a hint where to go from here. - try to compare FPC's linker script with one of a working ld - try to find differences using objdump > > Regards > > Carsten > > > > > -- Linux > - > 0x0001PROVIDE (__executable_start, > 0x1) > 0x00010100. = 0x10100 > 0x8000PROVIDE (__executable_start, 0x8000) > 0x80d4. = (0x8000 + SIZEOF_HEADERS) > > .interp 0x80d4 0x13 > *(.interp) > .interp0x80d4 0x13 /Fpc/Lib/Ulibc/Arm/cprt0.o > *(.interp) > > .hash 0x80e8 0x94 > *(.hash) > .hash 0x80e8 0x94 /Fpc/Lib/Ulibc/Arm/cprt0.o > *(.hash) > > .dynsym 0x817c 0x120 > *(.dynsym) > .dynsym0x817c 0x120 /Fpc/Lib/Ulibc/Arm/cprt0.o > *(.dynsym) > > .dynstr 0x829c 0xc4 > *(.dynstr) > .dynstr0x829c 0xc4 /Fpc/Lib/Ulibc/Arm/cprt0.o > *(.dynstr) > > .gnu.version > *(.gnu.version) > *(.gnu.version) > > .gnu.version_d > *(.gnu.version_d) > *(.gnu.version_d) > > .gnu.version_r > *(.gnu.version_r) > *(.gnu.version_r) > > .rel.dyn0x8360 0x18 > *(.rel.init) > *(.rel.text .rel.text.* .rel.gnu.linkonce.t.*) > *(.rel.fini) > *(.rel.rodata .rel.rodata.* .rel.gnu.linkonce.r.*) > *(.rel.data.rel.ro*) > *(.rel.data .rel.data.* .rel.gnu.linkonce.d.*) > *(.rel.tdata .rel.tdata.* .rel.gnu.linkonce.td.*) > *(.rel.tbss .rel.tbss.* .rel.gnu.linkonce.tb.*) > *(.rel.ctors) > *(.rel.dtors) > *(.rel.got) > .rel.got 0x8360 0x18 /Fpc/Lib/Ulibc/Arm/cprt0.o > *(.rel.bss .rel.bss.* .rel.gnu.linkonce.b.*) > *(.rel.init) > *(.rel.text .rel.text.* .rel.gnu.linkonce.t.*) > > -- Win32 > -- > 0x0001PROVIDE (__executable_start, > 0x1) > 0x00010100. = 0x10100 > 0x8000PROVIDE (__executable_start, 0x8000) > 0x8000. = 0x8000 > > .interp 0x8000 0x13 > *(.interp) > .interp0x8000 0x13 J:\Fpc\Lib\Ulibc\Arm\cprt0.o > *(.interp) > > .hash 0x8014 0x90 > *(.hash) > .hash 0x8014 0x90 J:\Fpc\Lib\Ulibc\Arm\cprt0.o > *(.hash) > > .dynsym 0x80a4 0x110 > *(.dynsym) > .dynsym0x80a4 0x110 J:\Fpc\Lib\Ulibc\Arm\cprt0.o > *(.dynsym) > > .dynstr 0x81b4 0xbb > *(.dynstr) > .dynstr0x81b4 0xbb J:\Fpc\Lib\Ulibc\Arm\cprt0.o > *(.dynstr) > > .gnu.version0x82700x0 > *(.gnu.version) > *(.gnu.version) > > .gnu.version_d 0x82700x0 > *(.gnu.version_d) > *(.gnu.version_d) > > .gnu.version_r 0x82700x0 > *(.gnu.version_r) > *(.gnu.version_r) > > .rel.dyn0x8270 0x18 > *(.rel.init) > *(.rel.text .rel.text.* .rel.gnu.linkonce.t.*) > *(.rel.fini) > *(.rel.rodata .rel.rodata.* .rel.gnu.linkonce.r.*) > *(.rel.data.rel.ro* .rel.gnu.linkonce.d.rel.ro.*) > *(.rel.data .rel.data.* .rel.gnu.linkonce.d.*) > *(.rel.tdata .rel.tdata.* .rel.gnu.linkonce.td.*) > *(.rel.tbss .rel.tbss.* .rel.gnu.linkonce.tb.*) > *(.rel.ctors) > *(.rel.dtors) > *(.rel.got) > .rel.got 0x8270 0x18 J:\Fpc\Lib\Ulibc\Arm\cprt0.o > *(.rel.bss .rel.bss.* .rel.gnu.linkonce.b.*) > *(.rel.init) > *(.rel.text .rel.text.* .rel.gnu.linkonce.t.*) > > > > > > > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/
Re: [fpc-pascal] fpnanosleep (again)
On Thu, 8 Nov 2007 13:43:48 +0100 Rainer Stratmann <[EMAIL PROTECTED]> wrote: > http://en.wikipedia.org/wiki/RDTSC Interesting... I'm guessing gettimeofday would use this register to obtain the hi-res time it provides - does it? Thanks John ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] is it safe to use v.2.2.1 for production use?
Op Thu, 8 Nov 2007, schreef Bee: > > Generally 2.2.1 is reliable, but bugfixes can have unforseen effects. You > > will have to weigh the advantage of the bugfixes against unforseen > > effects by those fixes. We cannot make that choice for you. > > Understood. Say I'd like to apply some updates/fixes (into my v.2.2.0 > installation) but reject some other updates/fixes, then what should I do? SVN > seems to get ALL updates/fixes. The only solution then is of course to compile your own FPC. You can retrieve any patch from svn and apply it to 2.2.0 or remove it from current 2.2.1. Daniël___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpnanosleep (again)
John Coppens wrote: > Just an extra note: delay(1) seems to delay 4.1 ms, so it _does_ seem to > be possible to do less than 8.3? You wait till the next tick that is after the requested delay. So it's never a HZ multiple or so. Micha ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] errno codes fpOpen
Hi,
I'm maybe lost in the doc searches, but is there a reference explaining the
extended err codes for fpOpen and friends?
I could not find one.
The effort is a Linux/Pentium fifo read by cgi but fails to read a piped
fifo built with RW permission / shared.
cgi:
Program pipe_read;
uses BaseUnix,Unix;
var FD: Cint;
s:string[255];
begin
writeln ('Content-type: text/html');
writeln;
FD:=fpOpen ('/tmp/BlaBla,O_RdOnly or O_NonBlock);
writeln ('start...');
if FD>=0 then
begin
fpread(FD,s,255);
writeln(s);
end
else
Writeln ('Error : ',fpgeterrno);
Writeln ('The script exited with status : ',fpClose (FD));
writeln ('done');
end.
Results...
FpMkfifo : -1<- setup fifo pipe,ok
start...3(handle to pipe)
PID > 0<-server returned
The script exited with status : 0
Thanks,
Mike
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
