Hi,

I know the 'libc' unit is for linux-x86 only. Does that also exclude 64-bit Linux?

If so, how can I IFDEF code that needs to run on Linux (32 & 64 bit) and FreeBSD (32 & 64 bit) when 'libc' only works on Linux and 32-bit systems. Clearly this code smells, so I should actually find a alternative solution and get rid of libc altogether.

I've tried the following, but don't know how to distinguish between 32-bit and 64-bit linux. The code is not critical, so if there isn't a solution, I can always trash that code.

eg:

 uses
   ....snip....
  {$IFDEF UNIX}
    {$IFDEF LINUX},libc{$ENDIF}
  ,baseunix
  {$ENDIF}
  ;

The above compiles under Linux and FreeBSD 32-bit, but fails under Linux 64-bit because of missing 'libc'. All compiling is done with FPC 2.2.0

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Op Thu, 31 Jan 2008, schreef Graeme Geldenhuys:

Hi, I know the 'libc' unit is for linux-x86 only. Does that also exclude 64-bit Linux?

Correct. 64-bit safeness is one thing the Kylix libc unit was not designed for.

If so, how can I IFDEF code that needs to run on Linux (32 & 64 bit)

{$if defined(linux) and defined(i386)}

Daniël

I know the 'libc' unit is for linux-x86 only. Does that also exclude 64-bit Linux?

Yes.

If so, how can I IFDEF code that needs to run on Linux (32 & 64 bit) and FreeBSD (32 & 64 bit) when 'libc' only works on Linux and 32-bit systems.

Something like

{$ifdef cpu386}
{$ifdef linux}
{$define linux386}
{$endif}
{$endif}

Clearly this code smells, so I should actually find a alternative solution and get rid of libc altogether.

Yes, that's what baseunix and unix are ( and sockets,termio,syscalls etc).

It is not complete by far, but it is getting there. If I can get the "users" package cleaned up, some more reasons to use unit libc disappear.

This also because mixing units can lead to problems since they are separate collections of types.

Wow you guys reply quickly. :) The above code doesn't look nice either, so I think I will rather implement a alternative.

All I really use 'libc' for is to retrieve the user name and group name from the user and group id's of files. As I said, it's not critical, I can always display the id's only. Or maybe parse the /etc/groups and /etc/passwd files to get the names, but I heard that's not very accurate for some reason.

Thanks again Marco and Daniël for the quick replies!

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Op Thu, 31 Jan 2008, schreef Graeme Geldenhuys:

Rather than use the libc unit, you might want to declare getpwent in your own code; a few naming service procedures are a whole lot easier to keep portable than the entire libc unit.

This doesn't guarantee you anything (getpwent could well be a macro on a random unix), but it wouldn't be that much work to make it work on the known Unixes.

Daniël

Op Thu, 31 Jan 2008, schreef Graeme Geldenhuys: > Wow you guys reply quickly. :) The above code doesn't look nice > either, so I think I will rather implement a alternative.

(Daniel's is better, I still have the habit to make 1.0.x compat defines, while not necessary anymore)

If 2.3.1 for Linux one can probably use package users. I plan to update this coming weekend to BSD compability. (the group part is mostly done already).

Afaik 2.2.0 has this package too, but it wasn't compiled till the recent package restructure (Which will be merged to 2.2 in the coming weeks somewhere)

This doesn't guarantee you anything (getpwent could well be a macro on a random unix),

Not uncommon even, since some only have the _r variant iirc.

but it wouldn't be that much work to make it work on the known Unixes.

Better focus that to an area where all benefit. This abstraction is simple to do, and often needed. However all people till now blindly grab libc or hack their own, and refuse to invest time in the general units.

I hope that the reviving of the (Michael abandonware) users package will start this proces.

Just to let you know Daniël, that doesn't work for Linux 32-bit systems, but the idea is correct. It should read.

{$if defined(linux) and defined(cpu386)}

Thanks again...

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Really the only reliable way to get that information is to link with libc. Reading the files in /etc will work on a basic system but will fail if an alternate authentication system is in use.

peter green wrote

Really the only reliable way to get that information is to link with libc. Reading the files in /etc will work on a basic system but will fail if an alternate authentication system is in use.

Yup, that's what somebody else told me as well. I must look at the GTK 1.2 file dialog's code to see what they did to overcome that issue. Otherwise simply show directories and file names only in the fpGUI File Dialog.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/