I am trying to write a small program using the nano-x library.

-----------------
Unit NanoX;
interface
{$mode objfpc}
Const
  LibNanoX='nano-X';
function GrOpen:longint;cdecl;external LibNanoX;
implementation
end.

------------------

program Nanoxdemo;

uses

 NanoX,linux,sysutils;
begin
  if GrOpen < 0 then
    WriteLn('Can not open graphics')
  else WriteLn('Graphics open');
end.

When linking, I get a lot of errors like this
-----------------

Linking nanoxdemo
L:\Pas\ReleasedUnits\LibArm9\/libnano-X.so: undefined reference to `strcpy'
L:\Pas\ReleasedUnits\LibArm9\/libnano-X.so: undefined reference to `ioctl' L:\Pas\ReleasedUnits\LibArm9\/libnano-X.so: undefined reference to `stdout'
L:\Pas\ReleasedUnits\LibArm9\/libnano-X.so: undefined reference to `vsprintf'
L:\Pas\ReleasedUnits\LibArm9\/libnano-X.so: undefined reference to `connect'
L:\Pas\ReleasedUnits\LibArm9\/libnano-X.so: undefined reference to `munmap'
L:\Pas\ReleasedUnits\LibArm9\/libnano-X.so: undefined reference to `getenv'
L:\Pas\ReleasedUnits\LibArm9\/libnano-X.so: undefined reference to `getpid'
L:\Pas\ReleasedUnits\LibArm9\/libnano-X.so: undefined reference to `getpagesize'
L:\Pas\ReleasedUnits\LibArm9\/libnano-X.so: undefined reference to `fgets' L:\Pas\ReleasedUnits\LibArm9\/libnano-X.so: undefined reference to `memcpy'
L:\Pas\ReleasedUnits\LibArm9\/libnano-X.so: undefined reference to `__floatsidf'
L:\Pas\ReleasedUnits\LibArm9\/libnano-X.so: undefined reference to `puts' L:\Pas\ReleasedUnits\LibArm9\/libnano-X.so: undefined reference to `feof' L:\Pas\ReleasedUnits\LibArm9\/libnano-X.so: undefined reference to `malloc'
L:\Pas\ReleasedUnits\LibArm9\/libnano-X.so: undefined reference to `__udivsi3'
L:\Pas\ReleasedUnits\LibArm9\/libnano-X.so: undefined reference to `socket'
L:\Pas\ReleasedUnits\LibArm9\/libnano-X.so: undefined reference to `select'
L:\Pas\ReleasedUnits\LibArm9\/libnano-X.so: undefined reference to `mmap'
L:\Pas\ReleasedUnits\LibArm9\/libnano-X.so: undefined reference to `alarm'
L:\Pas\ReleasedUnits\LibArm9\/libnano-X.so: undefined reference to `nanosleep'
L:\Pas\ReleasedUnits\LibArm9\/libnano-X.so: undefined reference to `calloc'
L:\Pas\ReleasedUnits\LibArm9\/libnano-X.so: undefined reference to `__fixdfsi'
L:\Pas\ReleasedUnits\LibArm9\/libnano-X.so: undefined reference to `write' L:\Pas\ReleasedUnits\LibArm9\/libnano-X.so: undefined reference to `fprintf'
L:\Pas\ReleasedUnits\LibArm9\/libnano-X.so: undefined reference to `__umodsi3'
L:\Pas\ReleasedUnits\LibArm9\/libnano-X.so: undefined reference to `ferror'
L:\Pas\ReleasedUnits\LibArm9\/libnano-X.so: undefined reference to `signal'
L:\Pas\ReleasedUnits\LibArm9\/libnano-X.so: undefined reference to `read' L:\Pas\ReleasedUnits\LibArm9\/libnano-X.so: undefined reference to `realloc'
L:\Pas\ReleasedUnits\LibArm9\/libnano-X.so: undefined reference to `sscanf'
L:\Pas\ReleasedUnits\LibArm9\/libnano-X.so: undefined reference to `__divdf3'
L:\Pas\ReleasedUnits\LibArm9\/libnano-X.so: undefined reference to `__muldf3'
L:\Pas\ReleasedUnits\LibArm9\/libnano-X.so: undefined reference to `fopen'
L:\Pas\ReleasedUnits\LibArm9\/libnano-X.so: undefined reference to `fclose'
L:\Pas\ReleasedUnits\LibArm9\/libnano-X.so: undefined reference to `stderr'
L:\Pas\ReleasedUnits\LibArm9\/libnano-X.so: undefined reference to `fwrite' L:\Pas\ReleasedUnits\LibArm9\/libnano-X.so: undefined reference to `__errno_location'
L:\Pas\ReleasedUnits\LibArm9\/libnano-X.so: undefined reference to `exit' L:\Pas\ReleasedUnits\LibArm9\/libnano-X.so: undefined reference to `setbuf'
L:\Pas\ReleasedUnits\LibArm9\/libnano-X.so: undefined reference to `strlen'
L:\Pas\ReleasedUnits\LibArm9\/libnano-X.so: undefined reference to `open' L:\Pas\ReleasedUnits\LibArm9\/libnano-X.so: undefined reference to `__assert'
L:\Pas\ReleasedUnits\LibArm9\/libnano-X.so: undefined reference to `__subdf3'
L:\Pas\ReleasedUnits\LibArm9\/libnano-X.so: undefined reference to `close' L:\Pas\ReleasedUnits\LibArm9\/libnano-X.so: undefined reference to `free' nanoxdemo.pas(10,31) Error: Error while linking

-------------

Some of the names are in the libc library, witch is present, others are in libraries witch I do not have on the compiling PC (cross compiling from Windows to Arm Linux).

What do I have to do to get moving?

Carsten

_Never_ add linklib c or linklib gcc directly, always work via unit initc. That's what it is for.

You need to link to the C library as well.

So, add

{$linklib c}

to your sources.

Michael.

I thought the compiler did this automatically when it detects a link to the C library ?

Michael.

Not that I know. It mostly is useful so that you don't have to change seventy headers if the name of libc changes on some platform, to potentially polish away issues with dependancies on certain sublibraries (libdl,libgettext,libgcc), and to encapsulate libc errno access.

There shouldn't be a {$linklib C or linklib gcc in any unit. _always_ via unit initc.

Because?

If you really believe that:
I suggest you start working on the sources in SVN then, because there are _a lot_ of them.

But I don't think that it should be done like that...

Michael.

Because firstly I think that what initc does behind the scenes should not be done in the first place, and secondly because the argument of the varying library name you have countered yourself with your implementation of link aliases.

{$Linklib C} does just that: it links to the C library, i.e. makes available some additional symbols. Initc also does some redirection of 'errno' handling (be it the C or pascal version), which is totally uncalled for if you for example need only sprintf()...

It's a tough issue, and it's a matter of preference, I'd say, but personally, I will not use initc as a rule...

Michael.

What, provide access to libc errno?

and secondly because the argument of the varying library name you have countered yourself with your implementation of link aliases.

I don't see that. Linkaliases are to provide the flexability to override the default if that must be necessary after release. initc sets the default libc name for a certain platform. Two different things.

{$Linklib C} does just that: it links to the C library, i.e. makes available some additional symbols. Initc also does some redirection of 'errno' handling (be it the C or pascal version), which is totally uncalled for if you for example need only sprintf()...

If the two handlers for that aren't called, the whole stuff can be smartlinked out. No problem here.

It's a tough issue, and it's a matter of preference, I'd say, but personally, I will not use initc as a rule...

IMHO this was all already discussed in the unix reforms, but as a detail it might have been forgotten. I don't like this backpedalling. Moreover IMHO there is no merit in the redundant $linklibs.

