Discussion:
FPC internal linker issues with Win64 .a startic-link libraries by GCC newer than 4.8.1
(too old to reply)
Benjamin Rosseaux
2016-09-18 00:31:32 UTC
Permalink
Raw Message
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
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
Benjamin Rosseaux
2016-09-18 00:41:46 UTC
Permalink
Raw Message
oh, "then FPC links it with any error." should be "then FPC links it
without any error."
Post by Benjamin Rosseaux
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
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
Maciej Izak
2016-12-09 09:32:28 UTC
Permalink
Raw Message
Post by 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
Sven Barth
2016-12-09 12:49:55 UTC
Permalink
Raw Message
Post by Maciej Izak
Post by 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.
Post by Maciej Izak
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
Maciej Izak
2016-12-12 11:31:00 UTC
Permalink
Raw Message
Post by 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
Sven Barth
2016-12-12 13:27:09 UTC
Permalink
Raw Message
Post by Maciej Izak
Post by 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...
Post by Maciej Izak
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.
Post by Maciej Izak
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
Maciej Izak
2016-12-12 14:09:32 UTC
Permalink
Raw Message
Post by 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)
Post by Sven Barth
Then don't pick such controversial topics :P
You never know what is controversial :P. Core team is unpredictable. ;)
--
Best regards,
Maciej Izak
Sven Barth
2016-12-12 16:09:00 UTC
Permalink
Raw Message
Post by Maciej Izak
Post by 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.
Post by Maciej Izak
=== 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
Post by Maciej Izak
...
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 ?
Post by Maciej Izak
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

Loading...