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

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.

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

In our previous episode, Vittorio Giovara said:

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

'ld', and of course adjust all the flags.

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

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

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

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.

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.

<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

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 -

http://lists.freepascal.org/mailman/listinfo/fpc-pascal [1]

Links:
------
[1]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

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

<snip>

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

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

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

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

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

Ludo

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