1:20 p.m.
I was trying to build the latest 0.24/fixes branch of MythTV and ran
into an issue where many C files were using functions (usleep, write,
close, gethostname, etc.) that were not available/(in scope?). It
turns out that unistd.h provided these functions so I included it in
all the offending files which allowed building to complete.
Is there any reason this would be unsafe (or non-portable)? I've
submitted a patch upstream but I'd like to get current builds out if
there's no reason not to.
Thanks,
Richard
2:14 p.m.
On 02/05/2012 02:20 PM, Richard Shaw wrote:
I was trying to build the latest 0.24/fixes branch of MythTV and ran
into an issue where many C files were using functions (usleep, write,
close, gethostname, etc.) that were not available/(in scope?). It
turns out that unistd.h provided these functions so I included it in
all the offending files which allowed building to complete.
Is there any reason this would be unsafe (or non-portable)?
No, nowadays, presuming
unistd.h to be present is pretty safe, because
it has been part of POSIX for ages and is likely present on all POSIX'sh
environments.
c.f.:
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/unistd.h.html
Somewhat oversimplified, in practice, this means, #include <unistd.h> is
safe except on Windows.
Whether a particular version of <unistd.h> will provide the missing
decls, is a different story.
Some (ancient) OSes still could be shipping ancient or broken versions
of unistd.h which do not supply the decls current POSIX would expect
unistd.h to supply. However, this would not be worse than the current
situation - Compilers could continue to complain about missing
symbols/decls.
Ralf
2:38 p.m.
Hi,
On 02/05/2012 02:20 PM, Richard Shaw wrote:
I was trying to build the latest 0.24/fixes branch of MythTV and ran
into an issue where many C files were using functions (usleep, write,
close, gethostname, etc.) that were not available/(in scope?). It
turns out that unistd.h provided these functions so I included it in
all the offending files which allowed building to complete.
Is there any reason this would be unsafe (or non-portable)? I've
submitted a patch upstream but I'd like to get current builds out if
there's no reason not to.
including unistd.h is the correct fix, this is necessary because
some libstdc++ headers used to include it implicitly and they
no longer do that, so now you need to include it explicitly.
Regards,
Hans
4463
days inactive
4463
days old
rpmfusion-developers@lists.rpmfusion.org
2 comments
3 participants
participants (3)
-
Hans de Goede -
Ralf Corsepius -
Richard Shaw