Re: [fpc-devel] FPC internal linker issues with Win64 .a startic-link libraries by GCC newer than 4.8.1
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
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
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
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
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
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
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
[fpc-devel] FPC internal linker issues with Win64 .a startic-link libraries by GCC newer than 4.8.1
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 ogbase.pas.patch Description: Binary data ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel