Writing a custom libc


Writing a custom libc

Postby Levi Campbell » Thu, 01 Jun 2006 10:40:10 GMT

where can I get the pieces needed to write a custom C library? I ask
because I'm working on a rather large set of libraries where the extra
stuff in glibc is a waste of space.

Re: Writing a custom libc

Postby Ian Collins » Thu, 01 Jun 2006 11:42:29 GMT

Eh?  Not including stuff you don't use is the linker's job.

Ian Collins.

Re: Writing a custom libc

Postby Eric Sosman » Thu, 01 Jun 2006 12:09:17 GMT

     The linker isn't always up to the task.  For example,
a program that never uses any of the <locale.h> functions
but uses <ctype.h> might drag in a whole bunch of the locale
machinery, because the <ctype.h> facilities are sensitive to
the locale changes the program will never perform.  Also, the
use of shared libraries tends to make library inclusion an
all-or-nothing proposition -- although in this case, the amount
of space used in the entire system usually decreases even if
the amount "used" by a single program seems to be greater than
if it incorporated only the "necessary" functions.

     If the O.P. has actually measured the amount of "extra
stuff" and found that it can't be tolerated (highly unlikely;
if he'd measured anything he'd probably have mentioned it),
there are a couple of possible strategies.  First, he could
see whether his system supports "static linking," following the
model implicit in Ian Collins' post.  If that's not enough, he
can get hold of the glibc source and start throwing things out
until he's got a smaller (maybe), less functional (surely), and
non-conforming (probably) library that works for his program
but for few others.  And I bet it won't save him much, either.

Eric Sosman

Re: Writing a custom libc

Postby Levi Campbell » Thu, 01 Jun 2006 16:12:37 GMT

You *do* realize you've given me the answer don't you? All I have to do
is write a new locale that can handle braille and patch the aclocal.m4
and Makefile to a) skip the threading and use sockets. b) use the
braille-enabled locale as the default.


Re: Writing a custom libc

Postby Ico » Thu, 01 Jun 2006 16:23:35 GMT

Assuming you are running linux: other C libraries with a much smaller
footprint exist, take a look at uClibc.


Similar Threads:

1.Handling 'write!' procedures for custom binary output ports


Could someone help to explain some of the wording for R6RS reagarding  
custom binary output ports?

The specification of the writer for the custom port indicates that when  
passed a count of zero, this should be the same as asking the write  
procedure to send the eof of file "object" to the byte sink. However, the  
R6RS EOF object defined by R6RS is that object returned by 'eoj-object',  
which by definition has no external representation and is not a datum.  
Moreover, the write procedure is required to indicate the number of bytes  
that were actually written. This number should not be, according to my  
reading, more than the count argument that is passed to the write  
procedure. Yet, in the case of the zero count argument, we are required to  
write something, which means at least one byte, to the byte sink. This to  
me indicates that the write procedure must return at least 1 in all cases.

There are two traditional EOF characters in common use today, the CTRL-D  
 from UNIX, and the CTRL-Z from windows. Does R6RS actually mean that one  
of these characters should be send to the sink? If so, which one? Should  
be base this on the platform which is sending the data, or the platform of  
the system receiving the data? These can be different systems, as in the  
case of sockets or network communication, and thus, who knows whether one  
or the other should be considered?

Additionally, there is no facility for sending this character outside of  
using something like #\x4 to send it. If R6RS really intended to use a  
character for sending the EOF object over the
stream or byte sink, wouldn't it make sense for the R6RS to at least  
define the #\eof or #\end-of-file character so that this could be done in  
a portable way. Even without this, at least something like an  
'eof-character' parameter could have been made.

The complete lack of information available on this in the documents  
suggests that I have misread something. Could someone provide more input  
as to the proper behavior of these procedures when they are passed a zero  
value for their count argument?

As a side, I also know that in Linux, the write(2) system call has  
unspecified behavior with a zero count argument when the file descriptor  
is not a regular file.

	Aaron W. Hsu

Of all tyrannies, a tyranny sincerely exercised for the good of its  
victims may be the most oppressive. -- C. S. Lewis

2.Rene has written a custom edit tool for RosAsm

> You mean this source code right here:
> [ClassName: B$ 'RosAsmWindowClass' 0   EditClassName: 'EDIT' 0
>   AppName: '  RosAsm, The Bottom-Up Assembler for ReactOS -V.1.22b-' 0]
> <<<<<<<<<<<<<

In case you might have missed it: The snippet above is a data 
declaration in RosAsm. The fact that something is named EditClassName 
does not mean that it is used as a base class for any window.

If you retry that test Donkey did with your favourite Spy tool you see 
that the source editor is of class 'RosAsmWindowClass'. If it was 
reported as Edit in the past, this only reflects that you can give your 
custom classes existing names (which is new for me, too). Or would you 
expect that the *Scrollbar* in RosAsm is of class Edit?

Besides that: Who cares? :)


3.Rene is claiming, again, that he wrote a custom edit tool for RosAsm

Betov wrote:
>  XXXX@XXXXX.COM  rivait
> news: XXXX@XXXXX.COM :
> Well, i should not answer to this flow of insanities,
> but, maybe it would be possible that some readers
> could believe them. So... here we go...

And you really expect people to believe you? Let me clue you in, Rene,
you have zero credibility. It comes from spending five years around
here spouting nonsense. Feel free to take your credibility level into
the negative regions, though.

> > We have never seen a "preparser" outside of RosAsm, either.
> One more inovation of RosAsm, that you will probably
> never understand.

IOW, a preparser is bad in HLA, it's an innovation in RosAsm.
I love it!

> >> RosAsm users' ones are (very partialy) there:
> >
> > Who cares? That has nothing to do with whether or not RosAsm is or
> > isn't an assembler. The fact that you've collected a few user demos on
> > your web page is hardly what defines what is and is not an assembler.
> Sure, but there is no question about RosAsm being or
> not being an Assembler. Everybody knows that RosAsm
> is an Assembler, full right, and this has never been
> a question.

No, by your own definition RosAsm fails to be an assembler. That point
has been made around here many times. It's not a question of whether
RosAsm is or isn't an assembler, though. What is in question is your
lame definitions, which you attempt to use to claim that MASM and HLA
are not assemblers. The problem with your definitions is that, when
applied to RosAsm, they demonstrate that RosAsm isn't an assembler,

You know, few people (other than the RosAsm crowd) question that MASM
is an assembler. You do. That fact alone gives you zero credibility
when it comes to defining what is and what is not an assembler.

> As opposed HLA is evidently not an Assembler, at all,
> as it does not even include an Encoder, and as it does
> not conform to any possible definition of what any
> Assembler could ever be.

It most certainly does include an encoder. Under Windows, it's called
ml.exe or fasm.exe. Under Linux, it's called as. The fact that it is a
separate process is irrelvant.

> > As for the fact that RosAsm's demos may be more advanced than some
> > user-written HLA demos, that's pretty much a given at this point. The
> > HLA user base is built up of beginning programmers. It will take time
> > before the larger user base increases to the point where you find a
> > large number of HLA apps as you would, say, MASM apps (the RosAsm base
> > is so pathetically small, I'm certainly not setting my goals to
> > achieve that level).
> :))
> OK:
> 1) This is normal that the HLA victims have nothing to
> show, because they are all beginners.

Yes, that is the market for whom HLA was created. Most HLA users are
solving homework problems and the like with HLA. Not exactly the stuff
you post on web pages (for obvious plagiarism purposes).

> 2) This is normal that the RosAsm users have something
> to show because they were all experts before using RosAsm.
> (What means that RosAsm does not have any beginner user).

Again, you are quite correct. Very few beginners could learn with
RosAsm because of the lack of appropriate pedagogy (and the prime
example of a beginner, Wannabee, is quite scary). I'd bet that the
largest percentage of RosAsm users already knew assembly upon
encountering RosAsm and, for whatever reason, were willing to learn a
different syntax (perhaps to use the IDE, back in the days when Spasm
was the only game in town) in order to use RosAsm. It's not surprising,
therefore, that *some* more advanced demos have come from the RosAsm
crowd.  Then again, now that we have IDEs for the likes of NASM, FASM,
MASM, and HLA, the advantage you once held in that area no longer

Compare yourself with the number of demos written by advanced users of
*other* assemblers (NASM, FASM, MASM, and even Gas). You've got a
pathetically small number by comparison.

> Fancy... :)

Nothing fancy about it at all. RosAsm has a tiny number of demos
available, compared to MASM, NASM, FASM, etc. Comparing yourself
against a teaching tool, for whom most users will complete the assembly
course and then simply use assembly in support of their HLL code may
make you feel better, but it doesn't change the fact that *you* don't
have a whole lot of people using your product.

HLA *has* reached critical mass. There are lots of people using it and
the experience of the user base is increasing. No doubt, within a year
or two, the number of user demos and applications written in HLA will
surpass that of RosAsm. You've got an advantage right now insofar as
HLA's user base has been inexperienced. But that advantage is fading
fast, just like all the other advantages RosAsm has held in the past
(such as being the first with an IDE).

Not that having more "user demos" has really been much of an advantage
to begin with. What does it prove? Absolutely nothing. Again, if you
had the same number of apps as MASM, I'd be impressed. Trying to
impress us with the tiny number of apps that you've got simply
demonstrates how *small* you think.

> >
> > I guess Guga doesn't either. How's the disassembler coming along?
> > Can't make any progress on it on your own?
> Yes, I have already answered to this. You will see the
> next coming release, with significative improvements,
> in the next week, probably.

I'd say I'm looking forward to it :-). But the truth is, you keep
making the pronouncements about how great the disassembler is, and
every time I've played with it, I've broken it within a minute or two.
Though it has been a long time since I've played with it, I'm not
expecting much.

> [By the way, not to minimize Guga contribution -that
> is quite massive on many areas...-, Guga never wrote
> _one_ single line of the Disassembler, that is 100%
> my own work. Though this may change in the future,
> for the final HLL interpretations... :)]

Yet, you've claimed in the past that work was being held up while Guga
was busy moving. Perhaps you can explain those posts?

> > Yes, we were *all* impressed by his last set of claims about how he
> > rewrote the Delphi VCL. They were about as amusing as your claims that
> > you'd created a totally custom edit tool for RosAsm.
> If "Half claims" were "as amusing as", i suppose he
> was 100% right, as long as it would require really
> having a very damaged brain, to assert that RosAsm
> Sources Editor is not "a totally custom edit tool
> for RosAsm".

Shall we ask Donkey to step in and point out how your code is just a
subclass of the Win32 tool again? You do realize, of course, that by
making RosAsm GPL and posting the source code, it's pretty easy for
people to verify what you've done with respect to your EDIT tool? Make
all the proclamations you want about your "totally custom edit tool",
but anyone who looks at your source code can easily determine that
you've simply subclassed the Win32 tool. In most people's minds, that
not a "totally custom edit tool".

> Anybody taking a quick look, simply, to the way the
> Sources Editor works, can see immidiatly that it is,
> in no way, an Edit Control, and anybody taking a quick
> look to the Source of the Sources Editor can see that,
> effectively, it is a 100% original Editor making use
> of nothing but the "TextOutA" Function, with many
> unusual Functionalities.

Yes, I do believe that Donkey did this, and verified that you are
simply subclassing the existing tool. Hardly a "totally custom edit

> Saying that i don't know what RosAsm Sources Editor
> is, and how i wrote it, shows nothing but your vileny
> and your definitive stupidity.

I will certainly admit that *I* haven't wasted the time figuring out
what you've done. But I have a fair amount of respect for Edgar
(Donkey) and he made a very pervasive arguement in this very newsgroup
that pretty much debunked your claims that you wrote a "totally custom
edit tool". Perhaps you simply don't understand the meaning of the
phrase "totally custom edit tool"?

> Well... you know, when Half will have finished his
> Icon Editor (w<e should have a new release soon...),

Wait, wait, wait. I thought he wrote this in 12 days, or something like
that? You mean, it's not finished? Boy, it's been a couple of months
now. You know, this "demo" is looking less impressive with each passing

> everybody will be able to measure the exact value of
> your words.

Yes, they will.

> >> No. It does not. What does damage Assembly is when writing
> >> Applications with a weird HLL and saying that it is Assembly.
> >
> > You mean, like RosAsm? Whether you claim HLL-like control structures
> > are macros or not in RosAsm, the bottom line is that you use a
> > HLL-like programming style in RosAsm. The fact that you call those HLL
> > statements "macros" doesn't change one thing. The fact that those
> > macros are built into MASM, TASM, and HLA doesn't mean a single thing
> > to your average assembly language programmer. What they see is that
> > you use HLL-like control structures in your code and then complain
> > about their presence in other assemblers. Doesn't make much sense to
> > most people (then again, neither do most of your posts). When you give
> > up the HLL-like programming style in your RosAsm code, you'll have a
> > leg to stand on when you make this complaint. Until then, it's all
> > syntactical nit-picking with absolutely zero differentiation between
> > the products (other than the fact that MASM, TASM, and HLA do a much
> > better job of what you're trying to do with your macros).
> Just for the ones reading those bullshits:
> Writing an HLL Pre-Parser enabling HLL Statements is
> way easier to write, than writing the Macros Parser
> that can enable the Programmer with defining his own
> HLL Style.

So why don't you prove how easy this is by writing such a "preparser"
for RosAsm then?  Given how broken your macro system is, such a
"preparser" would be a boon to RosAsm users.

BTW, have you forgotten that HLA *also* includes a powerful macro
system that is *far* more capable of implementing those HLL-like
statements than is RosAsm? Indeed, I've provided sample macro
implementations for *every one* of the HLA high-level control
structures. So if macro implementation is really a good indication of
the power of the assembler, HLA still wins hands down, because the
macro implementation of those statements in HLA is *far* better than
that in RosAsm (none of the funky "." nonsense, fully recursive, full
boolean expressions, nestable to any level, etc., etc., etc.).

> That is, by the way, one of the major differences
> between a Compiler and an Assembler,

Actually, there is an element of truth to this. Which is one of the
reasons I refer to HLA as a "compiler for an assembly language."

On the other hand, your argument that having the macros built into the
language puts you on weak ground. After all, RosAsm is the assembler
that builds all the Win32 equates into the assembler (rather than
including them as part of the user's source code as all other
assemblers do). So I'd be careful about your claims of what an
assembler is and isn't. As usual, they can be easily turned against

> that this swindler
> could never admit, as long as he is utterly unable to
> write anything but an HLL pre-parser.

Whatever you say. Bottom line though, is that I've written a lot more
code than you ever have, both in assembly and in HLLs.
Randy Hyde

4.Draft standards OK for new compiler and libc?

I was wondering whether there is much difference between the draft standards
of C and the official ISO published standards.

For example, would the draft standard be good enough to go on when writing a
new ISO Standard C compiler and C library?  Could the drafts be used as a
reference when writing C programs without any problems caused by
differences between the draft and the standard?

Thank you,

James Buchanan

5.Linking libc *BSD (amd64)

I am trying to figure out how to link to libc in assembly -- I just
want to know how to do this.  The documentation I find online is for
linux, but I am using one of the BSDs.

Anyway, here was my process:

1) write C code with printf:

#include <stdio.h>



2) compile and link the C code

3) lld the C code to see what libraries I need:

$ ldd library
        Start            End              Type Ref Name
        0000000000000000 0000000000000000 exe   1  library
        0000000048aaa000 0000000048f7e000 rlib  1
        0000000042200000 0000000042200000 rtld  1  /usr/libexec/ld.so

4) write the assembly code:

# writes an arg to stdout

.section .data

.section .text

.global _start


	xorq %rax, %rax
	movq 16(%rsp), %rdi # arguments are stored %rsp+16
	call printf

	movq $1, %rax
	movq $10, %rdi # just messing around with error return values

5) assemble and link the assembly code:

as -o test_arg.o test_arg.s
ld -dynamic-linker /usr/libexec/ld.so -o test_arg test_arg.o -lc

But I receive this error when linking:

/usr/lib/libc.so.38.0: undefined reference to `environ'
/usr/lib/libc.so.38.0: undefined reference to `__progname'

Is there something obvious that I am doing wrong?



6. using libc from nasm

7. POSIX thread chapter removed from libc, why?

8. OT: GNU libc linking problem on Linux

Return to c


Who is online

Users browsing this forum: No registered users and 55 guest