Re: getpagesize() problems

"Indan Zupancic" <[email protected]>
Newsgroups gmane.linux.lib.dietlibc
Message-ID <[email protected]>
On Tue, August 11, 2009 15:28, Michele Alberti wrote:
> Thanks Indan for your gentle answers.
>>
>> Sorry, it does indeed hardcodes the path, I checked again. In that
>> case it's easiest to distribute the whole diet source with your
>> source distribution, which makes sense anyway. Or require dietlibc
>> as a dependency (lots of distributions have a package for it).
>
> What about to emulate "diet" work?
> Like:
> cc -nostdlib -static -L/opt/diet/lib-i386 /opt/diet/lib-i386/start.o
> -isystem /opt/diet/include -D__dietlibc__ /opt/diet/lib-i386/libc.a -lgcc
>
> but I know, you just tell me that maybe "diet" makes other work.

It depends on your situation and what you want. I wouldn't distribute
dietlibc with my own source at all, but if I did I would distribute
whole dietlibc as it is, not select parts of it. This makes complying
with the GPL easier too, but more importantly, if someone finds a
bug in dietlibc it's easier to fix it.

The reason to not distribute dietlibc with the code would be that it's
not an integral part of it. I would make the code compile both with glibc
and dietlibc, that way you leave it to the user, and then dietlibc is an
optional dependency instead of a required one. This makes it easier to
compile it with some other libc too, like klibc or uclibc.

The reason to distribute it would be as a service to the user, but I
think dietlibc is widespread enough that that isn't needed. And if you
distribute dietlibc it will be often an older version than the latest,
missing the latest bugfixes and improvements.

Maybe have it as a compile time option to get the latest dietlibc from
CVS?

Greetings,

Indan
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.