stat.h

stat.h

[Paul Schutte]

[-- Attachment #1: Type: text/plain, Size: 853 bytes --]

Hi,

I am trying to compile pulseaudio5 against musl, but it fails with an error
indicating that struct stat64 is not defined:

utils/padsp.c:133:44: warning: 'struct stat64' declared inside parameter
list [enabled by default]
utils/padsp.c:133:44: warning: its scope is only this definition or
declaration, which is probably not what you want [enabled by default]

When I hack a bit and change the include in <sys/stat.h> from <bits/stat.h>
to <asm/stat.h>, it compiles that part, but fails some where else :

modules/module-augment-properties.c:187:15: error: 'struct stat' has no
member named 'st_mtim'
modules/module-augment-properties.c:198:18: error: 'struct stat' has no
member named 'st_mtim'
make[3]: ***
[modules/module_augment_properties_la-module-augment-properties.lo] Error 1


What is the correct way to fix this problem ?


Regards
Paul

[-- Attachment #2: Type: text/html, Size: 1095 bytes --]

Re: stat.h

[Szabolcs Nagy]

* Paul Schutte <sjpschutte@gmail.com> [2014-03-03 20:36:24 +0200]:
> I am trying to compile pulseaudio5 against musl, but it fails with an error
> indicating that struct stat64 is not defined:
> 
> utils/padsp.c:133:44: warning: 'struct stat64' declared inside parameter
> list [enabled by default]
> utils/padsp.c:133:44: warning: its scope is only this definition or
> declaration, which is probably not what you want [enabled by default]
> 

last time i checked padsp was hopelessly broken
(it tries to emulate /dev/dsp etc by overriding
internal glibc functions with code that is not
even compatible with the glibc api requirements)

alsa-oss has a similar mess

Re: stat.h

[Paul Schutte]

[-- Attachment #1: Type: text/plain, Size: 963 bytes --]

Thanks and I agree with padsp being messy.

My question really boils down to
Should 'struct stat64' be used from within a program and if so, which
header file should I include ?

Regards
Paul


On Mon, Mar 3, 2014 at 9:42 PM, Szabolcs Nagy <nsz@port70.net> wrote:

> * Paul Schutte <sjpschutte@gmail.com> [2014-03-03 20:36:24 +0200]:
> > I am trying to compile pulseaudio5 against musl, but it fails with an
> error
> > indicating that struct stat64 is not defined:
> >
> > utils/padsp.c:133:44: warning: 'struct stat64' declared inside parameter
> > list [enabled by default]
> > utils/padsp.c:133:44: warning: its scope is only this definition or
> > declaration, which is probably not what you want [enabled by default]
> >
>
> last time i checked padsp was hopelessly broken
> (it tries to emulate /dev/dsp etc by overriding
> internal glibc functions with code that is not
> even compatible with the glibc api requirements)
>
> alsa-oss has a similar mess
>

[-- Attachment #2: Type: text/html, Size: 1441 bytes --]

Re: stat.h

[Rich Felker]

On Tue, Mar 04, 2014 at 06:15:01AM +0200, Paul Schutte wrote:
> Thanks and I agree with padsp being messy.
> 
> My question really boils down to
> Should 'struct stat64' be used from within a program and if so, which
> header file should I include ?

If you want "struct stat64", make sure _GNU_SOURCE or
_LARGEFILE64_SOURCE is defined before including any system headers
(best way is with -D_GNU_SOURCE etc. in your CFLAGS) and include
sys/stat.h. However, it would be better to just use "struct stat",
etc. (With glibc, you need -D_FILE_OFFSET_BITS=64 in your CFLAGS to
make this work right; with musl it always works.)

Rich

Re: stat.h

[Paul Schutte]

[-- Attachment #1: Type: text/plain, Size: 1393 bytes --]

Hi

Hope I am not too anoying ... ;-)

I have tried both _GNU_SOURCE and _LARGEFILE64_SOURCE and in neither case
do I get a definition for 'struct stat64'

If I understand correctly then source using 'struct stat64' should be fixed
to use 'struct stat' instead ?
If this is not correct, then 'struct stat64' should probably be added to
<sys/stat.h> as only the following are defined there:

#if defined(_LARGEFILE64_SOURCE) || defined(_GNU_SOURCE)
#define stat64 stat
#define fstat64 fstat
#define lstat64 lstat
#define fstatat64 fstatat
#define blksize64_t blksize_t
#define blkcnt64_t blkcnt_t
#define ino64_t ino_t
#define off64_t off_t
#endif

Regards
Paul



On Tue, Mar 4, 2014 at 6:20 AM, Rich Felker <dalias@aerifal.cx> wrote:

> On Tue, Mar 04, 2014 at 06:15:01AM +0200, Paul Schutte wrote:
> > Thanks and I agree with padsp being messy.
> >
> > My question really boils down to
> > Should 'struct stat64' be used from within a program and if so, which
> > header file should I include ?
>
> If you want "struct stat64", make sure _GNU_SOURCE or
> _LARGEFILE64_SOURCE is defined before including any system headers
> (best way is with -D_GNU_SOURCE etc. in your CFLAGS) and include
> sys/stat.h. However, it would be better to just use "struct stat",
> etc. (With glibc, you need -D_FILE_OFFSET_BITS=64 in your CFLAGS to
> make this work right; with musl it always works.)
>
> Rich
>

[-- Attachment #2: Type: text/html, Size: 2037 bytes --]

Re: stat.h

[Rich Felker]

On Tue, Mar 04, 2014 at 07:18:05AM +0200, Paul Schutte wrote:
> Hi
> 
> Hope I am not too anoying ... ;-)
> 
> I have tried both _GNU_SOURCE and _LARGEFILE64_SOURCE and in neither case
> do I get a definition for 'struct stat64'
> 
> If I understand correctly then source using 'struct stat64' should be fixed
> to use 'struct stat' instead ?
> If this is not correct, then 'struct stat64' should probably be added to
> <sys/stat.h> as only the following are defined there:
> 
> #if defined(_LARGEFILE64_SOURCE) || defined(_GNU_SOURCE)
> #define stat64 stat

This defines "struct stat64", which the preprocessor replaces with
"struct stat". If that's not working it's because the source file is
doing something bogus (like #undef stat64, perhaps).

In any case, just fixing the source to use "stat" instead of "stat64"
(and likewise for any other *64 mess) is the best approach.

Rich

Re: stat.h

[Paul Schutte]

[-- Attachment #1: Type: text/plain, Size: 1011 bytes --]

Thanks


On Tue, Mar 4, 2014 at 7:31 AM, Rich Felker <dalias@aerifal.cx> wrote:

> On Tue, Mar 04, 2014 at 07:18:05AM +0200, Paul Schutte wrote:
> > Hi
> >
> > Hope I am not too anoying ... ;-)
> >
> > I have tried both _GNU_SOURCE and _LARGEFILE64_SOURCE and in neither case
> > do I get a definition for 'struct stat64'
> >
> > If I understand correctly then source using 'struct stat64' should be
> fixed
> > to use 'struct stat' instead ?
> > If this is not correct, then 'struct stat64' should probably be added to
> > <sys/stat.h> as only the following are defined there:
> >
> > #if defined(_LARGEFILE64_SOURCE) || defined(_GNU_SOURCE)
> > #define stat64 stat
>
> This defines "struct stat64", which the preprocessor replaces with
> "struct stat". If that's not working it's because the source file is
> doing something bogus (like #undef stat64, perhaps).
>
> In any case, just fixing the source to use "stat" instead of "stat64"
> (and likewise for any other *64 mess) is the best approach.
>
> Rich
>

[-- Attachment #2: Type: text/html, Size: 1542 bytes --]

Re: stat.h

[Rich Felker]

On Mon, Mar 03, 2014 at 08:36:24PM +0200, Paul Schutte wrote:
> Hi,
> 
> I am trying to compile pulseaudio5 against musl, but it fails with an error
> indicating that struct stat64 is not defined:
> 
> utils/padsp.c:133:44: warning: 'struct stat64' declared inside parameter
> list [enabled by default]
> utils/padsp.c:133:44: warning: its scope is only this definition or
> declaration, which is probably not what you want [enabled by default]

It seems to depend on a bug in glibc's headers which causes the
"LARGEFILE64" functions/types to get exposed even in the default
feature profile (they're only intended to be exposed with _GNU_SOURCE
or _LARGEFILE64_SOURCE defined). You could add one of these to your
CFLAGS and get them with musl but the correct solution is just
removing all these "64"s in the source, as they are not needed.

However as nsz noted, the "padsp" library is an utterly broken hack
that only works by chance if it works at all, and which should not be
used. I have no idea what degree of work would be needed to get it
"working" on the same level it "works" with glibc, but to make it
actually work right with either, a great deal of work would be
required. If you don't need it, see if there's just a way to skip it
in the build process.

> When I hack a bit and change the include in <sys/stat.h> from <bits/stat.h>
> to <asm/stat.h>, it compiles that part, but fails some where else :

This change is definitely wrong. In general the linux kernel headers
are not compatible with userspace (which raises the question of why
they're even installed at all). Some of them are compatible, mainly
ones that deal with functionality disjoint from the standard library
such as accessing specific hardware devices, but stat.h is not one of
these.

Rich

Re: stat.h

[Paul Schutte]

[-- Attachment #1: Type: text/plain, Size: 390 bytes --]

On Tue, Mar 4, 2014 at 6:18 AM, Rich Felker <dalias@aerifal.cx> wrote:

> > When I hack a bit and change the include in <sys/stat.h> from
> <bits/stat.h>
> > to <asm/stat.h>, it compiles that part, but fails some where else :
>
> This change is definitely wrong.
>

I knew I was doing the wrong thing here, and that's why I asked for advice.

Thanks for pointing me in the right direction.

[-- Attachment #2: Type: text/html, Size: 928 bytes --]