Re: [fpc-devel] Staticaly link C/C++ library (.lib) into FreePascal on Windows

[silvioprog]

On Wed, Mar 15, 2017 at 4:38 AM, LacaK  wrote:
>
> I forgot a question, could you send your ippi .a files for us? If so, I
>> can try a test here. :-)
>>
>
> Yes of course: I have uploaded them here http://uschovna.zoznam.sk/down
> load?code=1342688547227-EZyyeVzToDVVkkbJNCbN
> But be aware of that I am on Windows, not Linux (Despite this I have added
> to ZIP also .a files as they are installed by Intel into direcotry "Linux".
> In direcory "Windows" are installed only .lib files).
> If I can repeat my question: Can I use ".a" libraries also on Windows ? If
> not can I use ".lib" created by C/C++ (I do not know how they are build)
> Thank you
>
> -Laco.
>

Unfortunately you can't use the static libraries (.a) of Intel because they
are generated for Linux, in spite of static libraries be cross-platform.

I'm not sure about the .lib files. MS's COFF files adopt the .lib
extension, but it is a little bit strange these sizes below:

`libippi.a`:
. original - 251 MB;
. striped - 192 MB.

`libippi.lib`:
. original - 853 KB;
. striped - no strip needed, it is already small.

Huge difference, so I'm not sure if the .lib are really COFF files (even
the owns MS COFF style). I tried to convert it to OMF (the .obj for testing
on Delphi, because I don't know if FPC supports OMF) via the VS LIB.EXE
tool and I didn't have success. The .obj was generated, but it doesn't work
because it was generated with only the library "interface", so I'm
suspecting the `libippi.lib` requires external libraries, something like
other .libs or .dlls, because 853 KB is a very small size for the same
library that requires 250 MB on Linux... you need to check about it at
Intel support (or trying it in C or C++ just to check if these .lib files
are really OK).

Anyway, I'm on Linux and I did this test below, it worked fine (just
sharing it, but I know you need it on Windows :-) ):

type
  cchar = AnsiChar;
  Pcchar = PAnsiChar;
  cint = Int32;

  IppLibraryVersionPtr = ^IppLibraryVersion;
  IppLibraryVersion = record
major: cint;
minor: cint;
majorBuild: cint;
build: cint;
targetCpu: packed array [0 .. 3] of cchar;
Name: Pcchar;
Version: Pcchar;
BuildDate: Pcchar;
  end;

function ippGetLibVersion: IppLibraryVersionPtr; cdecl; external;
{$LINKLIB  ippcore.a}
{$LINKLIB ippi.a}

var
  ver: IppLibraryVersionPtr;
begin
  ver := ippGetLibVersion;
  writeln(ver^.Version);
end.

// result: 2017.0.2 (r54644)

-- 
Silvio Clécio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Some questions about compiler work on x86_64-win64

[Bishop]

   

03/18/17 00:51:05, Sven Barth via fpc-devel
:

> Bo, the main sense of this is to detect when a new thread is started
and more importantly terminated cause only with this we can free the
threadvar area of the thread accordingly (if the thread is an external one,
not one started using BeginThread or TThread).

Thanks, now i understand how its work. Plus as i understand on Linux (and
other unixes) threadvar for external threads allocated on first access to
them (and free via PThread ability to call destructor for key).

> Why *should* it be auto generated if one can use a table and let the
RTL do the rest.
Is it not better make all that can be done in compile time? Its not more
complex solution for compiler code, but as i see it, its more harmonious
(Its depend not only INIFINAL, but all tables, than used in RTL to make
work of compiler/linker. As example, FPC_THREADVARTABLES. Different
modules, i mean DLL or SO, use different TLS keys for their threadvar
regions. But why position of variable from begin of threadvar region must
be generated in runtime? Isn`t it work for linker?). Possible this is
depend on that "dynamic packages"?

> Also with the addition of dynamic packages this will move even more
towards a table based approach.
Where i can read information about what is it and why we need it? What kind
of problems is must solve? Because we already have dll/so, and as i know
and see for now its enough. Possible my knowledge is not enough to see
whole problem.

> But you can set the corresponding PE flag for ASLR using $SetPEOpts
(or so). No recompilation needed in that case.
Can. But what if i dont want ASLR binary? Its totaly valid.

> Microsoft recommended that approach for Win64 so why should we do the
work and implement it differently even if ASLR isn't enabled by default for
FPC executables?
Recommendation in not a law (like it is with SEH in Win64). C compilers
allow both type of programs, depend on what programmer need. Is it need
many work to change it? As i see it, its just one check in compiler code
for global varibles (if select PIC - use RIP-related, if not - use direct).
It already done in linux. I think it was better to give compiler user more
possibilities when its cost almoust nothing.

Regards,
Roman

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