Statically link library

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Statically link library

Darius Blaszyk
Hi,

I'm linking a C and FPC program but I keep on getting undifined symbols (see example below).

Error: Undefined symbol: _strcpy
Sofar I have added:

{$linklib msvcrt}
{$linklib gcc}     

What other libraries should I add? BTW, I'm compiling the C library with MinGW.

Regards, Darius

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Statically link library

Ludo Brands
On 04/20/2013 11:54 AM, Darius Blaszyk wrote:

> Hi,
>
> I'm linking a C and FPC program but I keep on getting undifined symbols
> (see example below).
>
> Error: Undefined symbol: _strcpy
> Sofar I have added:
>
> {$linklib msvcrt}
> {$linklib gcc}    
>
> What other libraries should I add? BTW, I'm compiling the C library with
> MinGW.
>
> Regards, Darius
>
>

_strcpy should be in msvcrt. It is defined in the mingw libmsvcrt.a file
on my system. Is your lib path correct?

BTW I use an explicit {$linklib libmsvcrt.a} with mingw.

Ludo
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Statically link library

Marco van de Voort
In our previous episode, Ludo Brands said:
> _strcpy should be in msvcrt. It is defined in the mingw libmsvcrt.a file
> on my system. Is your lib path correct?
>
> BTW I use an explicit {$linklib libmsvcrt.a} with mingw.

Afaik that is needed, gdbint also does this. For people interested in the
link sequences on various platforms, gdbint.pp is a treasure.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Statically link library

Vittorio Giovara
In reply to this post by Darius Blaszyk
On 20/apr/2013, at 11:55, Darius Blaszyk <[hidden email]> wrote:

> Hi,
>
> I'm linking a C and FPC program but I keep on getting undifined symbols (see example below).
>
> Error: Undefined symbol: _strcpy
> Sofar I have added:
>
> {$linklib msvcrt}
> {$linklib gcc}
>
> What other libraries should I add? BTW, I'm compiling the C library with MinGW.

You need to instruct fpc to use gcc instead of default ld when you
link c/pas code statically.
This is because gcc adds many linker flags that are automatically set
when you link something but are not set when you call ld directly.

I think such issue arises only when compiling statically, can you
compile your c library shared?
Cheers,
Vittorio
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Statically link library

Marco van de Voort
In our previous episode, Vittorio Giovara said:
> > {$linklib gcc}
> >
> > What other libraries should I add? BTW, I'm compiling the C library with MinGW.
>
> You need to instruct fpc to use gcc instead of default ld when you
> link c/pas code statically.

Fpc can't call gcc.

> This is because gcc adds many linker flags that are automatically set
> when you link something but are not set when you call ld directly.

FPC can pass extra flags to the linker. Just harvest the flags by compiling
a simple program with gcc
 
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Statically link library

Vittorio Giovara
On Sun, Apr 21, 2013 at 2:36 PM, Marco van de Voort <[hidden email]> wrote:
In our previous episode, Vittorio Giovara said:
> > {$linklib gcc}
> >
> > What other libraries should I add? BTW, I'm compiling the C library with MinGW.
>
> You need to instruct fpc to use gcc instead of default ld when you
> link c/pas code statically.

Fpc can't call gcc.

Well you could manually edit ppas.sh/link.res and substitute 'gcc' to 'ld', and of course adjust all the flags.
 
> This is because gcc adds many linker flags that are automatically set
> when you link something but are not set when you call ld directly.

FPC can pass extra flags to the linker. Just harvest the flags by compiling
a simple program with gcc

Indeed, too bad sometimes you have to link gcc, sometimes gcc_s.1, sometimes stdc++ and so on, depending on target, architecture, operating system and so on...
Like I said other time, not really portable, but with little use-case too, so not a big deal, right?

Cheers,
Vittorio

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Statically link library

Darius Blaszyk
In reply to this post by Marco van de Voort

I have prepared a minimal example of the linking problems I get.  Just unzip, create a "build" dir and run cmake. I'm using gcc 4.6.2.

As soon as I try to use the function "file_size" I get the following linker errors:

Free Pascal Compiler version 2.6.2 [2013/03/17] for i386
Copyright (c) 1993-2012 by Florian Klaempfl and others
Target OS: Win32 for i386
Compiling test.pp
Compiling test_h.pas
Linking project1.exe
test.pp(9,1) Error: Undefined symbol: _open
test.pp(9,1) Error: Undefined symbol: _filesize
test.pp(9,1) Error: Undefined symbol: _close
test.pp(9,1) Fatal: There were 3 errors compiling module, stopping

It really seems I need to add an additional library to the pascal source or that the linker cannot find some included symbols in the also attached libmsvcrt.a.

Any help appreciated.

Regards, Darius



[hidden email] schreef op 21 apr '13:

In our previous episode, Vittorio Giovara said:
{$linklib gcc} What other libraries should I add? BTW, I'm compiling the C library with MinGW.
You need to instruct fpc to use gcc instead of default ld when you link c/pas code statically.
Fpc can't call gcc.
This is because gcc adds many linker flags that are automatically set when you link something but are not set when you call ld directly.
FPC can pass extra flags to the linker. Just harvest the flags by compiling
a simple program with gcc
 
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

 


 

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

fpc_C.zip (48K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Statically link library

Marco van de Voort
In reply to this post by Vittorio Giovara
In our previous episode, Vittorio Giovara said:
> > Fpc can't call gcc.
> >
> > Well you could manually edit ppas.sh/link.res and substitute 'gcc' to
> 'ld', and of course adjust all the flags.

Possible, but not really sane. The  platforms with a lot of static linking
are mostly the non-unix ones, with multiple gcc's (mingw vs cygwin etc), and
gcc is not terribly standard on such platforms.

> > FPC can pass extra flags to the linker. Just harvest the flags by compiling
> > a simple program with gcc
> >
> > Indeed, too bad sometimes you have to link gcc, sometimes gcc_s.1,
> sometimes stdc++ and so on, depending on target, architecture, operating
> system and so on...

> Like I said other time, not really portable,

True, a portable solution would have such information in a more accessable
location.

> but with little use-case too, so not a big deal, right?

Yes. See above.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Statically link library

Darius Blaszyk
In reply to this post by Ludo Brands

<retrying with a smaller zip>

I have prepared a minimal example of the linking problems I get.  Just unzip, create a "build" dir and run cmake. I'm using gcc 4.6.2.

As soon as I try to use the function "file_size" I get the following linker errors:

Free Pascal Compiler version 2.6.2 [2013/03/17] for i386
Copyright (c) 1993-2012 by Florian Klaempfl and others
Target OS: Win32 for i386
Compiling test.pp
Compiling test_h.pas
Linking project1.exe
test.pp(9,1) Error: Undefined symbol: _open
test.pp(9,1) Error: Undefined symbol: _filesize
test.pp(9,1) Error: Undefined symbol: _close
test.pp(9,1) Fatal: There were 3 errors compiling module, stopping

It really seems I need to add an additional library to the pascal source or that the linker cannot find some included symbols in libmsvcrt.a.

Any help appreciated.

Regards, Darius



Ludo Brands schreef op 20 apr '13:

On 04/20/2013 11:54 AM, Darius Blaszyk wrote:
Hi, I'm linking a C and FPC program but I keep on getting undifined symbols (see example below). Error: Undefined symbol: _strcpy Sofar I have added: {$linklib msvcrt} {$linklib gcc} What other libraries should I add? BTW, I'm compiling the C library with MinGW. Regards, Darius
_strcpy should be in msvcrt. It is defined in the mingw libmsvcrt.a file
on my system. Is your lib path correct?

BTW I use an explicit {$linklib libmsvcrt.a} with mingw.

Ludo
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

 


 

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

fpc_C.zip (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Statically link library

Ludo Brands
On 04/21/2013 05:20 PM, Darius Blaszyk wrote:

> <retrying with a smaller zip>
>
> I have prepared a minimal example of the linking problems I get.  Just
> unzip, create a "build" dir and run cmake. I'm using gcc 4.6.2.
>
> As soon as I try to use the function "file_size" I get the following
> linker errors:
>
> Free Pascal Compiler version 2.6.2 [2013/03/17] for i386
> Copyright (c) 1993-2012 by Florian Klaempfl and others
> Target OS: Win32 for i386
> Compiling test.pp
> Compiling test_h.pas
> Linking project1.exe
> test.pp(9,1) Error: Undefined symbol: _open
> test.pp(9,1) Error: Undefined symbol: _filesize
> test.pp(9,1) Error: Undefined symbol: _close
> test.pp(9,1) Fatal: There were 3 errors compiling module, stopping
>
> It really seems I need to add an additional library to the pascal source
> or that the linker cannot find some included symbols in libmsvcrt.a.
>
> Any help appreciated.
>
A few things wrong in your files:
- the c program. When you want to link against msvcrt then you better
use the ms functions;) There is no filesize, or open, or close (the
latter are deprecated since a while and not present anymore in msvcrt)
This works:

#include <stdio.h>

#include "test.h"
#include <fcntl.h>

int file_size(char * name)
{
        int file, size;

        if (name == 0) return(0);
        file = _open(name, O_RDONLY);
        if (file == -1) return (0);

        size = _filelength(file);
        _close(file);
        return(size);
}

- the binding:

unit test_h;

interface

{$linklib libtest.a}
{$linklib libmsvcrt.a}

uses
  ctypes;

function file_size(Name: PChar): cint; cdecl;external ;

implementation

end.

This runs correctly on my system.

I have attached the modified files and the 2 .a files (windows x86). The
MakeFile.win created by wxDev-C++ is included. I renamed the
Output/MingW/Project1.a to libtest.a. When using wxDev-C++ make sure to
set the file to compile as a C file. Default is C++ and that uses a
different name mangling.

Ludo

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

libtest.zip (44K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Statically link library

Darius Blaszyk

On Apr 21, 2013, at 6:35 PM, Ludo Brands wrote:

> A few things wrong in your files:
> - the c program. When you want to link against msvcrt then you better
> use the ms functions;) There is no filesize, or open, or close (the
> latter are deprecated since a while and not present anymore in msvcrt)
>
<snip>
>
> This runs correctly on my system.
>
> I have attached the modified files and the 2 .a files (windows x86). The
> MakeFile.win created by wxDev-C++ is included. I renamed the
> Output/MingW/Project1.a to libtest.a. When using wxDev-C++ make sure to
> set the file to compile as a C file. Default is C++ and that uses a
> different name mangling.

Thanks Ludo! Works perfectly also here. However for my understanding. Why does MinGW find open, filesize etc? Is there some header file that "translates" these functions to be compatible with msvcrt? If not I would have to create one myself to limit the amount of work I guess.

Regards, Darius


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Statically link library

Ludo Brands
On 04/23/2013 10:14 PM, Darius Blaszyk wrote:
>
>
> Thanks Ludo! Works perfectly also here. However for my understanding. Why does MinGW find open, filesize etc? Is there some header file that "translates" these functions to be compatible with msvcrt? If not I would have to create one myself to limit the amount of work I guess.
>

Is MinGW finding open, filesize ? When building a static library there
is no verification at all if functions really exist.
Enter
        size = whatever(file);
and build your static library. You don't get any errors. Only when
linking the final executable it will start looking for 'whatever'.

In C you don't have to prototype functions. The compiler just assumes an
extern int if the function is not defined in the source or an header
file and leaves it up to the linker to sort it out. Or worse, lets your
program crash if the function exists but has a different parameter list
or does not return an int. Welcome to the joys of programming in C ;)

Ludo
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Statically link library

Darius Blaszyk

On Apr 24, 2013, at 10:00 AM, Ludo Brands wrote:

> On 04/23/2013 10:14 PM, Darius Blaszyk wrote:
>>
>>
>> Thanks Ludo! Works perfectly also here. However for my understanding. Why does MinGW find open, filesize etc? Is there some header file that "translates" these functions to be compatible with msvcrt? If not I would have to create one myself to limit the amount of work I guess.
>>
>
> Is MinGW finding open, filesize ? When building a static library there
> is no verification at all if functions really exist.
> Enter
> size = whatever(file);
> and build your static library. You don't get any errors. Only when
> linking the final executable it will start looking for 'whatever'.
>
> In C you don't have to prototype functions. The compiler just assumes an
> extern int if the function is not defined in the source or an header
> file and leaves it up to the linker to sort it out. Or worse, lets your
> program crash if the function exists but has a different parameter list
> or does not return an int. Welcome to the joys of programming in C ;)
>
Yes it does find them, the statically libraries are linked into an executable which works fine. That is why I was surprised. I'm sure MinGW must link to other libraries as well. The question though is which. Anyway to find out for a simple example project executable?

Regards, Darius

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Statically link library

Paul Breneman
Darius Blaszyk wrote:

> On Apr 24, 2013, at 10:00 AM, Ludo Brands wrote:
>
>> On 04/23/2013 10:14 PM, Darius Blaszyk wrote:
>>>
>>> Thanks Ludo! Works perfectly also here. However for my understanding. Why does MinGW find open, filesize etc? Is there some header file that "translates" these functions to be compatible with msvcrt? If not I would have to create one myself to limit the amount of work I guess.
>>>
>> Is MinGW finding open, filesize ? When building a static library there
>> is no verification at all if functions really exist.
>> Enter
>> size = whatever(file);
>> and build your static library. You don't get any errors. Only when
>> linking the final executable it will start looking for 'whatever'.
>>
>> In C you don't have to prototype functions. The compiler just assumes an
>> extern int if the function is not defined in the source or an header
>> file and leaves it up to the linker to sort it out. Or worse, lets your
>> program crash if the function exists but has a different parameter list
>> or does not return an int. Welcome to the joys of programming in C ;)
>>
> Yes it does find them, the statically libraries are linked into an executable which works fine. That is why I was surprised. I'm sure MinGW must link to other libraries as well. The question though is which. Anyway to find out for a simple example project executable?

http://www.dependencywalker.com/
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Statically link library

Darius Blaszyk

On Apr 26, 2013, at 1:37 AM, Paul Breneman wrote:

>>>
>> Yes it does find them, the statically libraries are linked into an executable which works fine. That is why I was surprised. I'm sure MinGW must link to other libraries as well. The question though is which. Anyway to find out for a simple example project executable?
>
> http://www.dependencywalker.com/
> _______________________________________________
>
Will have a look, although at first sight it seems to find dynamic libraries. I need to check the static ones as well.

Regards, Darius

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Statically link library

Ludo Brands
On 04/26/2013 09:54 AM, Darius Blaszyk wrote:

>
> On Apr 26, 2013, at 1:37 AM, Paul Breneman wrote:
>
>>>>
>>> Yes it does find them, the statically libraries are linked into an executable which works fine. That is why I was surprised. I'm sure MinGW must link to other libraries as well. The question though is which. Anyway to find out for a simple example project executable?
>>
>> http://www.dependencywalker.com/
>> _______________________________________________
>>
> Will have a look, although at first sight it seems to find dynamic libraries. I need to check the static ones as well.
>

Pass -M or --print-map to ld to get a memory map. It includes all object
files included.

Ludo
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Statically link library

Ludo Brands
On 04/26/2013 10:19 AM, Ludo Brands wrote:

>
> Pass -M or --print-map to ld to get a memory map. It includes all object
> files included.
>
On my system it shows that open and close are from
MinGW32/lib/libmoldname.a
and a
 undefined reference to `filesize'

Ludo

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal