RE: FAQ for portability issues?

	Free Downloads, Community Forum, FAQs and Developer Resources

Make /Tools Your Home | Link to us

Today's posts | Posts since last visit | Most Active Topics

All Forums	Register	Login	Search	Subscriptions	My Profile	Inbox
Tool Warehouse	FAQs	Resources	Help	Member List	Address Book	Logout

RE: FAQ for portability issues?

Logged in as: Guest

Users viewing this topic: none

Printable Version

All Forums >> [SFU / Interix / SUA Technology] >> Interix Advanced Forum >> RE: FAQ for portability issues?

Page: << < prev 1 [2] 3 next > >>

Message

<< Older Topic Newer Topic >>

RE: FAQ for portability issues? - Sep. 24, '06, 1:44:48 PM

Rodney

Posts: 3695
Joined: Jul. 9, '02,
From: /Tools lab
Status: offline

> Where is arc4random()?

It's in the /Tools version of libcrypt.
So "-L/usr/local/lib -lcrypt".
The MS version of libcrypt gets arc4random in Vista I think.

> #include <inttypes.h>
>1. Are there plans to add that to libport?

Funny you should ask that... I just hit that a couple days ago.
It's a slippery slope for me to start since this is c99 stuff.
"Slippery" in the sense that there are several of these files.
Can do it on s "as we go" sort-of thing more easily.

> 2. obstack.{c,h} would also be nice to have.

I'll look into it.

> 3. in 1.1.8 I found the strnlen symbol, but the header is not there.

Actually it is. You need to include the libport headers first.
So "-I/usr/include/port" and then "-I/usr/local/include".
The libport headers wrap in new stuff and then include the
system headers.

< Message edited by Rodney -- Sep. 24, '06, 7:44:58 PM >

(in reply to mkoeppe)

Post #: 21

RE: FAQ for portability issues? - Sep. 24, '06, 6:23:05 PM

mkoeppe

Posts: 43
Joined: Dec. 8, '05,
Status: offline

Hi Rodney,

arc4random: It's already in SFU 3.5 original libcrypt.a, now as I looked into it. Thanks for the hint.
strnlen: I grepped through all .h files in the libport 1.1.8 package, but didn't find it

(in reply to Rodney)

Post #: 22

RE: FAQ for portability issues? - Sep. 24, '06, 9:06:08 PM

Rodney

Posts: 3695
Joined: Jul. 9, '02,
From: /Tools lab
Status: offline

I've rolled the version to 1.1.9 and added an <inttypes.h>.
There's a <string.h> in this version for strnlen().

(in reply to mkoeppe)

Post #: 23

RE: FAQ for portability issues? - Sep. 26, '06, 5:35:33 PM

mkoeppe

Posts: 43
Joined: Dec. 8, '05,
Status: offline

Hi Rodney,

why did you disable uint64_t for gcc in inttypes.h?

#ifndef __GNUC__
typedef u_quad_t        uint64_t;
#endif  /* __GNUC__ */

I enabled it without problems so far.

(in reply to Rodney)

Post #: 24

RE: FAQ for portability issues? - Sep. 26, '06, 5:58:29 PM

mkoeppe

Posts: 43
Joined: Dec. 8, '05,
Status: offline

I encountered another portability issue:

5. (to continue the numbering from the first post) While building GNU findutils-4.2.28 (because of its options such as "find -printf") configure complains. I tried without and with libport, same result:

[...]
checking for listmntent... no
checking for getmntinfo... no
checking for sys/ucred.h... no
checking for sys/mount.h... no
checking mntent.h usability... no
checking mntent.h presence... no
checking for mntent.h... no
checking sys/fs_types.h usability... no
checking sys/fs_types.h presence... no
checking for sys/fs_types.h... no
checking for struct fsstat.f_fstypename... no
checking for library containing getmntent... none required
checking for getmntent... yes
checking for listmntent of Cray/Unicos-9... no
checking for mntctl function and struct vmount... no
checking for one-argument getmntent function... no
checking for two-argument getmntent function... no
checking for getfsstat function... no
checking for FIXME existence of three headers... no
checking for getmntinfo function... no
checking for getmnt function... no
checking for next_dev... no
checking for fs_stat_dev... no
checking fs_info.h usability... no
checking fs_info.h presence... no
checking for fs_info.h... no
checking for BEOS mounted file system support functions... no
checking whether it is possible to resort to fread on /etc/mnttab... no
configure: error: could not determine how to read list of mounted file systems
[...]

I'm not yet that familiar with autoconf, so I would be grateful if someone could help me to disable this test in the hope that it is not essential for find.
Even better would be of course to give find what it wants to have ...

(in reply to mkoeppe)

Post #: 25

RE: FAQ for portability issues? - Sep. 26, '06, 6:13:54 PM

Rodney

Posts: 3695
Joined: Jul. 9, '02,
From: /Tools lab
Status: offline

> why did you disable uint64_t for gcc in inttypes.h?

I had gcc complaining that it was already done in <sys/types.h>.
But *cough*cough* I see that was an addition I made.
So I'll undo that for the next release.

(in reply to mkoeppe)

Post #: 26

RE: FAQ for portability issues? - Sep. 26, '06, 6:25:22 PM

Rodney

Posts: 3695
Joined: Jul. 9, '02,
From: /Tools lab
Status: offline

It's looking for getfsstat(), etc. which are non-portable API's.
The closest portable API is statvfs() [which is near identical to the old statfs()].

Anyway, you'll see that the structure used for getfsstat() is the same as statfs().
So a wrapper function can straight-forwardly be made of getfsstat() using statvfs().
This is seeming familiar... perhaps I already did this for find(1) before...
I'll go look.

(in reply to Rodney)

Post #: 27

RE: FAQ for portability issues? - Sep. 26, '06, 6:31:38 PM

Rodney

Posts: 3695
Joined: Jul. 9, '02,
From: /Tools lab
Status: offline

Not find; it was df that has similar code.
But it'll take a while to morph it to the "older" structure to make it useful.
Another "slippery slope" of one API means several.

(in reply to Rodney)

Post #: 28

RE: FAQ for portability issues? - Sep. 27, '06, 6:52:04 PM

mkoeppe

Posts: 43
Joined: Dec. 8, '05,
Status: offline

In which (source) package is df? Or, where can I find it?

(in reply to Rodney)

Post #: 29

RE: FAQ for portability issues? - Sep. 27, '06, 7:53:56 PM

mkoeppe

Posts: 43
Joined: Dec. 8, '05,
Status: offline

Hi Rodney,

another thing with libport and inttypes.h:
In C++ mode, i.e. #ifdef __cplusplus you added just a pair of "{}". This didn't work for me, so I removed the #ifdef. extern "C" is not necessary here either, with just typedefs.

And maybe there should be a stdint.h, too. I have a case where configure checks for inttypes.h as well as stdint.h, but then there is an unconditioned #include <stdint.h>

. A symlink to inttypes.h was ok in this case.

(in reply to Rodney)

Post #: 30

RE: FAQ for portability issues? - Sep. 27, '06, 8:07:24 PM

mkoeppe

Posts: 43
Joined: Dec. 8, '05,
Status: offline

Just another bug in

/usr/include/port/sys/stat.h:

#endif /* __cplusplus */

should be before

#ifdef _USE_LIBPORT

(in reply to mkoeppe)

Post #: 31

RE: FAQ for portability issues? - Sep. 27, '06, 10:17:58 PM

Rodney

Posts: 3695
Joined: Jul. 9, '02,
From: /Tools lab
Status: offline

> In which (source) package is df? Or, where can I find it?

It was never released. I'd written it for my own amusement to replicate what
I'd done while at Softway. I used it for comparision with the Vista update.
I've actually written 5 new functions for libport which'll come out
later tonight or tomorrow: statfs, getfsinfo, getmntinfo, getvfsinfo & getvmntinfo.

Thanks for the feedback on the changes.
I'll make adjustments to the stat.h file. The inttypes.h is an awkward thing
because version 5.2 and 6.0 have their own versions -- trying to avoid clashes.

(in reply to mkoeppe)

Post #: 32

RE: FAQ for portability issues? - Sep. 29, '06, 5:56:31 PM

mkoeppe

Posts: 43
Joined: Dec. 8, '05,
Status: offline

Thank you, Rodney. Now I could successfully build GNU find / xargs!

However, I needed the following #defines, sponsored by google, so I'm not sure if the values are correct:

sys/mount.h:

/*
 * Flags for various system call interfaces.
 *
 * waitfor flags to vfs_sync() and getfsstat()
 */
#define MNT_WAIT        1       /* synchronously wait for I/O to complete */
#define MNT_NOWAIT      2       /* start all I/O, but do not wait for it */
#define MNT_LAZY        3       /* push data not written by filesystem syncer */

(in reply to Rodney)

Post #: 33

RE: FAQ for portability issues? - Sep. 29, '06, 8:07:26 PM

Rodney

Posts: 3695
Joined: Jul. 9, '02,
From: /Tools lab
Status: offline

You're welcome.
Right, those three for right now will all get #define'd to 0 (zero) to show they're not
actually doing anything right now.
I'll push these out at the next update in a couple of days.

(in reply to Rodney)

Post #: 34

RE: FAQ for portability issues? - Oct. 3, '06, 1:16:53 PM

mkoeppe

Posts: 43
Joined: Dec. 8, '05,
Status: offline

Hi Rodney,

today I found missing typedefs in inttypes.h or maybe stdint.h. I copied these from glibc's stdint.h:

/* Largest integral types.  */
#if __WORDSIZE == 64
typedef long int                intmax_t;
typedef unsigned long int       uintmax_t;
#else
__extension__
typedef long long int           intmax_t;
__extension__
typedef unsigned long long int  uintmax_t;
#endif

Furthermore, I could need strtoull and strtoll in libport.

(in reply to Rodney)

Post #: 35

RE: FAQ for portability issues? - Oct. 3, '06, 1:58:13 PM

markfunk

Posts: 669
Joined: Mar. 31, '03,
Status: offline

quote:

I could need strtoull and strtoll in libport.

These are known as
strtouq and strtoq in /usr/lib/libc.a

(in reply to mkoeppe)

Post #: 36

RE: FAQ for portability issues? - Oct. 3, '06, 2:02:18 PM

Rodney

Posts: 3695
Joined: Jul. 9, '02,
From: /Tools lab
Status: offline

> Furthermore, I could need strtoull and strtoll in libport.

Use strtoq() and strtouq() instead.
These functions are in libc, but the prototypes are missing.
mmm, I thought I'd had a patch for this already... I'll go look.

> today I found missing typedefs in inttypes.h or maybe stdint.h. I copied these from glibc's stdint.h:

You can copy from GPL/LGPL, but I won't -- that's a dangerous licencing issue.
Besides that, it needs to be more portable so that other compilers can use it other than gcc.
The SUS standard isn't looking for these types in inttypes.h, but I will look at SUS stdint.h to
see what's there (I'm not looking at GPL/LGPL code for this or anything else to go into libport).

(in reply to mkoeppe)

Post #: 37

RE: FAQ for portability issues? - Oct. 3, '06, 3:13:29 PM

Rodney

Posts: 3695
Joined: Jul. 9, '02,
From: /Tools lab
Status: offline

On the ftp site is now the package patch_stdint_h which will patch
the <stdlib.h> file on Interix 3.5 and 5.2 as needed. 5.2 already has the
prototypes for strtoq() and strtouq().
You will need to do "-D_ALL_SOURCE" to pick up the guarded additions.
The lib_port package I'll have depend on this package next release.

pkg_update -L patch_stdint_h

(in reply to Rodney)

Post #: 38

RE: FAQ for portability issues? - Oct. 3, '06, 5:57:45 PM

mkoeppe

Posts: 43
Joined: Dec. 8, '05,
Status: offline

Thank you again for the fast reaction, it now works for me!
But shouldn't the patch be named patch_stdlib_h?

(in reply to Rodney)

Post #: 39

RE: FAQ for portability issues? - Oct. 3, '06, 7:23:49 PM

Rodney

Posts: 3695
Joined: Jul. 9, '02,
From: /Tools lab
Status: offline

> But shouldn't the patch be named patch_stdlib_h?

arrhhhggg

That's what I get for doing two things at once: reading the standard on <stdint.h>
while making & testing a patch for <stdlib.h>.
Renaming it now to "patch_stdlib_h"... done.

Do a "pkg_delete -M patch_stdint_h" and then do a "patch_stdlib_h".
This will clear it up. Thanks for pointing that out.

(in reply to mkoeppe)