[FFmpeg-devel] Question on libbrokenos support

[Michael Niedermayer]

On Tue, Jan 08, 2008 at 09:27:41PM -0500, Rich Felker wrote:
> On Tue, Jan 08, 2008 at 07:18:10PM +0100, Michael Niedermayer wrote:
> > On Tue, Jan 08, 2008 at 12:56:51PM -0500, Rich Felker wrote:
> > > On Tue, Jan 08, 2008 at 06:44:16PM +0100, Michael Niedermayer wrote:
> > > > On Tue, Jan 08, 2008 at 05:12:36PM +0100, Luca Abeni wrote:
> > > > [...]
> > > > > > For headers with actual content, do a ln -s to
> > > > > > _actualheadername.h or echo #include "_actualheadername.h" >>
> > > > > > actualheadername.h where that _actualheadername.h is part of svn (in
> > > > > > libos/*, again).
> > > > > In this way, I prevent the inclusion of the header provided by the OS, no?
> > > > > In the example above, I need to include the sys/socket.h from the OS for
> > > > > having some definitions, and to provide some other definitions in
> > > > > libbrokenos's header. Or are you saying that the configure can merge the
> > > > > two headers, and libbrokenos can force the inclusion of this "merged header"?
> > > > > That could be a solution; I'll think about it...
> > > > 
> > > > What ronald meant i think is:
> > > > /usr/local/include/sys/original_socket.h which is a 
> > > > symlink to /usr/include/sys/socket.h
> > > > 
> > > > then you can just #include <sys/original_socket.h> to include the system header
> > > 
> > > Locating and making a symlink to the original header is both a lot
> > > more difficult and a lot more nonportable than using #include_next.
> > > As everyone knows I detest gccisms but I detest hacks like this just
> > > as much..
> > 
> > Making libos dependant on gcc is a very big problem, i dont think ill agree
> > to it.
> 
> If a system is so broken already, the non-gcc compilers for it
> probably provide environments that are a whole order of magnitude more
> broken...

Could be, but libos was supposed to provide some of the standard posix
functions if they are missing. Broken OSs really are the target environment
of libos, so this seems like a strange argument ...

And anyway, using #include_next would break the whole system. Just think what
would happen if a non gcc compiler would compile a file with 
#include <sys/socket.h> ?
It would fail hard, that is libos install on such a system would break it
and not just applications which want to use libos but every application which
includes sys/socket.h

And no #ifdef GNU would help cause its too late by the time it is reached


> 
> > Locating a header with the gnu toolchain (your solution needs it to be used
> > for all applications using libos, mine just needs it during libos install)
> > is easy:
> > 
> > just parse the output from
> > echo '#include <sys/socket.h>' | cpp -M
> > or look at the directories from
> > cpp -v
> 
> These are gccisms too. Do you see a -M option in:
> http://www.opengroup.org/onlinepubs/009695399/utilities/c99.html
> A "cpp" command does not even appear in:
> http://www.opengroup.org/onlinepubs/009695399/utilities/contents.html

and iam sure #include_next doesnt appear in there either


> 
> > or even take the first sys/socket.h from
> > echo '#include <sys/socket.h>' | cpp
> 
> Huh?

echo '#include <sys/socket.h>' | cpp | grep -m1 'socket.h'
# 1 "/usr/include/sys/socket.h" 1 3 4

of course thats a gcc-ism as well

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I am the wisest man alive, for I know one thing, and that is that I know
nothing. -- Socrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080109/2675aa10/attachment.pgp>