Starting with rel 1.0.2 in each case... 2 diffferent errors...

1 (make.zip) using maximal optimisation (see log), internal error... some sort of opt problem?!

2 something wrong with win32 smartlinking...

--Mon 16/10/00 18:30:09 target o/s = win32 snap params mwn new --initial compiler c:\pp1\bin\ppc386, 12/10/00, 13:34 --latest sources used 16/10/00 02:05
--dos, 4dos, dpmi versions 7.10, 6.01 0.90
--make string used ... make OPT="-Xs" RELEASE=1 OS_TARGET=win32 cycle c:/pp/bin/make.exe clean
make.exe[1]: Entering directory `d:/fpk/compiler'
rm -f ppc386.exe
rm -f fpcmade.w32 ppas.bat link.res log

snip

d:/fpk/compiler/ppc1.exe !FPCEXTCMD ../objpas/math.pp d:/fpk/compiler/ppc1.exe !FPCEXTCMD -I../objpas varutils.pp d:/fpk/compiler/ppc1.exe !FPCEXTCMD ../i386/cpu.pp d:/fpk/compiler/ppc1.exe !FPCEXTCMD ../i386/mmx.pp d:/fpk/compiler/ppc1.exe !FPCEXTCMD ../inc/getopts.pp d:/fpk/compiler/ppc1.exe !FPCEXTCMD -Sg ../inc/heaptrc.pp d:/fpk/compiler/ppc1.exe !FPCEXTCMD ../inc/lineinfo.pp d:/fpk/compiler/ppc1.exe !FPCEXTCMD wincrt.pp
d:/fpk/compiler/ppc1.exe !FPCEXTCMD winmouse.pp
d:/fpk/compiler/ppc1.exe !FPCEXTCMD sockets.pp
d:/fpk/compiler/ppc1.exe !FPCEXTCMD printer.pp
d:/fpk/compiler/ppc1.exe !FPCEXTCMD ../inc/dynlibs.pp make.exe[3]: Leaving directory `d:/fpk/rtl/win32'
c:/pp/bin/make.exe clean
make.exe[3]: Entering directory `d:/fpk/compiler'
rm -f ppc386.exe
rm -f fpcmade.w32 ppas.bat link.res log
rm -f *.ow *.ppw *.rst *.sw *.aw *.dll *.ppl
rm -rf *.slw
rm -f fpcmade.w32 ppas.bat link.res log
make.exe[3]: Leaving directory `d:/fpk/compiler'
c:/pp/bin/make.exe all
make.exe[3]: Entering directory `d:/fpk/compiler'
d:/fpk/compiler/ppc1.exe !FPCEXTCMD -XX pp.pas
d:\FPK\RTL\WIN32\WPRT0.OW(.text+0x2):fake: undefined reference to `U_SYSWIN32_ISCONSOLE'
d:\FPK\RTL\WIN32\WPRT0.OW(.text+0xe):fake: undefined reference to `U_SYSWIN32_ISCONSOLE'
PP.OW(.text+0x185):pp.pas: undefined reference to `U_SYSWIN32_ISCONSOLE' mv -f pp.exe ppc386.exe
c:/pp/bin/mv: pp.exe: No such file or directory (ENOENT) make.exe[3]: *** [ppc386.exe] Error 1
make.exe[3]: Leaving directory `d:/fpk/compiler'
make.exe[2]: *** [next] Error 2
make.exe[2]: Leaving directory `d:/fpk/compiler'
make.exe[1]: *** [ppc2.exe] Error 2
make.exe[1]: Leaving directory `d:/fpk/compiler'
make.exe: *** [cycle] Error 2

begin 600 make.ZIP
M4$L#!!0````(`'V24"F1E$/',0]```*````;6%K970R+G1M<.U;6V_; M.!9^%Z#_0,Q+9H)8UB47VT`?=M*F*#9=!TEF9H&ZR-(2;6LBB01).\G^^N5% M-XM,F_1B`\(&L$.?0Q[R^WAX1%+D8/`1%R`X'0;^T/=!,)H$XTEX"CBD2\0! M',&<@YP'@C+O.8)`6*4]A!F*<DS1#%,23&2%\-D\+\3^.
M1J='(`BU=9&*)M&Q+)9!CA@'#*]IC!A8,Y0TC?##B7\B<XEZC\"Q^DY(GH(- MHBS%!0-G7B"LG7I^`'QO[,N\.;Q'@'&:%DMMSO,\H(33J]LWOX!!4J`'3'B: MI_^%7%D9)$+UC\L/[_\%!M/W$8DH&&Q^`=.;.XW^S1)'X28$\5.<(=>))T-" )KUT",""'_))(.7(?F
M8+``FB%9M)(L2)S#!'F2<D(@>`(97E8Y#STL/H2LQ3<57!YZ
M3'<Y)95:6O::"+3R7"&Z^"L?"S>!<=,(U
M>HP1X85(+<C:PY66/3&.<L4(GO\MH<"L4H13+G.
M22A>",$Q4&N7K:'2FQ5AGC2FOZA0(JN*I!*8KI9"L=%.>V)JGF<Z2 M0ZZE_(FDQ0)K6P*/4N:/NBSBF)<KQFNJWQ"E*&=(,V
MD-;551RI6J6WU$HJQ_$/=XVMSGN)<QS(4?K2,7H`8)9]HR=!81-7GK0)50*R M2MZX5I5J=,K9U+>4*5!<H6I&,1A<I`)'R+#S;+Q
M:N`ZHJ-X!HCH0Y`6P(L72Y"*7!?K\\GLZBJ87=]>SMY.;V;OIU' M<,HB"P/.]$'P*?=^7<3<(/X,%ID!6[CKGF#S1=+GBX-?X-Q", )W"189K"@G"]$/M_I9,;V9`%DS^#,$HA6"08Z*!%%I3=8M
M.Z=&XSI!-(I\<)D6B%5/C^0(^-X(,>O`T0NV/6^F`<UJ
M7*X3G8PLK`>[85V;&39!N2\\"U2S!I7KG!T?6UCV=\-R^9SK!;<E%M<)@K.S M_3FN#,6M64,OJ&WA$?0>CVW1>'^HD`UF^T%IQ48R>EX
MCYS6ZX)^L%K#<9THLCVQ=C3^FS56/R)>_16
MW)NXJJ&X3A#N<;G,:K:D^K3,:E"Y3BB,;
MJ+;Y>C(;J."XSO'I_B99:FM&^J_:.JTW4/NQG"W!N$YP,HK,F6RPLP5M:_^K MM3'=EUW&"H_TY&/;D^UD9Y&XW%HL-_Q[MK%8HG*=OVC*I>H:Z9=ZX$:_B[N% M\PP!N<J8`&]6O7]PG?&9;5J\H\`M=W.:GFG>P/2L<,ZLVU%[(COLO!0 MO]_JS61$5##3D`2_-GIW.-V3].K7AKVB5T.2;XML\[P=34BJZ4C]-K9/T^D& ME>N<!/N<)ENWG7WB>D&E=P5\O>'2W#I&T">>6[!<Y_1DCZ\UFJ,9 MO>"W@>,ZT7B/;^-*_VU.N_3)?1M4KA/L\Z5XG8.DS4"ZY;>%ZZ=MD^,A7X M8]L")M)=\X..25$DD]$WG3!\QCM>"_/[M[^+[]^OI7S?OKB^G[\6/FS^N MKJ;7MW<?/_Y;/:]%EY?^M?:VSG,-+M+OV%<C'I%GK'JPI58B:>T/0QZOND+1 MQCF6@;63MW31CK3>)GA.33-2#%_(D:E)5]=,<?WJ#",Z/-<
MEB;F9(7Q?5>^2`NRYD9N.2?J9,QQLLZ,MA&YV.JV(.=RF%KD,2Z841F$+._* MFJ7<')J]T&CUI*)#8S(WJ!*L&I04.#$L+Z6_+$PZ1$=RVA6O8F%!E.C*YQ0_ M9'AIX(]A42##"GM(>;PRF]>`M/"#ES)\=(4/-K+P`S3JK(*2P1/1ARP-&T3% MB*Y8G40U4-+4-,#OQ+_U8U><YO(4P0LSH\=79.9WBSE+3"EFH8T,RDR/YW</ M:1$9V?E=\6#T![_34?89>6`AE%EZD,AYAM$KD#&46P84E$XP3PW_4\Z1S`T' M5/)X8;BWDJ/,D"O[D!N4EYZIU,6S8U>IT\*,+<)&)I#V2);
MR4$?KPP'%3_9G=$A?(F*U-(C'.7DSC+&J]8NH:T41<N-Z$JCF7&Q,629X:76 M;+'Y`"ABF!FRM#!E,#'KR*'1,X6:XW;S(:.#BT7V8&75</]6KYDP6TH+X)96 ;;"8%MK\M;26IAN:2U]2&RAG=AF"P0]$F-P
MD03%IDUN?1ZOXF4".;298&OCT2K%&_,)(\5X_K<AMEE@'/+<#!0E(13:XTA; M;8P_:)VGM8L\']>4.DE-2/H!])Q5B`FW-*74)E]6DR]J8V97D^KP?D>LIVIE M0R_3XE[;(D3?:PK"<'1J;BL&)]ZX7"MM]%4HM3XQ;T0)2:!_5QGKQ4RCLJR= M#BZNSM]TED7#JL0!.)A>OI4Y#D"!'GEKA16^;H6U7:GX=*\Y1=]Q)VS+R$^[ MB/65%O[_(M9/N(A5<H0KAG#-#];LX(8;7#*#2UYPS0JN.<$5(;N.8" @?<L(`U![AF`"O\6*''-79<(\<-;ERCQC5FW"#&/_[BV9>'PNLOGGTM M3'S'O;(1I1B>B3:K?;8/-=14UC1
MCE\#_R0Z"GX#%Y##K%54E0!C\=?A\O#P$'QJHLMG\$[E#+[-.[8BOC(MGP25 MT;"3X471=VN;3ID4](=28C/[XMNU58G2IKJ/W#+X/U!+`0(9`!0````(`'V2 M4"F1E$/',0]```*``````````$`(`````````!M86ME=#(N=&UP4$L% (``````==
`
end

Hello, I think about this strange directive PAVEL_LINKLIB ... Might be better setup fixes of Pavel to main code of fpc (like Gaber fixes ;-) ), or reject them? :-)

What is PAVEL_LINKLIB fixes? I think this for Win32 only fixes or not? Pavel report me (might be in russian forum?) about it. ok?

P.S: I think, Pavel is tormented every release fix ;-) I am right, Pavel?

Hello, May be, my patches which are introduced into compiler source under

PAVEL_LINKLIB conditional compiling directive will be

not "main stream", but now (while they exist in the compiler source) they

must be at lease able to be compiled. In the

last release it is impossible. t_win32 unit must be fixed: lines 910-912

must be

LinkRes.AddFileName(GetShortName(FindObjectFile('wdllprt0','')))

file://fix 17.10.2000

else LinkRes.AddFileName(GetShortName(FindObjectFile('wprt0','')));

file://fix 17.10.2000

At 09:52 17/10/00 , vous avez écrit:

The problem is that I don't want to make Pavel's code default, because it would break a lot of working stuff
(I would not be able to compile the IDE for win32 anymore with this code !)

The best would of course be to insert it into main code but to use it with a special switch...
but I have already too much to do and I never found the time to really do this !

Hello.

Really fixes such global?

Hello,
May be, my patches which are introduced into compiler source under PAVEL_LINKLIB conditional compiling directive will be not "main stream", but now (while they exist in the compiler source) they must be at lease able to be compiled. In the last release it is impossible. t_win32 unit must be fixed: lines 910-912 must be LinkRes.AddFileName(GetShortName(FindObjectFile('wdllprt0',''))) //fix 17.10.2000 else

   LinkRes.AddFileName(GetShortName(FindObjectFile('wprt0',''))); //fix 17.10.2000

Pavel

Hello,
in the last impdef.pas the ending end. is missed. Please fix it.

Pavel

At 11:32 20/11/00 , vous avez écrit:

Hello, in the last impdef.pas the ending end. is missed. Please fix it.

Whoops, a copy/paste failure of one of us.

Fixed in CVS.

Thanks for reporting this bug.

Hi guys finally got some time off to do some work

New bug in version 1.02 release

The compiler spits it if you try to link a resource file into your exe with {$R Somename}

error

'-gcc' no recognized as an internal or external program Warning preprocessor failed
Warning no resources
Closing script ppas.bat

Also what is the status of the bug with not being able to have a record label and type the same "HIcon: HIcon;"

Regards leon

Hello to All,

May be don't correct work fpc 1.0.2 with DWORD. Parameter lost. If change on WORD - it's fine.

I'm not verify this, bug users report me about this problem. Tomorrow, i'm post example, if needed.

Bye

Opps,

This right: " I'm not verify this, BUT users report me about this problem. Tomorrow, i'm post example, if needed."

The problem is not in the compiler, but in windres; to work with windres, you need gcc installed. (for it's preprocessor)

Also what is the status of the bug with not being able to have a record label and type the same "HIcon: HIcon;"

I think this is fixed in the development branch, but I am not 100% sure.

Michael.

I'm not verify this, bug users report me about this problem. Tomorrow, i'm post example, if needed.

This definitely needs an example if we're supposed to fix it.

Jonas

Hello, I compiled after some fixes the yesterday's CVS compiler.

1) also in t_win32 the old problem presents: parameter list of FindObjectFile was changed but lines 908, 910 (inside PAVEL_LINKLIB conditional block) were not fixed.
2) also now if DLL main module will be compiled into library (-CX -XX), export info will be lost (the library does not contain .edata ). But adding also -a into compiler command line (using external assembler) solves the problem. Why internal coff writer does not generate .edata section by creating smartlink libraries?

Pavel
P.S. Please tell me, which problems causes my version of $linklib? I would try to solve these problems.

No, it's not fixed yet (at least not in the compiler, but I've just committed a fix for the windows unit so the field is now called _hicon instead of hicon)

Jonas

Can you send me a patch ?

I already started to try to fix that problem,
the .edata section is created. The problem is that it is in a separate object if you smart create and it is not inserted in the final link because it is not required (no reference to any label from that object is used !)

I will try to solve this by adding an explicit reference to a assembler label of the .edata object file into
the object file containing the main procedure.

Pavel P.S. Please tell me, which problems causes my version of $linklib? I would try to solve these problems.

The main problem is that
external name 'ANY_bizaRRE_nAMe';
is translated into the whole compiler into an assembler label that is exactly 'ANY_bizaRRE_nAMe'
but your version of linklib associates
external name 'DLLFunction';
to the assembler label _DLLFunction
with a leading underscore.

You might argue that this is a detail, but for me it is a very important one.

----- Original Message -----

It's the windows unit, the file in whic it's been changed is rtl/win32/wininc/struct.inc

BTW: in the 1.0.3 branch not so much is changing.

Jonas

907:  if isdll then
908:   LinkRes.AddFileName(GetShortName(FindObjectFile('wdllprt0','')))
909:  else
910:   LinkRes.AddFileName(GetShortName(FindObjectFile('wprt0','')));

Please send me an example which could demonstrate this difference.

My example will be translated into the same asm code by both compiler variants:

{$linklib anylib}
function testfn(x:longint):pointer;
 external name 'testfn';
var
 p:pointer;
begin
 p:=testfn(1000);
 writeln(longint(p));
end.
	.file "test0.pp"

.text
.balign 16
.globl _main
_main:
.globl PASCALMAIN
PASCALMAIN:
.globl program_init
program_init:
pushl %ebp
movl %esp,%ebp
subl $4,%esp
call FPC_INITIALIZEUNITS
pushl $1000
call testfn
movl %eax,_P
.L7:
leal U_SYSTEM_OUTPUT,%edi
movl %edi,-4(%ebp)
pushl _P
pushl -4(%ebp)
pushl $0
call FPC_WRITE_TEXT_SINT
pushl -4(%ebp)
call FPC_WRITELN_END
pushl $.L7
call FPC_IOCHECK
call FPC_DO_EXIT
leave
ret
.balign 16

.data
.ascii "FPC 1.1 [2000/11/20] for i386 - WIN32"
.balign 4
.globl FPC_RESOURCESTRINGTABLES
FPC_RESOURCESTRINGTABLES:
.long 0
.globl INITFINAL
INITFINAL:
.long 1,0
.long INIT$$SYSTEM
.long 0
.globl HEAPSIZE
HEAPSIZE:
.long 262144

.data

.data

.section .bss
.lcomm _P,4
.comm HEAP,262144

In this example is assumed that the external function, testfn, is located in dynamic library (e.g., dll for win32).

To link a static library created by ar GNU (or compatible) utility (.a, .aw etc), my version supports directives like {$linklib anylib,static}. "Official" $linklib does not see differences between dynamic and static libraries. It applies to both types of libraries the same command in linker response file:

INPUT(
-llibname
)

This assuming causes some problems. 1) default library extension used by ld is not always the same that used in fpc (e.g., for win32 the static libraries are *.aw, but ldw waits for *.a); 2) Very often the big static libraries contain cross-references and therefore they must be linked as a group; 3) The libraries search path written in .res file does not contain current directory and therefore the linker cannot find third-party libraries if progammer places them into his working directory.

The underscoring symbol (which must be added manually to externals names which are located in dll although really this character is missed in this dll: external name '_MessageBoxA') is a forced and temporary solution. The cause is follow: to "link" dll to exe, an interface static library must be created. Now this library is creating by dlltool which is developed for C and therefore adds additional underscores. But one half of this work now is already moved to fpimpdef which creates a .def file. It is possible, to develop fpimpdef to fpimplib which will generate ar-compatible COFF static libraries without useless underscores. I could try to do it later.

Pavel

Hi,

I began to write fpimplib for Win32. I have some questions:
1) Is it possible, to distinguish references to exported functions and to exported variables in DLL?
2) Is this difference considered in standard interface libraries in GNU-Win32 (CygWin, MinGW32)?
3) If (2) is yes, how is solved this problem in GNU-Win32?

Pavel

At 10:17 23/11/00 , vous avez écrit:

You can look at the RVA address and compare with
.text .data .bss addresses boundary.

2) Is this difference considered in standard interface libraries in GNU-Win32 (CygWin, MinGW32)?

No idea, I don't even know if GNU-Win32 supports exporting/Importing of variables.

3) If (2) is yes, how is solved this problem in GNU-Win32?

Try the cygwin mailing list !

you wrote

At 10:17 23/11/00 , vous avez écrit: >Hi, > >I began to write fpimplib for Win32. I have some questions:

Why is a fpimplib necessary? You've still to write an interface unit.

Why is a fpimplib necessary? You've still to write an interface unit.

I would use it to auto-generating interface static libraries if a DLL is pointed in $LINKLIB.

You can look at the RVA address and compare with .text .data .bss addresses boundary.

Sorry for my ignorance, but I cannot understand how to compare these values. I got now in my test the entries of an exported procedure and of an exported variable (as I could see in asm sources, the first is located in .text, the second in .bss). Also I got the virtual addresses of .text and .bss. All 4 values are correct (I checked them also with NT Quick View) but I don't understand relationships:

Procedure entry point in export table: 5F38H,
Variable entry point in export table: 1040H,
.text section virtual address: 1000H,
.bss section virtual address: 40F3H.

Also when I tried to view other (e.g. NT system) dlls, many functions have entries outside of .text virtual addresses.

Please, if possible, explain me, how to recalculate these values to make comparing correct.

Hello, I would make 2 messages:
Message 1:

There are exist a discrepancy between generation of public names in dlls by exporting and by importing (if they are not pointed evidently using NAME keyword). By exporting they are converted to uppercase (like BP7 but not like Delphi32), by importing they remain unchanged.

Message 2:

Next version of PAVEL_LINKLIB patches based on today's snapshot is done. Leading underscores problem is solved. Now I can compile and link these examples:
1) UNIX-style "linking" of dlls:

{$linklib user32}
function MessageBoxA(x:longint;y,z:pchar;w:longint):longint;
 external;
begin
 MessageBoxA(0,'!','!',0);
end.

2) linking of static libraries (must be target-independed):

{$linklib 'libuser32.aw',static}
function MessageBoxA(x:longint;y,z:pchar;w:longint):longint;
 external;
begin
 MessageBoxA(0,'!','!',0);
end.

Import of functions is fully supported. Import of variables from dlls is also possible but with one restriction (I see no suitable solutions): dlls export not the variables, but their addresses. Before linking the compiler cannot "foretell", is this variable located in static library or in dll. Therefore external must be described not as as variable but as a pointer to variable.

Rewritten are:
impdef.pas (not completely but essentially);
t_win32.pas (minor changes).

Also fpimpdef program is rewritten (now it must be compiled with -dSTANDALONE option!). It works also as implib: creates static interface libraries for dlls (using asw and arw external utils). I'm ready to send fixed units. Where must I send them? Is mailing list a suitable address?

Hello, I would make 2 messages: Message 1: There are exist a discrepancy between generation of public names in dlls by exporting

and
by importing (if they are not pointed

evidently using NAME keyword). By exporting they are converted to uppercase (like BP7

but
not like Delphi32), by importing

they remain unchanged.

For the mainbranch compiler this can be changed easily. For the fixes branch i don't know atm.

This problem is actual in "both branches" because my $LINKLIB-concerned patches don't touch these parts of compiler code (BTW, I have no idea and no plans to create an independed FPC-branch! Really, sometimes I have a little free time and try to improve compiler. All my fixes I send to "official" developers team, some of them are introduced into official FPC, other are also excluded from "my home FPC" because I would write programs which could be recompiled with any recent version of FPC, not only with my "clone").

Pavel

At 08:44 29/11/00 , vous avez écrit:

I really think that the best method would be to
integrate your code in the main source,
but to activate it with some special switch, so that everybody can use yor patch without recompiling the compiler, but that the default behavior does not change.

I try always to keep old behavior if my additional options are not pointed evidently (may be, that is not always succesful?).

But where I can send my yesterday's patches? Can I use home address of Pierre or of someone another?

Pavel

At 11:05 29/11/00 , vous avez écrit:

Yes please send patch to the fixes branch to me at

Nu nakonec-to :)

Happy end of {$DEFINE PAVEL}? :)

pointed