Home > Archive > C > September 2005 > Universal (g)libc
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
|
| I am writing non GUI software in C for use on Windows and Linux. while
libc packages are generally compatible, I am ending up with a lot of
conditional macros for OS and I/O related stuff such as sleep, sockets
fork etc.
What I would really loke is something that implements as much as
possible glibc on a windows platform. I have seen cygwins dll, but is
no good as I cannot reveal some source which is not mine. I have seen
the wxWidgets base, but it is C++ and I want pure C.
Any experience ideas?
| |
| Nils O. Selåsdal 2005-09-30, 7:55 am |
| Roger wrote:
> I am writing non GUI software in C for use on Windows and Linux. while
> libc packages are generally compatible, I am ending up with a lot of
> conditional macros for OS and I/O related stuff such as sleep, sockets
> fork etc.
> What I would really loke is something that implements as much as
> possible glibc on a windows platform. I have seen cygwins dll, but is
> no good as I cannot reveal some source which is not mine. I have seen
> the wxWidgets base, but it is C++ and I want pure C.
>
> Any experience ideas?
Use apr.
http://apr.apache.org/
| |
| Flash Gordon 2005-09-30, 7:55 am |
| Roger wrote:
> I am writing non GUI software in C for use on Windows and Linux. while
> libc packages are generally compatible, I am ending up with a lot of
> conditional macros for OS and I/O related stuff such as sleep, sockets
> fork etc.
>
> What I would really loke is something that implements as much as
> possible glibc on a windows platform. I have seen cygwins dll, but is
> no good as I cannot reveal some source which is not mine. I have seen
> the wxWidgets base, but it is C++ and I want pure C.
This group only deals with standard C so I'm afraid requesting a library
that implements things that cannot be done in standard C (or even things
that can) is not on topic.
> Any experience ideas?
Yes, write an abstraction layer that contains all the system specific
stuff and call that from the main body of your code. Then all of the
system specific stuff and conditional macros will be isolated in one
place keeping the bulk of the code in one place.
<OT>
You may find MinGW and/or GNUWin32 useful, but I would still recommend
isolating your system specific code from the bulk of your code to ease
future posting issues.
</OT>
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.
| |
|
| That was a good link, didn't know about that!
Thanks.
| |
| Flash Gordon 2005-09-30, 6:55 pm |
| Roger wrote:
> That was a good link, didn't know about that!
> Thanks.
What was? Provide context. There is at least one post almost every day
about providing context and giving instructions (I know there was both
yesterday and today) so you have no excuse for not knowing to provide
context or how to do it through Google.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.
| |
| James McIninch 2005-09-30, 6:55 pm |
| This is not a C language question, per se.
Even so, you'd note that GNU libc is released under the LGPL license. You
are under no obligation to release source code to software that makes use
of it.
Roger wrote:
> I am writing non GUI software in C for use on Windows and Linux. while
> libc packages are generally compatible, I am ending up with a lot of
> conditional macros for OS and I/O related stuff such as sleep, sockets
> fork etc.
>
> What I would really loke is something that implements as much as
> possible glibc on a windows platform. I have seen cygwins dll, but is
> no good as I cannot reveal some source which is not mine. I have seen
> the wxWidgets base, but it is C++ and I want pure C.
>
> Any experience ideas?
--
Remove '.nospam' from e-mail address to reply by e-mail
| |
|
|
Flash Gordon wrote:
> This group only deals with standard C so I'm afraid requesting a library
> that implements things that cannot be done in standard C (or even things
> that can) is not on topic.
>
Sorry, I don't get it. I **want** to use standard C and **only**
standard C. My problem is finding a library that does the most
compatible implementation of C on windows. Perhaps I am incorrect in
regarding glibc as being a good reference standard? To me standard C is
Unix (POSIX) C.
| |
|
|
James McIninch wrote:
> This is not a C language question, per se.
>
> Even so, you'd note that GNU libc is released under the LGPL license. You
> are under no obligation to release source code to software that makes use
> of it.
>
I am aware that glibc is LGPL'd, but cygwin links to a 'cygwin' dll
which cygwin claim is GPL'd and thus source must be released
http://cygwin.com/licensing.html
Briefly what I have found is that the minGW setup I had been using was
not fully supporting glibc, in fact it is designed for implementing
Windows apps using GCC.
cygwin does a good job of implementing a posix like environment, but
has this licesing issue.
However I have now found that thre is a GNUWin32 project on sourceforge
who do a good implementation of glibc. This is working for me.
| |
| Keith Thompson 2005-09-30, 9:55 pm |
| "Roger" <irwin@iol.it> writes:
> Flash Gordon wrote:
>
>
> Sorry, I don't get it. I **want** to use standard C and **only**
> standard C. My problem is finding a library that does the most
> compatible implementation of C on windows. Perhaps I am incorrect in
> regarding glibc as being a good reference standard? To me standard C is
> Unix (POSIX) C.
No, standard C is C as defined by the ISO C standard (either the 1990
or 1999 version). Unix is an operating system, one of many on which C
implementations exist, and POSIX is a secondary standard that defines
many things that the C standard doesn't.
If you have a copy of K&R2 (Kernighan & Ritchie, _The C Programming
Language_, 2nd Edition), standard C is basically what's covered in
appendices A and B. (If you don't have a copy, you should.)
Some quick examples: fopen(), fread(), fwrite(), and fclose() are
standard C; open(), read(), write(), close(), and fork() are not.
POSIX-specific issues are typically discussed in comp.unix.programmer.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
| |
|
|
Keith Thompson wrote:
> "Roger" <irwin@iol.it> writes:
>
> No, standard C is C as defined by the ISO C standard (either the 1990
> or 1999 version). Unix is an operating system, one of many on which C
> implementations exist, and POSIX is a secondary standard that defines
> many things that the C standard doesn't.
>
> If you have a copy of K&R2 (Kernighan & Ritchie, _The C Programming
> Language_, 2nd Edition), standard C is basically what's covered in
> appendices A and B. (If you don't have a copy, you should.)
>
<quote K&R Second edition>
The computing world has undergone a revolution since the publication of
the C Programming language in 1978. Big computers are much bigger, and
personal computers have capabilities that rival the mainframes of a
decade ago. During this time, C has changed too, althougth only
modestly, and it has spread far beyond it's origins as the language of
the UNIX operating system.
</quote>
I had to blow the dust of the K&R. Allthougth I have it I never use it
as I know it by heart. I know that the lib c in K&R only includes
stdio.h wrt interfaces to the real world. So can I assume from that
this ng considers OT anything that cannot be directly implemented using
the libc of K&R. It would seem a bit narrow to me.
comp.unix.programmer would **not** seem to be an appropriate place to
ask about the best libc implementation
> Some quick examples: fopen(), fread(), fwrite(), and fclose() are
> standard C; open(), read(), write(), close(), and fork() are not.
>
The ones you listed as 'not' do appear in K&R in chapter 8 "The unix
system interface". Do you think that the C language per se should not
make any attempt to incorporate interfaces to the rest of the world,
other than a vauge acknowledement that there may be input and output
streams? As the introduction to chapter 8 points out: "Scince the ANSI
C library is in many cases modelled on UNIX facilities, this code may
help your understanding of the library as well", also, "Chapter 7 was
concerned with i/o that is uniform accross operating systems". IMHO
socket i/o is nowdays as fundamental as file i/o and should be included
in "chapter 7". Forks and threads are slightly different in the sense
that different approaches to thier use (and the pro's and cons) vary
from platform to platform, including different unices, so perhaps they
should not be in the standard C library.
I acknowledge however that they are currently **not** in the ANSI
standard and therefore you consider them OT in this ng. I did not
realise you were so pedantic here.
> POSIX-specific issues are typically discussed in comp.unix.programmer.
>
Does not really seem an appropriate place to ask about a good libc
implementation for Win32. If they are as pedantic over there as you lot
over here are I would be flamed to ashes ;-)
My issues are with C portability. I have always felt that portability
has been very much in the spirit of the C language. According to the
K&R preface the ANSI goal was to produce an unambiguous and machine
independent definition of the language. My point is that you cannot
achieve that completely by simply ignoring essential functionality that
almost any modern program needs. Or perhaps C should be called "a
standard language for mono-threaded applications which only require
file and console i/o".
| |
| Keith Thompson 2005-09-30, 9:55 pm |
| "Roger" <irwin@iol.it> writes:
> Keith Thompson wrote:
[...]
> I had to blow the dust of the K&R. Allthougth I have it I never use it
> as I know it by heart. I know that the lib c in K&R only includes
> stdio.h wrt interfaces to the real world. So can I assume from that
> this ng considers OT anything that cannot be directly implemented using
> the libc of K&R. It would seem a bit narrow to me.
I mentioned K&R because it's a reference you're likely to have. The C
language is defined by the ISO standard.
You can certainly do plenty of system-specific and non-portable things
in C, using libraries beyond those defined by the standard. We just
don't discuss them here, largely because we lack the expertise, and
largely because there are plenty of newsgroups that discuss particular
systems.
[...]
>
> Does not really seem an appropriate place to ask about a good libc
> implementation for Win32. If they are as pedantic over there as you lot
> over here are I would be flamed to ashes ;-)
There are also a number of Windows newsgroups. You might try
comp.os.ms-windows.programmer.win32.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
|
|
|
|
|