Sooner or later sb will use a uclibc or msvcrt as basis for a headerset, and the redundant ifdeffing will begin. Also there is the little issue for sometimes need {$linklib gcc}, we now haphazardly fixed for libgdb only. This kind of issues can also be changed centrally in initc.

I'm afraid this kind of narrow thinking will in time result in the header sets working on the top 2 tier platforms, and constantly be out of date for the rest, simply because for each odd ball platform, it must be checked by the maintainer (that must then have all the libs to notice). Bad.

Yes.

The difference is minor.

I'm not disputing your statement, but I have absolutely no recollection of this, and I followed the matter closely, as you well know.

Please don't use terms as 'this kind of narrow thinking' which places an element of emotionality in what is a purely technical discussion; It clouds people's judgement.

As for your arguments:

You are 100% right that it may be a good thing to have a central place which somehow regulates access to libc; It will make things clearer and more maintainable. However, if you want to position it like that, I do think that it should be handled like that: The unit which provides the correct glue to the C library, which we can say is the preferred way of linking to the C library. I would even go as far as saying that in this case, the program/library stub code can be placed in this unit. It would remove a lot of code which is now in the compiler.

It should, however, not be positioned as the replacement of {$linklib C}; This decision should always be made by the programmer. It is up to us to decide what to do with the units we distribute by default.

So, my conclusion is that we should take the following actions:

1. Finish the job in InitC, and make it truly a cross-platform unit. Currently it's full of ifdefs, this should be replaced with a platform-dependent initc.inc and a global, cross-platform initc.pp

2. Possibly extend it with some constants that describe properties of the libc in use.

3. Replace where possible and appropriate the {$linklib C} with a uses initc;

4. Put a section in the programmers's guide which describes the use of it, because it is rather important.

Michael.

(snip water under the bridge)

What compiler code exactly do you mean? Cprt stuff?

It should, however, not be positioned as the replacement of {$linklib C}; This decision should always be made by the programmer. It is up to us to decide what to do with the units we distribute by default.

That + the formal advise to do it that way, with the reasons I posted earlier is fine with me.

So, my conclusion is that we should take the following actions: 2. Possibly extend it with some constants that describe properties of the libc in use.

Agree (also with the other points). However do you have examples of this?

You need to link to the C library as well.

When I use initc I get thise errors

Linking nanoxdemo
L:\Lib\fpc202\arm-linux\cprt0.o: In function `_start': : undefined reference to `__libc_start_main'
L:\Lib\fpc202\arm-linux\cprt0.o: In function `_haltproc' : undefined reference to `_fini'
L:\Lib\fpc202\arm-linux\cprt0.o: In function `_haltproc' : undefined reference to `_init'

I can see (in the map file) that the linker pulls cprt0 (instead of prt0) and cprt0 calls "__libc_start_main", "_fini" and "_init". As you can see these functions are not in the clib on my platform. Is there a way around?

Carsten

Yes.

At least
- the name.
- A constant describing whether errno is thread-safe etc.
- It is gnu libc. ? (with all it's peculiarities)
- Is libgcc linked in ?
- Does it provide threading by default ?
In short, stuff which might be important to know when dealing with libc...

Compare it to the t_systems records in the compiler.

Michael.

No. But this has nothing to do with initc, just with the fact that you use a C lib; Strange though, because the arm-linux libc has this. What libc did you use for linking ?

Michael.

These are no problems of initc, but cprt0.as which still assumes you are using glibc (though most of those symbols are fairly general for libcs)

Is there a way around?

Patch cprt0.as for your libc.

The libc is from an embedded Arm Linux.

Carsten

This is not gnu libc ?

That means a crpt0.as must be created for this particular libc.

(exactly one of the reasons why I think crpt code should be in initc.pp)

Michael.

Patch cprt0.as for your libc.

The libc that my platform is using is micro libc, and unfortunately the micro libc is
initialized the same way as libc.
Does anyone have a hint?

Carsten

objdump a helloworld C program, and investigate.