Re: [fpc-devel] FPC internal linker issues with Win64 .a startic-link libraries by GCC newer than 4.8.1

[Sven Barth]

Am 12.12.2016 15:09 schrieb "Maciej Izak" :
>
>
> 2016-12-12 14:27 GMT+01:00 Sven Barth :
>>
>> I'm still thinking about a solution that will satisfy both of our points
as good as possible - yes, I already have an idea. Maybe I'll share it this
evening when I'm home again.
>
>
> Do you mean :
>
> === code begin ===
>   TRecordTypeField = packed record // without "Field: TManagedField"
> Flags: Byte; // visibility
> Name: ShortString;
>   end;
>
> ...
> { tkRecord }
> property ManagedFldCount: Integer read GetManagedFldCount;
 deprecated 'Use TotalFieldCount'; // return TotalFieldCount
> ...
>   tkRecord: (
> RecSize: Integer;
> ManagedFieldCount: Integer;
> TotalFieldCount: Integer;
>{TotalFields: array[0..TotalFieldCount - 1] of TManagedField;
> ManagedFields: array[0..ManagedFieldCount - 1] of TManagedField;
// or indirect pointer to init table ?
> RecFields: array[0..TotalFieldCount - 1] of TRecordTypeField});
> === code end ===
>
> Full backward compatible... Fair enough and a little Delphi incompatible
(it is already incompatible so no big difference and no redundant info for
TRecordTypeField)

Nearly. ;) I'll reply later on in the other thread.

Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] FPC internal linker issues with Win64 .a startic-link libraries by GCC newer than 4.8.1

[Maciej Izak]

2016-12-12 14:27 GMT+01:00 Sven Barth :

> I'm still thinking about a solution that will satisfy both of our points
> as good as possible - yes, I already have an idea. Maybe I'll share it this
> evening when I'm home again.
>

Do you mean :

=== code begin ===
  TRecordTypeField = packed record // without "Field: TManagedField"
Flags: Byte; // visibility
Name: ShortString;
  end;

...
{ tkRecord }
property ManagedFldCount: Integer read GetManagedFldCount;
 deprecated 'Use TotalFieldCount'; // return TotalFieldCount
...
  tkRecord: (
RecSize: Integer;
ManagedFieldCount: Integer;
TotalFieldCount: Integer;
   {TotalFields: array[0..TotalFieldCount - 1] of TManagedField;
ManagedFields: array[0..ManagedFieldCount - 1] of TManagedField; //
or indirect pointer to init table ?
RecFields: array[0..TotalFieldCount - 1] of TRecordTypeField});
=== code end ===

Full backward compatible... Fair enough and a little Delphi incompatible
(it is already incompatible so no big difference and no redundant info for
TRecordTypeField)

> Then don't pick such controversial topics :P
>
You never know what is controversial :P. Core team is unpredictable. ;)

-- 
Best regards,
Maciej Izak
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] FPC internal linker issues with Win64 .a startic-link libraries by GCC newer than 4.8.1

[Sven Barth]

Am 12.12.2016 12:31 schrieb "Maciej Izak" :
>
>
> 2016-12-09 13:49 GMT+01:00 Sven Barth :
>>
>> Improvements for cppclass are definitely welcome :)
>
>
> Rather not mine :P I have packed cppclass into record. For "wrapped
cppclass" I have "default" field (aka proxy record) for direct access
combined with "managament operators" to handle "new" & "destroy" operators.

Okay, that is indeed something I would not want to see in the compiler...

> I have always many troubles with my patches/reports (many times reopened
- #25610, #25607, long pending time - #27206, not merged - #30687). I don't
have real response about ManagedFldCount (#31102) nor vManagedTable topic.

I'm still thinking about a solution that will satisfy both of our points as
good as possible - yes, I already have an idea. Maybe I'll share it this
evening when I'm home again.

> I always need to use many arguments to force my changes (even simple and
basic changes). It costs me many time, energy and nerves.

Then don't pick such controversial topics :P

Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] FPC internal linker issues with Win64 .a startic-link libraries by GCC newer than 4.8.1

[Maciej Izak]

2016-12-09 13:49 GMT+01:00 Sven Barth :

> Improvements for cppclass are definitely welcome :)


Rather not mine :P I have packed cppclass into record. For "wrapped
cppclass" I have "default" field (aka proxy record) for direct access
combined with "managament operators" to handle "new" & "destroy" operators.

I have always many troubles with my patches/reports (many times reopened -
#25610, #25607, long pending time - #27206, not merged - #30687). I don't
have real response about ManagedFldCount (#31102) nor vManagedTable topic.
I always need to use many arguments to force my changes (even simple and
basic changes). It costs me many time, energy and nerves. I see no sense in
contributing improvements for cppclass. Especially that Jonas is in
opposition to default field/proxy records. I have patch for this but... It
has no sense. #30687 is not merged yet, so what is the sense for
contributing "yet another big patch" when I am not sure about future of
#30687 which is base for many new patches?

I will continue my work in less problematic topics like minor/major bug
fixes for FPC. Improved cppclass will be merged to NewPascal because I
can't see any chance in FPC trunk for my modifications.

Good deal for all :).

-- 
Best regards,
Maciej Izak
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] FPC internal linker issues with Win64 .a startic-link libraries by GCC newer than 4.8.1

[Sven Barth]

Am 09.12.2016 10:32 schrieb "Maciej Izak" :
>
>
> 2016-09-18 2:31 GMT+02:00 Benjamin Rosseaux :
>>
>> i've noticed a weakness of the FPC internal linker at static-linking .a
libraries on the Win64 target, which're generated by GCC newer than 4.8.1,
due to the new refptr.* and .refptr.* symbols-can-be-multiple-defined stuff
(inside one single .a library file), which was introduced in newer GCC
versions.
>
>
> I don't have the real patch for this yet but I have my inner tool to
rename all duplicated symbols for statically linking FPC with C++ code (I
have improved cppclass type). My tool uses objconv :
http://www.agner.org/optimize/#objconv . Rename for symbols is simple with
few commands for objconv ("-dfhs" to list symbols and "-nr" to rename).

Improvements for cppclass are definitely welcome :)

Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] FPC internal linker issues with Win64 .a startic-link libraries by GCC newer than 4.8.1

[Maciej Izak]

2016-09-18 2:31 GMT+02:00 Benjamin Rosseaux :

> i've noticed a weakness of the FPC internal linker at static-linking .a
> libraries on the Win64 target, which're generated by GCC newer than 4.8.1,
> due to the new refptr.* and .refptr.* symbols-can-be-multiple-defined
> stuff (inside one single .a library file), which was introduced in newer
> GCC versions.
>

I don't have the real patch for this yet but I have my inner tool to rename
all duplicated symbols for statically linking FPC with C++ code (I have
improved cppclass type). My tool uses objconv :
http://www.agner.org/optimize/#objconv . Rename for symbols is simple with
few commands for objconv ("-dfhs" to list symbols and "-nr" to rename).

Anyway your temporary patch might be better for statically linking with
SDL2...

-- 
Best regards,
Maciej Izak
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] FPC internal linker issues with Win64 .a startic-link libraries by GCC newer than 4.8.1

[Benjamin Rosseaux]

oh, "then FPC links it with any error." should be "then FPC links it
without any error."

On Sun, Sep 18, 2016 at 2:31 AM, Benjamin Rosseaux 
wrote:

> Hello,
>
> i've noticed a weakness of the FPC internal linker at static-linking .a
> libraries on the Win64 target, which're generated by GCC newer than 4.8.1,
> due to the new refptr.* and .refptr.* symbols-can-be-multiple-defined
> stuff (inside one single .a library file), which was introduced in newer
> GCC versions.
>
> For example, when I do to want link SDL2 statically to my FPC code, where
> the libSDL2.a as Win64 StaticLink Build was generated with GCC 4.9.1 or
> newer, then FPC abort with a error and outputs:
>
> > Free Pascal Compiler version 3.1.1 [2016/08/22] for x86_64
> > Copyright (c) 1993-2016 by Florian Klaempfl and others
> > Target OS: Win64 for x64
> > Compiling racegame.dpr
> > Linking racegame_x86_64.exe
> > Error: Multiple defined symbol .refptr.SDL_free_REAL
> > Error: Multiple defined symbol .refptr.SDL_XInputGetCapabilities
> > Error: Multiple defined symbol .refptr.SDL_Appname
> > Error: Multiple defined symbol .refptr.SDL_Instance
> > Error: Multiple defined symbol .refptr.SYS_Joystick
> > Error: Multiple defined symbol .refptr.SDL_XInputSetState
> > Error: Multiple defined symbol .refptr.SDL_HelperWindow
> > Error: Multiple defined symbol .refptr.GUID_XAxis
> > Error: Multiple defined symbol .refptr.GUID_YAxis
> > Error: Multiple defined symbol .refptr.GUID_ZAxis
> > Error: Multiple defined symbol .refptr.GUID_RxAxis
> > Error: Multiple defined symbol .refptr.GUID_RyAxis
> > Error: Multiple defined symbol .refptr.GUID_RzAxis
> > Error: Multiple defined symbol .refptr.IID_IDirectInput8W
> > Error: Multiple defined symbol .refptr.CLSID_DirectInput8
> > Error: Multiple defined symbol .refptr.SDL_hapticlist
> > Error: Multiple defined symbol .refptr.IID_IDirectInputDevice8W
> > Error: Multiple defined symbol .refptr.SDL_expand_byte
> > Error: Multiple defined symbol .refptr.SDL_expand_byte
> > Error: Multiple defined symbol .refptr.SDL_expand_byte
> > Error: Multiple defined symbol .refptr.SDL_expand_byte
> > Error: Multiple defined symbol .refptr.SDL_expand_byte
> > Error: Multiple defined symbol .refptr.SDL_expand_byte
> > Error: Multiple defined symbol .refptr.SDL_expand_byte
> > Error: Multiple defined symbol .refptr.SDL_expand_byte
> > Fatal: There were 25 errors compiling module, stopping
> > Fatal: Compilation aborted
>
> But for example, when I do to want the same, but where the libSDL2.a as
> Win64 StaticLink Build was generated this time with GCC 4.8.1 or older,
> then FPC links it with any error.
>
> So I did some research on this issue and found https://gcc.gnu.org/ml/gcc-
> patches/2013-03/msg00858.html in the gcc-patches mailing list and tp://
> stackoverflow.com/questions/28012075/what-does-
> refptr-mean-in-a-mingw64-def-file , so I've looked at ogbase.pas of
> FreePascal, and try to write a beginning patch, which I've attached it to
> this mail. So someone, who are more inside the FreePascal source code
> structure, should finish this patch.
>
> Regards,
> Benjamin 'BeRo' Rosseaux
>
>
>
>
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel