Hello,

i've noticed a weakness of the FPC internal
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:

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 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

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

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

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...

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

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 :).

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

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. ;)

as good as possible - yes, I already have an idea. Maybe I'll share it this evening when I'm home again.

 deprecated 'Use TotalFieldCount'; // return TotalFieldCount

// 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