Nano-x

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

Nano-x

Carsten Bager
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

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

Re: Nano-x

Michael Van Canneyt


On Thu, 20 Jul 2006, Carsten Bager wrote:

> 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

You need to link to the C library as well.

So, add

{$linklib c}

to your sources.

Michael.

> -----------------
>
> 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
>
> _______________________________________________
> 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
Reply | Threaded
Open this post in threaded view
|

Re: Nano-x

Marco van de Voort
>
> You need to link to the C library as well.
>
> So, add
>
> {$linklib c}

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

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

Re: Nano-x

Michael Van Canneyt


On Thu, 20 Jul 2006, Marco van de Voort wrote:

>>
>> You need to link to the C library as well.
>>
>> So, add
>>
>> {$linklib c}
>
> _Never_ add linklib c or linklib gcc directly, always work via unit initc.
> That's what it is for.

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

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

Re: Nano-x

Marco van de Voort
> On Thu, 20 Jul 2006, Marco van de Voort wrote:
>
> >>
> >> You need to link to the C library as well.
> >>
> >> So, add
> >>
> >> {$linklib c}
> >
> > _Never_ add linklib c or linklib gcc directly, always work via unit initc.
> > That's what it is for.
>
> I thought the compiler did this automatically when it detects a link to
> the C library ?

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

Re: Nano-x

Michael Van Canneyt


On Thu, 20 Jul 2006, Marco van de Voort wrote:

>> On Thu, 20 Jul 2006, Marco van de Voort wrote:
>>
>>>>
>>>> You need to link to the C library as well.
>>>>
>>>> So, add
>>>>
>>>> {$linklib c}
>>>
>>> _Never_ add linklib c or linklib gcc directly, always work via unit initc.
>>> That's what it is for.
>>
>> I thought the compiler did this automatically when it detects a link to
>> the C library ?
>
> 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.

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

Re: Nano-x

Marco van de Voort
> On Thu, 20 Jul 2006, Marco van de Voort wrote:
> > (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.
>
> 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...

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

Re: Nano-x

Michael Van Canneyt


On Thu, 20 Jul 2006, Marco van de Voort wrote:

>> On Thu, 20 Jul 2006, Marco van de Voort wrote:
>>> (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.
>>
>> 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...
>
> Because?

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

Re: Nano-x

Marco van de Voort
> On Thu, 20 Jul 2006, Marco van de Voort wrote:
> >> 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...
> >
> > Because?
>
> Because firstly I think that what initc does behind the scenes should not
> be done in the first place,

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.

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

Re: Nano-x

Michael Van Canneyt


On Thu, 20 Jul 2006, Marco van de Voort wrote:

>> On Thu, 20 Jul 2006, Marco van de Voort wrote:
>>>> 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...
>>>
>>> Because?
>>
>> Because firstly I think that what initc does behind the scenes should not
>> be done in the first place,
>
> What, provide access to libc errno?

Yes.

>
>> 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.

The difference is minor.

>
>> {$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,

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

> 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.

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

Re: Nano-x

Marco van de Voort

(snip water under the bridge)
 

> 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.
 
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?
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Nano-x

Carsten Bager
In reply to this post by Marco van de Voort
 > 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

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

Re: Nano-x

Michael Van Canneyt
In reply to this post by Marco van de Voort


On Thu, 20 Jul 2006, Marco van de Voort wrote:

>
> (snip water under the bridge)
>
>> 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.
>
> What compiler code exactly do you mean? Cprt stuff?

Yes.

>
>> 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?

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

Re: Nano-x

Michael Van Canneyt
In reply to this post by Carsten Bager


On Thu, 20 Jul 2006, Carsten Bager wrote:

> > 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?

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

Re: Nano-x

Marco van de Voort
In reply to this post by Carsten Bager
> 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.

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

Re: Nano-x

Carsten Bager
In reply to this post by Michael Van Canneyt
>
> On Thu, 20 Jul 2006, Carsten Bager wrote:
>
> > > 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?
>
> 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 ?

The libc is from an embedded Arm Linux.

Carsten

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

Re: Nano-x

Michael Van Canneyt


On Thu, 20 Jul 2006, Carsten Bager wrote:

>>
>> On Thu, 20 Jul 2006, Carsten Bager wrote:
>>
>>>> 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?
>>
>> 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 ?
>
> The libc is from an embedded Arm Linux.

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

Re: Nano-x

Carsten Bager
In reply to this post by Marco van de Voort
> 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



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

Re: Nano-x

Marco van de Voort
> > 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?

objdump a helloworld C program, and investigate.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal