Re: About the support of aarch64

[Rob Landley]

On 01/09/2017 08:26 AM, ANDY KENNEDY wrote:
> Because uClibc is dead.

As the guy who staged the coup to appoint the current maintainer a
decade ago and then watched him _not_ get the NPTL mess sorted or the
project back on a regular release schedule, I agree: uClibc is dead. Has
been for a while, replaced by musl-libc (chromeos) and bionic (android).

I wrote a long eulogy for the project last year on the buildroot list
explaining how it died and why I consider the uClibc-ng project to be
beating a dead horse:

  http://lists.busybox.net/pipermail/buildroot/2016-December/180102.html

Of course that particular exercise in necromancy is no sillier than a
half-dozen other such projects I could name. Heck, there's open source
projects _today_ to clone OS/2 http://www.osfree.org/ BeOS
https://www.haiku-os.org/ AmigaOS http://aros.sourceforge.net/ Windows
95 https://www.reactos.org/ and there are even a bunch of operating
systems written entirely in assembly (menuet, kolibri, mikeos,
baremetal...).

> You may be able to get support from
> de...@uclibc-ng.org where a new maintainer picked up uclibc
> and started a fork.

*shrug* Good luck with if if you decide to go that way.

> The current uclibc maintainer hasn't posted to this list,
> unless I am mistaken, since before 7/28/2016.

You might have better luck with http://musl-libc.org which already
supports aarrcchh64. The https://github.com/richfelker/musl-cross-make
toolchain builder presumably can build current cross and native
toolchains for all the supported targets. (There's some buildroot
support as well, but not as thorough as musl-cross-make. I have a todo
item to talk Rich into posting prebuilt binary toolchains each release,
and to get my https://github.com/landley/mkroot project to have simple
root filesystems you can drop the native toolchains into to build linux
from scratch. It's on my todo list, but not near the top.)

For nommu targets musl only supports fdpic and static pie (no binflt).
Meaning if you want to use cortex-m with musl you need to either
--enable-default-pie in your gcc build (plus the tiny kernel patch to
enable binfmt_flat on cortex-m and teach it to load pie binaries) or
else grab the full fdpic for cortex-m support patches (which modify the
compiler and linker as well as the kernel) from those french guys who
did it.

But arrch64 should work fine without that, it's got an mmu so it's
standard ELF all the way

Rob

P.S. Remind me to write up a proper explanation of nommu executable
formats for the kernel Documentation directory...
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [Buildroot] [musl] Re: [musl] cortex-m support?

[Rob Landley]

On 12/21/2016 12:18 AM, Waldemar Brodkorb wrote:
> Hi Rob,
> Rob Landley wrote,

Forwarding my reply to the old uClibc list instead of continuing on
buildroot and musl lists, since it's probably off topic there.

If anybody else is still listening, you can follow the previous messages
starting more or less at:

http://lists.busybox.net/pipermail/buildroot/2016-December/179782.html

>>> I am wondering why you don't cc me or any uclibc related list? 
>>
>> I cc'd the buildroot list, which only has uClibc-based cortex-m support
>> at the moment. Why do you suppose I did that?
> 
> That is not completely true, OpenADK has support for it, too.

Buildroot has cortex-m support based on OpenADK as well as its cortex-m
support based on uClibc?

> It seems to me that in your definition of a open source project,
> the people behind must either get money for their work or the
> project needs millions of installations.

I prefer to spend my free time on things that have a reasonable
probability of a future, yes.

When I first started banging on busybox and uClibc I was thinking "linux
from scratch is 110 megs based on gnu/crap but tomsrtbt does the same in
1.7 megs based on busybox, if I can save Knoppix 100 megs on their 700
meg CD they can work WONDERS with that". This was back when "Linux on
the Desktop" was still a feasible idea, and knoppix was leading that
charge. So there was a small but real chance it could help change the
world. (Plus getting Stallman's claws off the thing by producing a
version even he couldn't stick a GNU/ prefix on, at least without being
laughed off the stage, was a nice fringe benefit. My history with _that_
goes back to
http://web.archive.org/web/20060206061908/http://kerneltraffic.org/kernel-traffic/kt20020805_178.html#1
and I'm still sorry.)

Now I'm trying to turn Android into a self-hosting development
environment capable of rebuilding itself under itself, so when an 8 year
old girl in rural India inherits her mother's old castoff phone, buys an
old USB hub/mouse/keyboard at a yard sale with lunch money, and gets a
ten year old HDTV with a chromecast or something*, she can become a full
blown Android OS developer. (The economies of scale favor phones the way
they favored PCs 30 years ago, the old big iron technology will get rare
and expensive and the new thing will be cheap and ubiquitous, and this
will become more extreme as the new thing sucks away all the old thing's
users and use cases. Unless we want a read-only iPad future with no user
serviceable software parts, we need to lever open the phone the way
Compaq's clean-room clone levered open the IBM PC. There is _work_ to do
here to make it _better_.)

* USB to HDMI adapters require USB3, once that's ubiquitous they should
get cheap, but aren't yet.

Before either of those I spent half the 1990's trying to make OS/2
happen (because windows was terrible technology and basing the internet
on it meant not just a virus utopia but probably the kind of surveilance
state Edward Snowden eventually showed us we actually got.) My time on
OS/2 was a learning experience, and figuring out it was over and I
needed to move on to Linux in 1998 was an important lesson. I prefer to
spend my public development time on things that have at least the
possibility of a future. (I write plenty of code I don't bother to
_post_ anywhere. I don't need you for that, thanks. And $DAYJOB is a
black hole of unrelated programming time, for which I'm currently
supposed to be writing GPS signal processing software but it's the
holidays so I'm ignoring that and doing toybox for a bit instead.)

So yes, I was interested in uClibc when it had the distant but real
potential to change the world. But it sat there stagnating for TEN YEARS
during which the world changed out from under it, and these days its
world-changing potential is zero, and I have other things to do with
with my time.

Here's what happened in those ten years uClibc twiddled its thumbs,
starting with some research I did in 2003 helping defend IBM from the
SCO lawsuit:

  http://www.catb.org/esr/halloween/halloween9.html#id2867629

Which turned into a research paper about how Linux might take advantage
of the move from 32 to 64 bits to displace Windows on the desktop:

http://catb.org/esr/writings/world-domination/world-domination-201.html

Which didn't happen. I figured out I missed
http://landley.net/notes-2010.html#10-03-2010 in my analysis which gave
microsoft time to recover from Vista. On the Macintosh front (which was
at least a unix base) Steve Jobs' cancer made Apple back off from trying
to own the desktop instead of just cream-skimming the most profitable
20% (and of course he was ahead of everybody else with the iPhone). And
Linux on the Desktop continued not to happen because it turns out Open
Source development can't handle aesthetic issues the same way wikipedia
can't write a novel, as I explained at
http://landley.ne

Re: [PATCH] uClibc++: any throw statement causes memory corruption

[Rob Landley]

On 03/12/2016 11:20 AM, Bernhard Reutner-Fischer wrote:
> On March 12, 2016 12:18:02 AM GMT+01:00, Ivan Koldaev  
> wrote:
>> P.S. added Bernhard Reutner-Fischer into CC, because I hope for some
>> movement for this patch.
> 
> I have this scheduled, thanks. Will push together with a second patch as soon 
> as I have written a trivial testcase for the second buglet.
> 
> Thanks for the patch!
> Cheers,

Ah, I thought the project was abandoned just because there hasn't been a
release in years. My bad, I should know better around here.

Rob
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH] uClibc++: any throw statement causes memory corruption

[Rob Landley]

On 03/04/2016 01:48 PM, Ivan Koldaev wrote:
> Patch for uClibc++ bug #8741 (https://bugs.busybox.net/show_bug.cgi?id=8741)
> 
> I have discovered that uClibc++ incorrectly implements C++ exception
> ABI, allocating not enough memory in the
> "__cxxabiv1::__cxa_allocate_exception":

When I spoke to Garrett Kajmowicz on the phone last month, he said that
his previous day job stuck with last GPLv2 release of gcc, so he stopped
staying up to date with changes in the C++ specification after ~2007.
Meaning he hasn't touched uClibc++ in years.

He switched jobs recently (at Google now) but didn't seem particularly
interested in picking up where he left off after a multi-year gap. (I
think they use LLVM internally there, and thus http://libcxx.llvm.org/ ?
I know Android and ChromeOS do, dunno about the web server plumbing
stuff he's dealing with. It sounded more like AI research than anything
else, really...)

I still use it in Aboriginal Linux, but only because I haven't switched
my toolchain to LLVM yet...

Rob
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Segmentation fault in __uClibc_main on m68k

[Rob Landley]

On 06/08/2015 10:35 AM, Thomas Petazzoni wrote:
 Waldemar, Rob,
 
 On Sat, 30 May 2015 10:06:08 +0200, Waldemar Brodkorb wrote:
 
 Remember when buildroot announced they would switch their default libc
 if the uClibc developers couldn't get a new release out? Remember how
 that was over a year ago, ala
 http://lists.busybox.net/pipermail/uclibc/2014-February/048252.html ?
 Well instead what happened was
 http://lists.busybox.net/pipermail/buildroot/2013-October/079661.html
 became 
 http://git.buildroot.net/buildroot/commit/?id=c29799330464fb5d152f1b3d550fcbda69c58a3d
 which became 
 https://www.phoronix.com/scan.php?page=news_itempx=Musl-Libc-GCC-Support
 and at this point it's pretty much over except the cleanup. They
 didn't _announce_ a migration, they just did it. At this point if
 uClibc had a new release I expect they'd smile and nod and _continue_
 not to care because there are better alternatives now, once that
 haven't established a pattern of chronic multi-year development
 constipation.

 That is not correct. They did not silently migrate to musl.
 Musl is a choice like Gnu Libc in their buildsystem.

 They will migrate in the next release cycle, but they migrate to
 uClibc-ng as default C library for their system.
 
 Correct. Contrary to what Rob said, we (Buildroot) have only added
 support for Musl, not switched to it as our default C library.

Indeed. I wasn't trying to speak for the project, just saying that all
the buildroot users I know moved over already. (Not all to musl, some
went to glibc.)

 We
 actually discussed switching to glibc as the default C library, but
 never to musl. We want to offer the option of using musl, but for the
 moment not as the default. Also our musl support is still experimental,
 and there are lots of packages in Buildroot that do not yet build with
 musl.
 
 However, we are indeed quite desperate about the state of uClibc and
 the lack of stable releases. Which is why I've personally encouraged
 Waldemar to do the uClibc-ng project, Buildroot offers the option of
 using uClibc-ng, and I will propose to make that the default C library
 choice in the next Buildroot release.

I see another uClibc fork as increasing fragmentation. Manuel Nova had a
fork. S.J. Hill had a fork. Peter Mazinger had a fork. Mike Frysinger
had a fork. The Code Sourcery guys had a fork. Let's try to fix uclibc
by forking it was the approach people tried back in 2007. It didn't
work then, I don't see why it would work better now.

There are still _three_ threading implementations, incoherent locale
support, a tangled mess of headers copied from random glibc snapshots,
the kconfig in current git _still_ has Manuel's Hidden Warnings, the
root of the Kconfig tree is extra/Configs which you just have to
_know_ (what does extra mean in this context, cannot compile this
without?), there's still the HAS_MMU/USE_MMU nonsense (both showing up
in target architecture features and options when it's just one choice:
you've either enabled mmu support or you haven't)...

People have been working at cross-purposes in uclibc for many years,
abandoning half-finished projects that never got removed, and cleanup
was never a priority because glibc was inherently so much worse that
just not being a gnu project made it smell like roses in comparison. I
complained about this crap over the course of many years. I didn't stop
complaining because it got fixed, but because an alternative appeared
that was neither a giant mass of scar tissue nor moribund.

That said, I can see the appeal of uclibc-ng for buildroot: you've
effectively already _been _maintaining your own uClibc fork for years,
and migrating a major system component is painful and disruptive. Heck,
a huge amount of your build plumbing is running sed against uclibc
config symbols, just cleaning that _out_ for something like musl would
be quite the chore.

But the potential userbase of uclibc-ng is a subset of the historical
userbase of uclibc. (Explaining to a newbie why after they select NPTL
they can still select PTHREADS_DEBUG_SUPPORT in the giant forest of
overcomplicated Kconfig plumbing is not a task for the weak of stomach.)
It's maintenance of legacy code, bionic or musl make way more sense for
new deployments.

 At this point, I don't think there's any hope for uClibc to ever do a
 release.

Even if they did, one release would not solve a chronic problem going
back almost a full decade.

Rob
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Locales strike back

[Rob Landley]

On Mon, Jun 1, 2015 at 5:12 AM, Jaromír Cápík tav...@seznam.cz wrote:
  The guy who implemented locale support for uClibc, Manuel Nova, never
  quite finished it, and left the code with a config symbol manuel's
  warnings. He wandered away from uClibc development almost ten years
  ago, and nobody really inherited his work. Sounds like it's
  bit-rotted.
 
  I took a stab at it a few years back, but distributing a binary
  tarball of data sourced from glibc seemed like a license violation,

 What license violation? The glibc library is released under the GPL

Actually it's released under LGPL, which is not actually the same
license. (Plus there was 2.1 vs 2.0 skew for a bit, and the glibc
developers were talking about switching to GPLv3 for a while until red
hat quashed it, and there was the whole mepis thing...)

 license and therefore you can freely redistribute and modify
 sources and even binary data.

And if you redistribute binaries without the corresponding sources you
get a shakedown from the FSF or the Conservancy asking for many
thousands of dollars.

  and I _really_ didn't want to throw a glibc source tarball in the
  uclbic download directory.

 I don't think you need to.

Allow me to introduce you to the Mepis disaster:
http://archive09.linux.com/articles/55285

The FSF went after Ubuntu derivative distro, which at the time had a
press release on its website quoting Mark Shuttleworth saying how
great it was that Mepis was basing itself on Ubunt. Mepis' crime was
not mirroring ubuntu source tarballs it hadn't modified. They pointed
at their upstream for stuff they hadn't modified, with the explicit
consent of Ubuntu, and the FSF said no, you must mirror it yourself.
How the FSF even got INVOLVED between the two parties, I couldn't tell
you, but they stuck their nose in and nearly bankrupted a small three
person garage operation.

In response to that, I added an explicit explanation of the busybox
FAQ saying if you use a vanilla unmodified busybox version and SAY
it's a vanilla unmodified version X and that you did not modify it,
you do not need to mirror the source tarball but can point at us
instead because we don't need you to give us code you already have, we
just want you to _identify_ it.

Bradley Cooper, the guy whose somewhat acromonious parting of the ways
with the Software Freedom Law Center resulted in founding the Software
Freedom Conservancy, has only ever pushed two git commits to the
busybox web repository. What they did was remove the safe harbor
provision I'd added:

http://git.busybox.net/busybox-website/commit/?id=09ea33fdd63acbf5160090e8563c0a9a35ff7f6f

(Second commit was basically a typo fix to the first.)

Note that I wrote the text he was removing (posted to the mailing
list), and new maintainer Denys Vlasenko is the one who checked it in
to the website:

http://git.busybox.net/busybox-website/commit/license.html?id=8ab0ffdccf6c429c8ddbaf21fce4f206859ab6f8

I yelled at Bradley about it on irc (on the public #uclibc channel,
October 10, 2013, you can probably pull it out of riker's ibot if you
want to scroll down far enough):

landley_ The paragraph starting: pSo if you built an unmodified
BusyBox release and you point people at the URL
landley_ -to the SPECIFIC source tarball on busybox.net you built it
from and truthfully
landley_ -say that's it, no patches, we've accepted that as
compliance even from
landley_ Got removed entirely.
landley_ It was not replaced with any rewording. It was removed.
bkuhn landley_: I know, I removed it because the GPLv2 just doesn't
allow that.  BusyBox is GPLv2-only.  I know *you* don't mind that, and
that we haven't *enforced* against anyone who does that, but it's just
not what the license says.

I.E. if we say on the busybox website that this behavior is ok for
this project (the ex-maintainer writing it, current maintainer
uploading it), that's not allowed because GPLv2 is magic, it's not our
license on our project that we're using to give permission to use our
copyrights, the FSF's interpretation trumps that of the developers
writing and releasing the code, The Convervancy reserves the right to
sue even if the project maintainers say no because ONE DEVELOPER
SOMEWHERE might disagree, and the FSF has a _history_ of taking action
on exactly these grounds.

So yes, I feel I would totally have to upload a copy of glibc source
tarball if we derived binary stuff from it because the FSF is a group
of foaming loonies with a history of suing their supposed friends
because they like persecuting minor heresies.

(I looked at extracting just the relevant source and it's an
incestuous tangle, as is all FSF code. One of the big advantages of
musl: it contains zero FSF code, and is in fact MIT-licensed, which is
basically the BSD license in a boston accent.)

  See probable license violation, above. (Maybe locale data isn't
  copyrightable? Scenes a' faire? No idea, not personally going there.
  You don't get these problems with musl.)

 I don't see 

Re: Locales strike back

[Rob Landley]

On Sun, May 31, 2015 at 4:13 AM, Jaromír Cápík tav...@seznam.cz wrote:

  Does anybody have working pre-generated
 locales for uClibc 0.9.30?
 I tried to generate them by myself on a glibc
 based system, but they are not generated
 properly and cause build errors with excess
 elements in array, etc.

 Please, tell me.

 This might be related to my post from March titled Broken assumptions
 in gen_wctype.
 Rich

 Hello Rich.

 I've read many threads about uClibc and locales, but
 none of them seems to bring a solution.

The guy who implemented locale support for uClibc, Manuel Nova,  never
quite finished it, and left the code with a config symbol manuel's
warnings. He wandered away from uClibc development almost ten years
ago, and nobody really inherited his work. Sounds like it's
bit-rotted.

I took a stab at it a few years back, but distributing a binary
tarball of data sourced from glibc seemed like a license violation,
and I _really_ didn't want to throw a glibc source tarball in the
uclbic download directory.



 0.9.28 worked well with the following pre-generated locales

 http://www.uclibc.org/downloads/uClibc-locale-030818.tgz

See probable license violation, above. (Maybe locale data isn't
copyrightable? Scenes a' faire? No idea, not personally going there.
You don't get these problems with musl.)

 0.9.30 doesn't crash and is re-buildable from the upstream
 provided system-image-m68k.tar.bz2, but it doesn't accept

 data from the above archive and when I enable download

 of pre-generated locales, it tries to pull a non-existent
 uClibc-locale-2008-32-eb.tgz archive.

Yeah, a patch was checked into uclibc but the corresponding file was
never updated. The commit says:

  http://git.busybox.net/uClibc/commit/?id=ab600d2ad032

We will retroactively fill them in, eventually but Bernhard was
underestimating how dead the project was. Keep in mind this happened
_after_ uClibc developement cratered back in 2007:

  http://lists.uclibc.org/pipermail/uclibc/2007-September/039215.html

Bernhard came in and tried to fix stuff. I myself tried to fix the
locale thing myself but hit the above license issues, so didn't upload
it:

  http://lists.busybox.net/pipermail/uclibc/2009-January/041758.html

There's a problem that uclibc was never quite an independent project,
it copied glibc headers, copied glibc locale data, snapshotted glibc's
thread implementation... If you don't care about licenses at all and
don't thing the FSF will ever sue you, then it's fine. If you _do_
treat the FSF like a wounded rabid weasel, and don't want to get any
of it on you, this poses a problem.

Basically you're underestimating how many years this project has been
struggling for. The above message about development stalling was from
2007, and the project never really recovered from that stall. The
third anniversary of the last-ever release was two weeks ago, and
that's over a year after bulidroot threatened to walk.

Meanwhile, musl's 1.0 release was a little over a year ago, it's going
strong, and a number of distros have adopted it. If you wonder why I
haven't been trying to fix stuff here like I used to, I've been
following the project since
http://landley.net/notes-2012.html#29-09-2012 or so...

 I'd like to find some workaround or enable at least basic
 support so that I could build packages with locale support
 till a solution is found.

Adding m68k support to musl is probably easier than fixing locale
support in uClibc.

No really.

 Anybody has got a copy of the above archive?

I don't think it was ever uploaded. I'm not sure it was ever actually made.

Rob
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Segmentation fault in __uClibc_main on m68k

[Rob Landley]

On Fri, May 29, 2015 at 1:00 PM, Jaromír Cápík tav...@seznam.cz wrote:

 On 29 May 2015 at 17:54, Jaromír Cápík tav...@seznam.cz wrote:

 You mentioned a distro you boottrapped a couple of weeks
 ago. Do you have a working rootfs environment I could
 test?

 I did not submit the m68k patch to OE yet since i meant to get gmp
 going first, no.
 



 I found a complete uclibc environment in the uclibc

 downloads. It's called system-image-m68k.tar.bz2

 and it's based on version 0.9.30.

That sounds like my aboriginal linux output. There should be newer
ones at http://landley.net/aboriginal/downloads/binaries/ or
http://landley.net/aboriginal/downloads/old/binaries/ based on the
last-ever uClibc release from 2012 plus a pile of patches in
http://landley.net/hg/aboriginal/file/tip/sources/patches

That said, I've given up on uclibc development and am following
musl-libc.org these days. At this point, I wouldn't care if uclinux
_did_ have a new release. The 3+ year gap since the last release is
AFTER I SENT TWO CAKES to get this unblocked last decade. I created a
buildroot list and evicted the other project's traffic off this one. I
appointed a new maintainer more or less by fiat.

None of it helped, and I'm through playing sisyphos. The problem is
_chronic_ and apparently unsolvable, which means this project is
essentially already dead. It just hasn't noticed because it's
_that_dead_.

Remember how eglibc was created in response to the vacuum uClibc left.
The reason eglibc went away is that vacuum got filled. Between musl
and a slowly improving bionic sucking your developers away, I expect
the number of people bothering the uClibc developers for a new release
has dropped considerably. That's because the number of people who
would care about a new uClibc release even if it happened at this
point has dropped considerably, because they've moved on.

Of course somebody did a uclibc-ng fork (bought the domain name and
everything), but I talked to him and his reason for doing it is there
are some obscure targets even glibc doesn't support, and I expect that
as musl grows support for those targets his reasons for doing it will
gradually fade away. *shrug* We'll see.

Remember when buildroot announced they would switch their default libc
if the uClibc developers couldn't get a new release out? Remember how
that was over a year ago, ala
http://lists.busybox.net/pipermail/uclibc/2014-February/048252.html ?
Well instead what happened was
http://lists.busybox.net/pipermail/buildroot/2013-October/079661.html
became 
http://git.buildroot.net/buildroot/commit/?id=c29799330464fb5d152f1b3d550fcbda69c58a3d
which became 
https://www.phoronix.com/scan.php?page=news_itempx=Musl-Libc-GCC-Support
and at this point it's pretty much over except the cleanup. They
didn't _announce_ a migration, they just did it. At this point if
uClibc had a new release I expect they'd smile and nod and _continue_
not to care because there are better alternatives now, once that
haven't established a pattern of chronic multi-year development
constipation.

The only reason I haven't switched aboriginal over yet (added support
to build musl but didn't make it the default) is I'm busy with other
things. The current blocker is I need to update my linux from scratch
6.8 native build, which is my big smoketest for each aboriginal linux
release when I update the kernel and toybox and such. several packages
in there have big #ifdef/else staircases with lists of known build
environments and end with #error or doing something really stupid if
they can't recognize your libc. Yes, even if nothing's wrong, they
break just because they don't recognize the _name_ of the build
environment. Mostly FSF crap. The way uclibc dealt with that was by
lying and claiming to be glibc. Musl pushes fix patches upstream into
the other packages instead, but that involves upgrading to package
versions that have the fix or applying the fix yourself, and I've
needed to upgrade my LFS build version anyway, so...

Anyway, good luck with your m68k port.( I've poked the musl maintainer
about adding that but he hasn't got a test environment and Laurent
Vivier's qemu-q800 fork _still_ isn't merged. I should follow up and
poke on that again, but my todo list runneth over...)

Rob
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Switching from uClibc to glibc as the default in Buildroot?

[Rob Landley]

On 06/11/14 02:35, Thomas Petazzoni wrote:
 Dear Jody Bruchon,
 
 On Tue, 10 Jun 2014 17:43:34 -0400, Jody Bruchon wrote:
 
 I'm waiting for musl to be sufficiently stable at this point;

It seems reasonably stable to me. I keep meaning to port my aboriginal
linux project over to it but toybox is eating all my non-work
development time. (I test toybox using the musl wrapper, which sadly
means I'm only testing the x86-64 musl variant. Test of the testing is
still against glibc and the old patched-up uClibc in aboriginal.)

 musl is indeed a very interesting project, and we've added support for
 it in Buildroot in our last release. The musl developers are very
 reactive and helpful when we're facing issues.
 
 However, one thing that musl doesn't handle currently is the support
 for noMMU architectures. This remains an area where uClibc is essential.
 
 it's hard to keep a libc patched on my own. Perhaps a fork of the
 project is in order?
 
 It looks to me that a fork is now the only solution. However, this
 requires someone having a good knowledge of the uClibc internals and
 the time to maintain a new project, which is not that easy to find.

Adding nommu support to musl would be easier than maintaining a uClibc
fork. The big blocker is lack of a nommu test environments: those of us
who don't do it yet tend not to have one set up.

Is there an existing nommu test image that runs under qemu? (Possibly
one of http://wiki.qemu.org/Testing#QEMU_disk_images perhaps?) Adding a
musl chroot under a working system is a lot easier than getting an
initial kernel, emulator, and some libc agree enough to boot to a shell
prompt setup working for a new layout.

Rob
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: non-interactive build question

[Rob Landley]

On 10/14/2013 11:43:34 AM, Steve Ellcey wrote:


I am new to building uclibc,


And I'm about two weeks behind on my email. :)


but have experience building glibc and newlib,
and I have a question about the best way to build multiple versions  
of uclibc

from a script without any user interaction.

Currently, I run 'make defconfig' to create a default .config file  
and then
use grep to modify the .config file before each build (strip out some  
lines
and then append my versions back in).  I.e. I remove the  
ARCH_BIG_ENDIAN=y
line and then add in a ARCH_LITTLE_ENDIAN=y line. to change from  
big-endian
to little-endian or I may pick a different MIPS ABI.  But what I  
noticed is
that when I run the normal 'make' command after modifying .config is  
that my
.config changes are getting wiped out and .config is getting restored  
to a

default state.

Can someone explain why this is happening and if there is a way to  
prevent

it?  Is there a better way to do multiple uclibc builds with different
defaults and without requiring any user interaction?


In Aboriginal Linux I use the miniconfig technique, which starts with  
allnoconfig and switches on specific symbols, allowing dependency  
resolution to happen to each one. You basically make a file going


  CONFIG_BLAH=y
  CONFIG_THINGY=42

And so on for each symbol you'd modify by hand if you were doing a  
menuconfig after allnoconfig, and then you go:


  make allnoconfig KCONFIG_ALLCONFIG=mini.conf

My basic uClibc config is here:

  http://landley.net/hg/aboriginal/file/1620/sources/baseconfig-uClibc

That's the set of symbols common to all architures. The build adds the  
architecture specific symbols from the architecture config files in  
targets directory:


  http://landley.net/hg/aboriginal/file/1620/sources/targets

So in the case of armv5l it adds:

  TARGET_arm=y
  CONFIG_ARM_EABI=y
  ARCH_WANTS_LITTLE_ENDIAN=y
  DOPIC=y

For sparc it adds this instead:

  TARGET_sparc=y
  UCLIBC_HAS_FPU=y
  FORCE_SHAREABLE_TEXT_SEGMENTS=y

I note that I patched my copy of uClibc to remove the pointless  
ARCH_HAS_MMU symbol:


   
http://landley.net/hg/aboriginal/file/1620/sources/patches/uClibc-mmu.patch


If you don't patch ARCH_HAS_MMU out, you'll have to add it to your  
config in order to be able to say ARCH_USE_MMU (which is the actual  
meaningful symbol).


Rob
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH] argv[0] of execvp when ENOEXEC

[Rob Landley]

On 08/21/2013 09:16:29 AM, Wei-cheng Wang wrote:

On Wed, Aug 21, 2013 at 6:12 PM, Denys Vlasenko
vda.li...@googlemail.com wrote:
 On Tue, Aug 20, 2013 at 6:42 PM, Wei-cheng Wang cole...@gmail.com  
wrote:

 You mean, this happens if foo.sh is a non-executable file
  Yes.  foo.sh a shell script with execute permission without #! at
the very first line.
  For example,
  $ echo echo hello  ./foo.sh
  $ chmod a+x ./foo.sh
  $ ./foo.sh
  hello
 and /bin/sh is a symlink to busybox?
  Yes. busybox, toybox, toolbox (android) and similar tools use this  
way to

  provides multiple Unix tools with a single executable binary.


gzip/gunzip detecting whether to force the -d flag predates them all by  
a decade, and I'm told the bell labs guys were already doing it in the  
70's in Programmer's Workbench...


Rob
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH] argv[0] of execvp when ENOEXEC

[Rob Landley]

On 08/21/2013 12:52:26 PM, Rich Felker wrote:

On Wed, Aug 21, 2013 at 12:36:00PM -0500, Rob Landley wrote:
 On 08/21/2013 09:16:29 AM, Wei-cheng Wang wrote:
 On Wed, Aug 21, 2013 at 6:12 PM, Denys Vlasenko
 vda.li...@googlemail.com wrote:
  On Tue, Aug 20, 2013 at 6:42 PM, Wei-cheng Wang
 cole...@gmail.com wrote:
  You mean, this happens if foo.sh is a non-executable file
   Yes.  foo.sh a shell script with execute permission without #! at
 the very first line.
   For example,
   $ echo echo hello  ./foo.sh
   $ chmod a+x ./foo.sh
   $ ./foo.sh
   hello
  and /bin/sh is a symlink to busybox?
   Yes. busybox, toybox, toolbox (android) and similar tools use
 this way to
   provides multiple Unix tools with a single executable binary.

 gzip/gunzip detecting whether to force the -d flag predates them all
 by a decade, and I'm told the bell labs guys were already doing it
 in the 70's in Programmer's Workbench...

This analogy is not relevant because gzip/gunzip are not part of POSIX
and the specification of execvp does not require invoking them in a
way that breaks with the multicall binary idiom.


It's relevant in that it's a common usage going back almost 40 years,  
and individual problematic cases can have a trivial wrapper.


Rob
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

O_NOFOLLOW is not a gnu extension, it's posix-2008.

[Rob Landley]

Files like libc/sysdeps/linux/powerpc/bits/fcntl.h have blobs like:

#ifdef __USE_GNU
# define O_DIRECT   040 /* Direct disk access.  */
# define O_DIRECTORY 04 /* Must be a directory.  */
# define O_NOFOLLOW 010 /* Do not follow links.  */
# define O_NOATIME  0100 /* Do not set atime.  */
# define O_CLOEXEC  0200 /* Set close_on_exec.  */
#endif

Meaning that if you don't #define GNU_DAMMIT you don't get symbols  
Posix-2008 has been requiring for several years now:


file:///home/landley/reading/SUSv4/basedefs/fcntl.h.html

Which is why you don't need the #define to use O_NOFOLLOW in glibc.

This is hard to work around because the value of the symbol varies  
per-target.


Rob
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Alternatives to Buildroot for Native Compilation and Testing?

[Rob Landley]

On 02/28/2013 03:17:05 PM, Jeffrey Walton wrote:

Hi All,

Are there any alternatives for testing uClibc on the native platform?


Use qemu. I have build scripts and prebuilt binary images:

http://landley.net/aboriginal/about.html
http://landley.net/aboriginal/bin


I don't need a complete embedded system (which is what Buildroot
appears to provide). In addition, Buildroot does not provide the
compiler I want to use.

Lack of familiarity is hindering me. All I want to do is:

  make CC=clang other CFLAGS
  make test

What are the alternatives for building? My apologies for my ignorance.


My system images come with a native gcc+uClibc toolchain. In theory you  
could natively build clang on target, but it's not an existing build  
option...


(Automated native build stuff is the  
http://landley.net/aboriginal/control-images stuff. There's  
documentation on the website if you want to go down that rabbit hole...)


Rob
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [OTish] getaddrinfo(), DNS client library (was: Crash in gethostbyname() on congruent usage)

[Rob Landley]

On 12/13/2012 07:37:41 AM, Rich Felker wrote:

On Thu, Dec 13, 2012 at 08:43:01AM +0100, Laurent Bercot wrote:
Only a tiny class of software needs to lookup MX records. I agree it's
flaw (which could easily be fixed with new flags) that getaddrinfo
can't lookup other records like MX (needed for mail delivery), SVR
(needed for SIP), etc., but the impact is relatively low. If you think
it's that important I'll open an issue with the Austin Group about
getting such things added to the next revision of POSIX.


Can't deprecate the old one with gaping holes in the new one, and  
adding redundant apis to do the same darn thing is sad.


Rob
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Has anybody actually tested x86-64 with NPTL in 0.9.33.1?

[Rob Landley]

On 05/15/2012 12:16 PM, Bernhard Reutner-Fischer wrote:
 On Mon, May 14, 2012 at 06:04:41PM -0500, Rob Landley wrote:
 Attempting to build NPTL on x86-64 does this:

  LD libpthread-0.9.33.2-git.so
 /home/landley/aboriginal/aboriginal/build/simple-cross-compiler-x86_64/lib/../x86_64-unknown-linux/bin/ld:
 libpthread/nptl/libpthread_so.a(pthread_once.oS): relocation
 R_X86_64_PC32 against `__fork_generation' can not be used when making a
 shared object; recompile with -fPIC
 /home/landley/aboriginal/aboriginal/build/simple-cross-compiler-x86_64/lib/../x86_64-unknown-linux/bin/ld:
 final link failed: Bad value
 
 Old toolchain, maybe? Please mail me that .config.

The same last gplv2 releases of gcc and binutils I've been using to
build uClibc for a while now. (Now that the next release of freebsd is
ditching it for clang I suppose I should look at that. Pity though, I
was hoping pcc might amount to something.)

Config attached.

Rob
-- 
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's mere aggregation, or a license violation.  Pick one.
#
# Automatically generated make config: don't edit
# Version: 0.9.33.2-git
# Sun May 13 23:25:08 2012
#
# TARGET_alpha is not set
# TARGET_arm is not set
# TARGET_avr32 is not set
# TARGET_bfin is not set
# TARGET_cris is not set
# TARGET_e1 is not set
# TARGET_frv is not set
# TARGET_h8300 is not set
# TARGET_hppa is not set
# TARGET_i386 is not set
# TARGET_i960 is not set
# TARGET_ia64 is not set
# TARGET_m68k is not set
# TARGET_microblaze is not set
# TARGET_mips is not set
# TARGET_nios is not set
# TARGET_nios2 is not set
# TARGET_powerpc is not set
# TARGET_sh is not set
# TARGET_sh64 is not set
# TARGET_sparc is not set
# TARGET_v850 is not set
# TARGET_vax is not set
TARGET_x86_64=y
# TARGET_xtensa is not set
# TARGET_c6x is not set

#
# Target Architecture Features and Options
#
TARGET_ARCH=x86_64
FORCE_OPTIONS_FOR_ARCH=y
TARGET_SUBARCH=

#
# Using ELF file format
#
ARCH_LITTLE_ENDIAN=y

#
# Using Little Endian
#
ARCH_USE_MMU=y
UCLIBC_HAS_FLOATS=y
UCLIBC_HAS_FPU=y
DO_C99_MATH=y
# DO_XSI_MATH is not set
UCLIBC_HAS_FENV=y
# UCLIBC_HAS_LONG_DOUBLE_MATH is not set
KERNEL_HEADERS=/usr/include
HAVE_DOT_CONFIG=y

#
# General Library Settings
#
# DOPIC is not set
HAVE_SHARED=y
# FORCE_SHAREABLE_TEXT_SEGMENTS is not set
# LDSO_LDD_SUPPORT is not set
LDSO_CACHE_SUPPORT=y
# LDSO_PRELOAD_ENV_SUPPORT is not set
# LDSO_PRELOAD_FILE_SUPPORT is not set
LDSO_BASE_FILENAME=ld-uClibc.so
# LDSO_STANDALONE_SUPPORT is not set
# LDSO_PRELINK_SUPPORT is not set
UCLIBC_STATIC_LDCONFIG=y
LDSO_RUNPATH=y
LDSO_SEARCH_INTERP_PATH=y
LDSO_LD_LIBRARY_PATH=y
# LDSO_NO_CLEANUP is not set
UCLIBC_CTOR_DTOR=y
# LDSO_GNU_HASH_SUPPORT is not set
# HAS_NO_THREADS is not set
# LINUXTHREADS_OLD is not set
# LINUXTHREADS_NEW is not set
UCLIBC_HAS_THREADS_NATIVE=y
UCLIBC_HAS_THREADS=y
UCLIBC_HAS_TLS=y
# PTHREADS_DEBUG_SUPPORT is not set
UCLIBC_HAS_SYSLOG=y
UCLIBC_HAS_LFS=y
# MALLOC is not set
# MALLOC_SIMPLE is not set
MALLOC_STANDARD=y
MALLOC_GLIBC_COMPAT=y
UCLIBC_DYNAMIC_ATEXIT=y
# COMPAT_ATEXIT is not set
UCLIBC_SUSV3_LEGACY=y
UCLIBC_SUSV3_LEGACY_MACROS=y
UCLIBC_SUSV4_LEGACY=y
# UCLIBC_STRICT_HEADERS is not set
# UCLIBC_HAS_STUBS is not set
UCLIBC_HAS_SHADOW=y
UCLIBC_HAS_PROGRAM_INVOCATION_NAME=y
UCLIBC_HAS___PROGNAME=y
UCLIBC_HAS_PTY=y
ASSUME_DEVPTS=y
UNIX98PTY_ONLY=y
# UCLIBC_HAS_GETPT is not set
UCLIBC_HAS_LIBUTIL=y
UCLIBC_HAS_TM_EXTENSIONS=y
UCLIBC_HAS_TZ_CACHING=y
UCLIBC_HAS_TZ_FILE=y
UCLIBC_HAS_TZ_FILE_READ_MANY=y
UCLIBC_TZ_FILE_PATH=/etc/TZ
# UCLIBC_FALLBACK_TO_ETC_LOCALTIME is not set

#
# Advanced Library Settings
#
UCLIBC_PWD_BUFFER_SIZE=256
UCLIBC_GRP_BUFFER_SIZE=256

#
# Support various families of functions
#
UCLIBC_LINUX_MODULE_26=y
# UCLIBC_LINUX_MODULE_24 is not set
UCLIBC_LINUX_SPECIFIC=y
UCLIBC_HAS_GNU_ERROR=y
UCLIBC_BSD_SPECIFIC=y
UCLIBC_HAS_BSD_ERR=y
UCLIBC_HAS_OBSOLETE_BSD_SIGNAL=y
UCLIBC_HAS_OBSOLETE_SYSV_SIGNAL=y
UCLIBC_NTP_LEGACY=y
UCLIBC_SV4_DEPRECATED=y
UCLIBC_HAS_REALTIME=y
UCLIBC_HAS_ADVANCED_REALTIME=y
UCLIBC_HAS_EPOLL=y
UCLIBC_HAS_XATTR=y
UCLIBC_HAS_PROFILING=y
UCLIBC_HAS_CRYPT_IMPL=y
# UCLIBC_HAS_SHA256_CRYPT_IMPL is not set
# UCLIBC_HAS_SHA512_CRYPT_IMPL is not set
UCLIBC_HAS_CRYPT=y
UCLIBC_HAS_NETWORK_SUPPORT=y
UCLIBC_HAS_SOCKET=y
UCLIBC_HAS_IPV4=y
UCLIBC_HAS_IPV6=y
UCLIBC_HAS_RPC=y
UCLIBC_HAS_FULL_RPC=y
UCLIBC_HAS_REENTRANT_RPC=y
# UCLIBC_USE_NETLINK is not set
# UCLIBC_HAS_BSD_RES_CLOSE is not set
# UCLIBC_HAS_COMPAT_RES_STATE is not set
# UCLIBC_HAS_EXTRA_COMPAT_RES_STATE is not set
# UCLIBC_HAS_RESOLVER_SUPPORT is not set
UCLIBC_HAS_LIBRESOLV_STUB=y
UCLIBC_HAS_LIBNSL_STUB=y

#
# String and Stdio Support
#
UCLIBC_HAS_STRING_GENERIC_OPT=y
UCLIBC_HAS_STRING_ARCH_OPT=y
UCLIBC_HAS_CTYPE_TABLES=y
UCLIBC_HAS_CTYPE_SIGNED=y
UCLIBC_HAS_CTYPE_UNSAFE=y
# UCLIBC_HAS_CTYPE_CHECKED is not set
# UCLIBC_HAS_CTYPE_ENFORCED is not set
UCLIBC_HAS_WCHAR=y
# UCLIBC_HAS_LOCALE is not set
# UCLIBC_HAS_HEXADECIMAL_FLOATS is not set
UCLIBC_HAS_GLIBC_CUSTOM_PRINTF

Re: Unable to build x86_64 on x86_64

[Rob Landley]

On 05/10/2012 03:23 AM, Piotr Karbowski wrote:
 /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/../../../../x86_64-pc-linux-gnu/bin/as:
 error while loading shared libraries: libc.so.0: cannot open shared

Oh, you hit the Fedora bug!

So far, that problem only occurred to me on Fedora.  I have a test
environment I've been meaning to track it down in, but I just moved to a
new house and everything's still packed. (I finally have all the cables
to set everything back up, but it is The Time Of Day Job again, so
probably this weekend.)

 The host is gentoo.

Lemme guess: you have ccache installed?

That's more or less what I was poking at when I had to pack up the server...

Rob
-- 
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's mere aggregation, or a license violation.  Pick one.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Unable to build x86_64 on x86_64

[Rob Landley]

Here's Denys Vlasenko hitting what I think is the same bug a couple
months ago:

http://lists.landley.net/pipermail/aboriginal-landley.net/2012-March/000384.html

I've been meaning to track it down ever since but moving to a new house
kinda screwed up my todo lists...

As I said, it seems like a ccache issue. The host shouldn't leak like
that, but with ccache installed it does anyway...

Rob
-- 
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's mere aggregation, or a license violation.  Pick one.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH] support kernels without __ARCH_WANT_SYSCALL_OFF_T

[Rob Landley]

On 04/30/2012 03:28 PM, Laurent Bercot wrote:
 Can you report your uClibc configuration? I'm nearly certain you have
 locale disabled; if it's enabled, a lot more junk will be pulled in.
 
  I'm not sure. I'm using the binary uClibc-0.9.32.1 provided by the
 Aboriginal Linux native-compiler-i686 toolchain, I don't know what
 options have been compiled in. Cc to Rob so he can provide the
 configuration.

Look in the src directory of the cross compiler, the uClibc config is
in there.  (Or in /usr/src of the root filesystem images.)

I think locale is disabled too: last I looked the uClibc build process
didn't contain its own locale information but harvested it from the
host, which means it's a build break if you select locales the host
hasn't got, and there was no sane subset guaranteed to be there. (Even
the minimal locales involved more locale support than my basic Gentoo
server install had, and I'm in en-us...)

It's one of those issues I revisit every year or two and go nope, still
doesn't work...

 Also I don't understand how using _exit changes anything. The startup
 code that calls main has a reference to exit (or equivalent code)
 anyway and has no way of determining that you'll be calling _exit
 early...

  I can only guess that gcc sees that main() is never returned from
 and optimizes away everything that's referenced *after* the main()
 call in _startup(). But I'm really not an expert on those things and
 it's a wild, wild guess.

Denys Vlasenko gave a nice talk on this sort of thing in 2010:

http://www.embeddedlinuxconference.com/elc_2010/sessions.html#Vlasenko
http://elinux.org/images/2/2d/ELC2010-gc-sections_Denys_Vlasenko.pdf
http://free-electrons.com/pub/video/2010/elc/elc2010-vlasenko-dead-code.ogv

Rob
-- 
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's mere aggregation, or a license violation.  Pick one.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH] Fixing sh4 and sparc builds.

[Rob Landley]

On 10/27/2011 09:38 AM, Austin Foxley wrote:
 On 07/29/2011 08:04 PM, Rob Landley wrote:
 On 07/29/2011 02:34 PM, Bernhard Reutner-Fischer wrote:

 On Jul 21, 2011 11:05 PM, Rob Landleyr...@landley.net
 mailto:r...@landley.net  wrote:

 I needed the following patch to make sh4 and sparc build with
 pthreads.old in current git:

 diff --git a/libc/sysdeps/linux/sh/Makefile.arch
 b/libc/sysdeps/linux/sh/Makefile.arch
 index 92e262b..6cbc681 100644
 --- a/libc/sysdeps/linux/sh/Makefile.arch
 +++ b/libc/sysdeps/linux/sh/Makefile.arch
 @@ -9,4 +9,4 @@
   CSRC := \
 mmap.c pipe.c __init_brk.c brk.c sbrk.c pread_write.c
 cacheflush.c

 -SSRC := setjmp.S __longjmp.S ___fpscr_values.S vfork.S
 +SSRC := setjmp.S __longjmp.S ___fpscr_values.S vfork.S clone.S
 diff --git a/libc/sysdeps/linux/sparc/Makefile.arch
 b/libc/sysdeps/linux/sparc/Makefile.arch
 index d0cae9f..820b2fa 100644
 --- a/libc/sysdeps/linux/sparc/Makefile.arch
 +++ b/libc/sysdeps/linux/sparc/Makefile.arch
 @@ -13,7 +13,7 @@ SSRC := \

   ifneq ($(UCLIBC_HAS_THREADS_NATIVE),y)
   CSRC += sigaction.c
 -SSRC += fork.S vfork.S
 +SSRC += fork.S vfork.S clone.S
   endif

   # check weather __LONG_DOUBLE_128__ is defined (long double support)

 I also had to symlink:

   ln -s ../../../linuxthreads/sysdeps/pthread/tcb-offsets.h
 libpthread/linuxthreads.old/sysdeps/pthread/tcb-offsets.h

 Because you only have that link in the new pthreads and the sparc
 build breaks looking for it on the old one.

 Sounds odd, it should long be used by NPTL, IIRC.

 If I don't symlink (or in my patch, drop a file there that #includes
 ../../../blahblahblah) then it does this:

 libc/sysdeps/linux/sparc/clone.S:26:25: error: tcb-offsets.h: No such
 file or directory
 make: *** [libc/sysdeps/linux/sparc/clone.os] Error 1
 make: *** Waiting for unfinished jobs

 Because sparc's clone.S (which, without the makefile change never got
 built), does in fact include that file.  which is only there in the new
 pthread and nptl, but not pthread.old.

 Here's the config I used, and the patch I used.

 Rob
 
 
 Applied the sparc part of the patch for linuxthreads.old. It looks like
 it was my fault it got broken back in 2009 when I was adding nptl
 support to sparc. Sorry about that.
 
 -Austin

Yay!

I occasionally poke at NPTL support, but it's not working for me:

  http://lists.busybox.net/pipermail/uclibc/2011-March/045020.html

  http://lists.uclibc.org/pipermail/uclibc/2011-October/045835.html

Need to track down why...

Rob
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: static compile help

[Rob Landley]

On 10/11/2011 06:43 AM, Jed Evnull wrote:
 I'm having problems statically compiling arm code with a uclibc toolchain
 generated by buildroot-2011.08. My goal is to statically link against uclibc
 for the small filesize. I'm compiling outside buildroot, per the
 instructions.
 
 The uclibc toolchain (generated via buildroot) seems to work. I can compile
 a simple hello.c program statically (arm-linux-gcc hello.c -o hello -static
 -s ) but source packages like lighttpd, or joe editor fail with various
 errors. No source package has compiled to completion.  I start a compile
 with ./configure --host=arm-linux CC=arm-linux-gcc
 
 Am I going about this in the wrong way, or misusing the tools?

http://landley.net/writing/docs/cross-compiling.html

(Which is why I did http://landley.net/aboriginal/about.html .)

Rob
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Building a uclibc based toolchain

[Rob Landley]

On 10/20/2011 03:30 AM, stl wrote:
 Hello all,
 I am trying to build my own uClibc based linux toolchain for a new 
 architecture.

I have scripts that do this at http://landley.net/aboriginal which are
just bash scripts you should be able to read along with reasonably easily.

Hint: the build_section shell function calls the relevant script out
of sources/sections, all the patches I apply are in sources/patches, and
all the target-secific information is in sources/targets.  The
scriptsthemselves are fully target agnotic and no there aren't even if
POWERPC bits in them, I mean got them to actually be _clean_.  90% of
the other plumbing under sources is to make downloading, extracting, and
patching source tarballs, and then deleting the result when done, happen
for you.

The magic I'm doing with the compressed config file format is explained at:

  http://landley.net/aboriginal/FAQ.html#dev_miniconfig

The presentation slides for my big long design talk on this (including
rationale, implementation, and expected use cases) are online in HTML or
PDF format:


http://speakerdeck.com/u/mirell/p/developing-for-non-x86-targets-using-qemu
  http://landley.net/aboriginal/downloads/presentation.pdf

My why cross compiling sucks document is at:

  http://landley.net/writing/docs/cross-compiling.html

The syllabus for my cross-compiling tutorial I gave at OLS 2007 is at:

  http://landley.net/ols/ols2007/tutorial.txt

A video of the OLS compiler BOF I hosted in 2008 is at:

http://free-electrons.com/pub/video/2008/ols/ols2008-rob-landley-linux-compiler.ogg

Hopefully something in there is useful to you. :)

 I follow the following steps:
 
 1 - I compile binutils
 2 - I copy the specific and generic linux headers (from my port of
 linux) into ${HEADERS_DIR}
 3 - I compile gcc only with --enable-language=c and
 --with-headers=${HEADERS_DIR}
 4 - I compile uClibc with the previously compiled gcc
 5 - I recompile gcc with --enable-language=c,c++
 
 All is fine for the four first steps.
 But I have a question:
 
 When uClibc building is done, where should I install the uClibc
 libraries (libc.a, librt.a, etc...)
 and headers?
 
 Where gcc expects to find them?

There's a whole rant in the compiler BOF video (which really shouldn't
have been all me talking but people kept asking me questions) about how
the word pathological was not invented to describe teh GCC path logic,
 But _should_have been.

The short answer is it's not that simple.  The long answer wanders
through kill it with fire and version-specific workarounds.  Once upon
a time the uClibc guys wrote a wrapper script, which I've updated and
it's what I use in my toolchains:

  http://landley.net/hg/aboriginal/file/1461/sources/toys/ccwrap.c

 Because, when I recompile gcc (step 5), I get GCC_NO_EXECUTABLE fatal error.
 The config.log shows me that the crt1.o and some standard headers are 
 missing..

Here's a blog entry from two years ago where I ranted about compiler
path logic and the six paths the compiler has to keep stright, but which
gcc fundamentally _can't_:

  http://landley.net/notes-2009.html#21-11-2009

There are actually multiple .o files involved here. (If I recall crt1.o
comes from libc, crtbegin.o and crtend.o come from your compiler
implementation), although the six paths breakdown doesn't distinguish
between build-time and runtime dependencies which only really come up
when you're dynamic linking.  (I suppose the dynamic linker path should
be #7 on that list, although the compiler doesn't _use_ it and just has
to record it.  I'm glossing over TLS linking against ld-linux.so because
in that case it's using it _as_ a system library, so that's already
covered.)

Note that ccwrap.c does all thsi by hand, telling teh compiler
-nostdinc and -nostdlib and then manually explicitly adding back
everything at the correct location.  (Only way to get sane behavior out
of gcc is to take path logic decisions out of its hands.)

Rob
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: uclibc 0.9.5

[Rob Landley]

On 09/23/2011 05:23 PM, iggi wrote:
 Yann,
 
 Thank you for the response, but it looks like they moved from CVS after that
 date.

Erik moved from CVS to SVN around 2005, and then the git was cloned from
the SVN, so the full history back to 2000 _is_ in the git archive.

The reason the full _project_ history isn't in the archive is that the
project goes back long before Erik, for gory details see:

http://web.archive.org/web/200102051514/http://cvs.uclinux.org/uClibc.html

(And yes, I hate the way thunderbird wraps links and that there's no
obvious way to prevent it from doing that.)

 Unless I am missing something, I can't find  way to get a tarball from
 that time.

Unfortunately, the really old versions predate uClibc and busybox having
their own website, back when the release tarballs were on
ftp://oss.lineo.com.  The website is archived in the wayback machine,
but the _ftp_ site wasn't.  And lineo went under in the dotcom bust...

That said, the version you're looking for _has_ to be in the git archive
because if you go back to the beginning:

  git log | tail -n 1000

A couple of the early commits are:

  commit 7b9cd2baf91a1f7f0cd364758102cec4e0f9c2c1
  Author: Erik Andersen ander...@codepoet.org
  Date:   Wed May 17 02:16:00 2000 +

  More tests. Seems malloc isn't working...
   -Erik

  commit 9b7a1c1c4b4cbb1257b19caa92ccd9b765b1f01b
  Author: Erik Andersen ander...@codepoet.org
  Date:   Tue May 16 05:38:45 2000 +

Add in the _start symbol in asm.  Fix a makefile (that needs to be
abstracted I suppose for platforms (though I am doing fine w/o
libcrt*) and add function prototype for exit into stdlib.h (it was
missing... odd). Compiles vs uC-libc are less noisy now.
   -Erik

  commit d2d67c9856355f732c83f060e0c69b2e520db65e
  Author: Erik Andersen ander...@codepoet.org
  Date:   Mon May 15 22:10:56 2000 +

  Finished porting stuff to x86 and supporting the Linux 2.2
  kernels. It now compiles
   -Erik

So if it works for you at ALL you're using something after that.  (The
first commit didn't even COMPILE, then it didn't _link_, and then malloc
didn't work for quite some time while Erik checked in test cases...)

Ooh, here's an interesting one:

  commit 38b20649403f2cbffc4581211f1b61868e3b358f
  Author: Eric Andersen ander...@codepoet.org
  Date:   Mon Jun 19 21:51:18 2000 +

  Add in a version number so apps can tell uclib is being used.
   -Erik

Let's see...  git show 38b20649403f2cb is where the version numbers were
first added (0.9.1), and that touched include/features.h so let's look
at a log of _that_ file...

  commit 0ea968c3e603da9da9c8ae8f81382d105127ab2d
  Author: Eric Andersen ander...@codepoet.org
  Date:   Thu Dec 21 16:21:27 2000 +

  Sync version number with Makefile

And _that_ one sets it to 5, but implies that it got changed somewhere
else first.  So let's look at the _big_ log starting from that commit...

I really, really, really hate git.  Show a file at a revision should
not be esoteric knowlege.  (What's git's equivalent of hg cat -r
revision?  It's not _quite_ git show 0ea968c3e603da9 -- Makefile
because that just shows me the CHANGE to that one file.  Oh well,
annotate is overkill but shows me the darn data... and Makefile has no
version stamp?  Huh?  Ok, mkdir sub; git archive 0ea968c3e603da9 | tar
xC sub and... doesn't seem to be in Rules.mak either?  Or in any of the
subdir Makefiles)

What on _earth_ was Erik talking aboutin the commit message then?  Let's
see,

  $ make help
  Rules.mak:25: Config: No such file or directory
  make: *** No rule to make target `Config'.  Stop.

Beautiful.  The version number was probably in a Config file that wasn't
checked in...

Ah, and note this commit in 2002:

 58bd16ab173a4df7b

-/* Major and minor version number of the uClibc library package.  Use
-   these macros to test for features in specific releases.  */
-#define__UCLIBC__  0
-#define__UCLIBC_MAJOR__9
-#define__UCLIBC_MINOR__5
+/* This macro indicates that the installed library is uClibc.  Use
+ * __UCLIBC_MAJOR__ and __UCLIBC_MINOR__ to test for the features in
+ * specific releases.  */
+#define__UCLIBC__  1
+
+/* Major and minor version number of the uClibc library package are
+ * can be used to test for features in specific uClibc releases.
+ *
+ * Now included from bits/uClibc_config.h */
+#if 0
+/* For uClibc release 0.9.12, these numbers would be: */
+#define__UCLIBC_MAJOR__0
+#define__UCLIBC_MINOR__9
+#define__UCLIBC_SUBLEVEL__ 12
+#endif

So yeah, versions 5-11 all identified themselves as 5.  (Are you sure
you actually _have_ 5?)  But _that_ was also identifying MINOR_VERSION
in Rules.mak, so let's trace back the changes to that line with a lot of
git annotate $VERSION^1 -- Rules.mak and...

git annotate aa6ece75^1 -- Rules.mak | grep MINOR
8f2286fd(Eric 

Re: usefulness of UCLIBC_CTOR_DTOR ?

[Rob Landley]

On 08/12/2011 04:01 PM, Yann E. MORIN wrote:
 So, two questions:
 - is it at all possible to generate a proper uClibc-based toolchain without
   those two files?

Yes, I've done it.

 - even so, are those 132 bytes really worth an option in the menuconfig?

You could pretty much ask that about any part of uClibc until we're back
at glibc.

Rob
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH] Fixing sh4 and sparc builds.

[Rob Landley]

On 07/29/2011 02:34 PM, Bernhard Reutner-Fischer wrote:
 
 On Jul 21, 2011 11:05 PM, Rob Landley r...@landley.net
 mailto:r...@landley.net wrote:

 I needed the following patch to make sh4 and sparc build with
 pthreads.old in current git:

 diff --git a/libc/sysdeps/linux/sh/Makefile.arch
 b/libc/sysdeps/linux/sh/Makefile.arch
 index 92e262b..6cbc681 100644
 --- a/libc/sysdeps/linux/sh/Makefile.arch
 +++ b/libc/sysdeps/linux/sh/Makefile.arch
 @@ -9,4 +9,4 @@
  CSRC := \
mmap.c pipe.c __init_brk.c brk.c sbrk.c pread_write.c cacheflush.c

 -SSRC := setjmp.S __longjmp.S ___fpscr_values.S vfork.S
 +SSRC := setjmp.S __longjmp.S ___fpscr_values.S vfork.S clone.S
 diff --git a/libc/sysdeps/linux/sparc/Makefile.arch
 b/libc/sysdeps/linux/sparc/Makefile.arch
 index d0cae9f..820b2fa 100644
 --- a/libc/sysdeps/linux/sparc/Makefile.arch
 +++ b/libc/sysdeps/linux/sparc/Makefile.arch
 @@ -13,7 +13,7 @@ SSRC := \

  ifneq ($(UCLIBC_HAS_THREADS_NATIVE),y)
  CSRC += sigaction.c
 -SSRC += fork.S vfork.S
 +SSRC += fork.S vfork.S clone.S
  endif

  # check weather __LONG_DOUBLE_128__ is defined (long double support)

 I also had to symlink:

  ln -s ../../../linuxthreads/sysdeps/pthread/tcb-offsets.h
 libpthread/linuxthreads.old/sysdeps/pthread/tcb-offsets.h

 Because you only have that link in the new pthreads and the sparc
 build breaks looking for it on the old one.
 
 Sounds odd, it should long be used by NPTL, IIRC.

If I don't symlink (or in my patch, drop a file there that #includes
../../../blahblahblah) then it does this:

libc/sysdeps/linux/sparc/clone.S:26:25: error: tcb-offsets.h: No such
file or directory
make: *** [libc/sysdeps/linux/sparc/clone.os] Error 1
make: *** Waiting for unfinished jobs

Because sparc's clone.S (which, without the makefile change never got
built), does in fact include that file.  which is only there in the new
pthread and nptl, but not pthread.old.

Here's the config I used, and the patch I used.

Rob
The sh4 and sparc targets have assembly implementations of clone.S that don't
get used, and thus the build breaks.  Also, sparc is missing a header file in
pthreads.old that exists in pthreads.new.

diff --git a/libc/sysdeps/linux/sh/Makefile.arch b/libc/sysdeps/linux/sh/Makefile.arch
index 92e262b..6cbc681 100644
--- a/libc/sysdeps/linux/sh/Makefile.arch
+++ b/libc/sysdeps/linux/sh/Makefile.arch
@@ -9,4 +9,4 @@
 CSRC := \
 	mmap.c pipe.c __init_brk.c brk.c sbrk.c pread_write.c cacheflush.c
 
-SSRC := setjmp.S __longjmp.S ___fpscr_values.S vfork.S
+SSRC := setjmp.S __longjmp.S ___fpscr_values.S vfork.S clone.S
diff --git a/libc/sysdeps/linux/sparc/Makefile.arch b/libc/sysdeps/linux/sparc/Makefile.arch
index d0cae9f..820b2fa 100644
--- a/libc/sysdeps/linux/sparc/Makefile.arch
+++ b/libc/sysdeps/linux/sparc/Makefile.arch
@@ -13,7 +13,7 @@ SSRC := \
 
 ifneq ($(UCLIBC_HAS_THREADS_NATIVE),y)
 CSRC += sigaction.c
-SSRC += fork.S vfork.S
+SSRC += fork.S vfork.S clone.S
 endif
 
 # check weather __LONG_DOUBLE_128__ is defined (long double support)
--- /dev/null	2011-07-15 06:34:19.820919508 -0500
+++ uClibc/libpthread/linuxthreads.old/sysdeps/sparc/tcb-offsets.h	2011-07-23 19:53:02.079880519 -0500
@@ -0,0 +1 @@
+#include ../../../linuxthreads/sysdeps/pthread/tcb-offsets.h
#
# Automatically generated make config: don't edit
# Version: 0.9.32
# Fri Jul 29 21:57:45 2011
#
# TARGET_alpha is not set
# TARGET_arm is not set
# TARGET_avr32 is not set
# TARGET_bfin is not set
# TARGET_cris is not set
# TARGET_e1 is not set
# TARGET_frv is not set
# TARGET_h8300 is not set
# TARGET_hppa is not set
# TARGET_i386 is not set
# TARGET_i960 is not set
# TARGET_ia64 is not set
# TARGET_m68k is not set
# TARGET_microblaze is not set
# TARGET_mips is not set
# TARGET_nios is not set
# TARGET_nios2 is not set
# TARGET_powerpc is not set
# TARGET_sh is not set
# TARGET_sh64 is not set
TARGET_sparc=y
# TARGET_v850 is not set
# TARGET_vax is not set
# TARGET_x86_64 is not set
# TARGET_xtensa is not set
# TARGET_c6x is not set

#
# Target Architecture Features and Options
#
TARGET_ARCH=sparc
FORCE_OPTIONS_FOR_ARCH=y
# CONFIG_SPARC_V7 is not set
CONFIG_SPARC_V8=y
# CONFIG_SPARC_V9 is not set
# CONFIG_SPARC_V9B is not set
TARGET_SUBARCH=

#
# Using ELF file format
#
ARCH_BIG_ENDIAN=y

#
# Using Big Endian
#
ARCH_USE_MMU=y
UCLIBC_HAS_FLOATS=y
UCLIBC_HAS_FPU=y
DO_C99_MATH=y
# DO_XSI_MATH is not set
UCLIBC_HAS_FENV=y
# UCLIBC_HAS_LONG_DOUBLE_MATH is not set
KERNEL_HEADERS=/usr/include
HAVE_DOT_CONFIG=y

#
# General Library Settings
#
# HAVE_NO_PIC is not set
DOPIC=y
# ARCH_HAS_NO_SHARED is not set
# ARCH_HAS_NO_LDSO is not set
HAVE_SHARED=y
FORCE_SHAREABLE_TEXT_SEGMENTS=y
# LDSO_LDD_SUPPORT is not set
LDSO_CACHE_SUPPORT=y
# LDSO_PRELOAD_ENV_SUPPORT is not set
# LDSO_PRELOAD_FILE_SUPPORT is not set
LDSO_BASE_FILENAME=ld-uClibc.so
UCLIBC_STATIC_LDCONFIG=y
LDSO_RUNPATH=y
LDSO_SEARCH_INTERP_PATH=y
UCLIBC_CTOR_DTOR=y
# LDSO_GNU_HASH_SUPPORT is not set
# HAS_NO_THREADS is not set
LINUXTHREADS_OLD=y

Re: Toolchain test suite

[Rob Landley]

On 07/24/2011 08:23 PM, manish kumar wrote:
 Hi,
 
 Is there any official test suite to verify the stability of
 tool-chain, specifically uClibc based? And is this official test
 suite maintained by community as well? I am looking for maximum
 coverage of tool-chain functionality and not just uClibc specific
 ones.

I have an automated build of Linux From Scratch, natively under qemu on
a dozen different CPU targets.  Does that count?

Rob
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

[PATCH] Fixing sh4 and sparc builds.

[Rob Landley]

I needed the following patch to make sh4 and sparc build with 
pthreads.old in current git:

diff --git a/libc/sysdeps/linux/sh/Makefile.arch 
b/libc/sysdeps/linux/sh/Makefile.arch
index 92e262b..6cbc681 100644
--- a/libc/sysdeps/linux/sh/Makefile.arch
+++ b/libc/sysdeps/linux/sh/Makefile.arch
@@ -9,4 +9,4 @@
 CSRC := \
mmap.c pipe.c __init_brk.c brk.c sbrk.c pread_write.c cacheflush.c
 
-SSRC := setjmp.S __longjmp.S ___fpscr_values.S vfork.S
+SSRC := setjmp.S __longjmp.S ___fpscr_values.S vfork.S clone.S
diff --git a/libc/sysdeps/linux/sparc/Makefile.arch 
b/libc/sysdeps/linux/sparc/Makefile.arch
index d0cae9f..820b2fa 100644
--- a/libc/sysdeps/linux/sparc/Makefile.arch
+++ b/libc/sysdeps/linux/sparc/Makefile.arch
@@ -13,7 +13,7 @@ SSRC := \
 
 ifneq ($(UCLIBC_HAS_THREADS_NATIVE),y)
 CSRC += sigaction.c
-SSRC += fork.S vfork.S
+SSRC += fork.S vfork.S clone.S
 endif
 
 # check weather __LONG_DOUBLE_128__ is defined (long double support)

I also had to symlink:

  ln -s ../../../linuxthreads/sysdeps/pthread/tcb-offsets.h 
libpthread/linuxthreads.old/sysdeps/pthread/tcb-offsets.h

Because you only have that link in the new pthreads and the sparc build breaks 
looking for it on the old one.

Rob
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [ANNOUNCE] uClibc-0.9.32 released

[Rob Landley]

On 06/14/2011 03:53 AM, Bernhard Reutner-Fischer wrote:
 On Mon, Jun 13, 2011 at 06:55:43PM +0200, Carmelo AMOROSO wrote:
 On 08/06/2011 22.04, Bernhard Reutner-Fischer wrote:
 Hi,

 We are pleased to announce the release of uClibc-0.9.32.

 Numerous bugfixes and alot of overall improvement went into this
 release:
 It contains NPTL (Native POSIX Thread Library) support for the following
 architecures:
 - arm
 - i386
 - mips
 - powerpc
 - sh
 - sh64
 - x86_64

 Bernd Schmidt from codesourcery.com kindly contributed a new port for
 the c6x family of Texas Instruments DSPs.

 Thanks to everybody who made this release happen!

 Enjoy!
 ___
 uClibc mailing list
 uClibc@uclibc.org
 http://lists.busybox.net/mailman/listinfo/uclibc


 Hi Bernard,
 that's great... but there some git issue I guess.

 On master branch, Rules.mak is still

 # Now config hard core
 MAJOR_VERSION := 0
 MINOR_VERSION := 9
 SUBLEVEL  := 32
 EXTRAVERSION  :=-rc3-git
 
 I've corrected this.

 Further I can't see the tag v0.9.32 associated with the commit
 buildsys: fix pregen target (!NPTL with LOCALE)

 on master branch it seems that the 0.9.32 branch has diverged ??? I
 don't know.
 
 I don't understand.. We now have a 0.9.32 branch where future dot
 releases for 0.9.32.x will come from (like v0.9.32 itself).
 
 What's your concern?

You're supposed to tag _then_ branch.  If you branch and then only tag
the branch, you can't git bisect between tags because they cross
unmerged branches.

I.E. you broke git bisect, and probably other stuff.  Look at what the
kernel guys do.

Rob
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: New libgcc_eh dependency for ARM_EABI targets

[Rob Landley]

On 06/10/2011 06:51 PM, Kevin Cernekee wrote:
 Commit 4916fd88 (present in v0.9.32, but not in v0.9.32-rc3) created a
 new dependency on libgcc_eh.a for the final link stage:
 
 uClibc-0.9.32/libubacktrace/Makefile.in:
 
 ifeq ($(CONFIG_ARM_EABI),y)
 LIBGCC += $(shell $(CC) -print-file-name=libgcc_eh.a)
 endif
 
 I build gcc stage 1 with --disable-shared, which causes libgcc_eh.a
 not to be built:
 
 gcc-4.5.2/libgcc/Makefile.in:
 
 ifeq ($(enable_shared),yes)
 all: libgcc_eh.a libgcc_s$(SHLIB_EXT)
 ...
 
 Therefore, I am not able to build uClibc 0.9.32 with my gcc stage 1
 compiler.  This worked fine on uClibc 0.9.32-rc3.

I'm still using 0.9.31 because NTPL doesn't work on half the platforms I
tried in -rc3, and because building pthreads x86_64 had a link failure
claiming it was mixing PIC and non-pic code when it tried to make
libc.so.0.  I was waiting for the next -rc.  I consider this release
the next rc and will get around to debugging whatever's wrong with it
when I find time.

Nobody's going to pay any attention until uClibc has a 1.0 release anyway...

 I see that Rob Landley has patched his gcc source tree so that it
 always builds libgcc_eh.a.  Is this the recommended procedure going
 forward?

I dunno about recommended.  By who?  There are people using buildroot
(which is a repository accumulating build descriptions for the bitbake
build tool), people using openembedded, people using scratchbox, and
about 30 other weird toolsets out there.  (Just about all of them seem
to have gone over to eglibc, but oh well.)

The reason I'm building libgcc_eh.a in the stage one compiler is A) I
needed it to build uClibc++, B) there's no earthly reason to have to
build your compiler more than once just to cross compile a target system
you then boot into and continue natively under the emulator.  The fact
that gcc tries to force you to do it is one of the many quirks of
gcc's design.

Rob
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Paper comparing speed of uClibc and Glibc

[Rob Landley]

On 05/11/2011 01:56 AM, Zdeněk Materna wrote:
 Hello,
 
 
 is there any paper comparing speed of uClibc and Glibc? I googled for
 a while, but couldn't find any. I assume that uClibc is faster, but I
 can't just declare it in diploma thesis. Thanks a lot for any tips.

It's faster in some things and slower in others.  Mostly it's not the
limiting factor on performancce, the rest of your program is.

Note that uClibc is aimed at _size_, not _speed_.  On some chips it's
faster because more code fits in cache, but other times there's a more
efficient algorithm that eats more memory (assuming that your DRAM bus
isn't your performance limiting factor, which is again hardware-specific)...

You have to run benchmarks, and they're always workload-specific.

Rob
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Can't build m4 or bison with -rc3.

[Rob Landley]

On 03/20/2011 01:02 AM, Khem Raj wrote:
  On 3/19/2011 10:17 PM, Rob Landley wrote:
  I'm running my Linux From Scratch 6.7 build under a uClibc root
  filesystem, and building m4 1.14.4 has this error:
 
  gcc -std=gnu99  -I. -g -O2 -MT execute.o -MD -MP -MF
  .deps/execute.Tpo -c -o execute.o execute.c
  In file included from execute.c:47:
  ./spawn.h:112: error: field '_sp' has incomplete type
  distcc[23848] ERROR: compile execute.c on localhost failed
  make[3]: *** [execute.o] Error 1
  make[3]: Leaving directory `/home/m4/lib'
 
  Apply the fixes e.g.
 
http://git.openembedded.org/cgit.cgi/openembedded/tree/recipes/bison/bison-2.4.3/uclibc-sched_param-def.patch

Translation: uClibc is permanently broken, and we have no choice but to
start crapping #ifdef uClibc all over other packages to get them to work
with special cases just for us, when in the previous version we could
actually fix uClibc.

Unless that goes upstream into m4 and those maintainers accept the
permanent burden of regression testing against our broken special case,
it's a workaround, not a fix.

Rob

___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Can't build m4 or bison with -rc3.

[Rob Landley]

On 03/22/2011 06:01 PM, Khem Raj wrote:
 On (22/03/11 16:42), Rob Landley wrote:
 On 03/20/2011 01:02 AM, Khem Raj wrote:
 On 3/19/2011 10:17 PM, Rob Landley wrote:
 I'm running my Linux From Scratch 6.7 build under a uClibc root
 filesystem, and building m4 1.14.4 has this error:

 gcc -std=gnu99  -I. -g -O2 -MT execute.o -MD -MP -MF
 .deps/execute.Tpo -c -o execute.o execute.c
 In file included from execute.c:47:
 ./spawn.h:112: error: field '_sp' has incomplete type
 distcc[23848] ERROR: compile execute.c on localhost failed
 make[3]: *** [execute.o] Error 1
 make[3]: Leaving directory `/home/m4/lib'

 Apply the fixes e.g.
 http://git.openembedded.org/cgit.cgi/openembedded/tree/recipes/bison/bison-2.4.3/uclibc-sched_param-def.patch

 Translation: uClibc is permanently broken, we have no choice but to
 start crapping #ifdef uClibc all over other packages to get them to work
 with special cases just for us, when in the previous version we could
 actually fix uClibc.

 
 heh so you mean whatever glibc does is right ?

If the package is expecting something specifically because we're
exporting _GLIBC_?  Yes.

Your fix isn't removing a _GLIBC_ dependency, it's adding another
special case for uClibc.  I really don't see how that's an improvement.

Rob
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Building -rc3 x86-64 NPTL failed for me.

[Rob Landley]

  LD libpthread-0.9.32-rc3.so
/home/landley/play/aboriginal/build/simple-cross-compiler-x86_64/lib/../x86_64-unknown-linux/bin/ld:
libpthread/nptl/libpthread_so.a(pthread_once.oS): relocation
R_X86_64_PC32 against `__fork_generation' can not be used when making a
shared object; recompile with -fPIC
/home/landley/play/aboriginal/build/simple-cross-compiler-x86_64/lib/../x86_64-unknown-linux/bin/ld:
final link failed: Bad value

Looks like libpthread_so.a was built without -fpic...?

This was using a toolchain and config that pthreads.old worked with...

Rob
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Can't build m4 or bison with -rc3.

[Rob Landley]

I'm running my Linux From Scratch 6.7 build under a uClibc root
filesystem, and building m4 1.14.4 has this error:

gcc -std=gnu99  -I. -g -O2 -MT execute.o -MD -MP -MF
.deps/execute.Tpo -c -o execute.o execute.c
In file included from execute.c:47:
./spawn.h:112: error: field '_sp' has incomplete type
distcc[23848] ERROR: compile execute.c on localhost failed
make[3]: *** [execute.o] Error 1
make[3]: Leaving directory `/home/m4/lib'


The attached patch made m4 and bison build against 0.9.31, but it
doesn't fix it in 0.9.32-rc3.  Apparently uClibc has optimized away
fields that both m4 and bison are reaching out and touching directly.

(Oh, and some of the time the configure test to see if strstr happens in
linear time hangs indefinitely, the alarm() that's supposed to wake it
up apparently doesn't.  For that one it might be relevant that I'm
currently testing on mips, for the rest it's not target specific.)

Rob
diff -ru uClibc/libc/sysdeps/linux/common/bits/sched.h uClibc.bak/libc/sysdeps/linux/common/bits/sched.h
--- uClibc/libc/sysdeps/linux/common/bits/sched.h	2010-04-02 10:34:27.0 -0500
+++ uClibc.bak/libc/sysdeps/linux/common/bits/sched.h	2010-10-15 13:38:43.0 -0500
@@ -61,6 +61,7 @@
 # define CLONE_STOPPED	0x0200 /* Start in stopped state.  */
 #endif
 
+#undef sched_param
 /* The official definition.  */
 struct sched_param
   {
@@ -82,6 +83,8 @@
 
 __END_DECLS
 
+#else
+#define sched_param __sched_param
 #endif	/* need schedparam */
 
 #if !defined __defined_schedparam \
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [ANNOUNCE] 0.9.32-rc3 released

[Rob Landley]

On 03/18/2011 09:25 AM, Bernhard Reutner-Fischer wrote:
 Rob Landley rland...@parallels.com wrote:
 
 On 03/16/2011 02:44 PM, Bernhard Reutner-Fischer wrote:  Hi,  
 I'm happy to announce that we now have a 0.9.32-rc3.  This is
 planned to be the last RC before the release which we aim at  doing
 in 2 weeks, i.e end of March.   Please test this release candidate
 and report back. So in the Linux kernel, make V=1 gives you the
 actual command lines that make is calling. That's also how it works
 in uClibc 0.9.31. But now, make V=1 does... nothing that I can see.
 Instead to get the actual kernel command lines you have to say V=2.
 But if you feed V=2 to the kernel build, you get pages and pages of
 _why_ it's rebuilding each thing it's building, a flood of
 dependency information which makes the output pretty much
 unreadable. So uClibc used ot work like the kernel does, and no it
 no longer does, for no readily apparent reason. This broke my build
 scripts, or at least the ability to easily figure out why arm eabi
 and i686 are including libgcc_eh.a in their build but mips and
 arm-oabi aren't... Rob 
 
 
 Hi Rob,
 
 V=1 is quiet plus defines. V=2 are verbatim commands. I don't know (nor
 care) what the kernel does

So your build infrastructure (including make menuconfig and V=1) was
copied from the Linux kernel, the previous release had a meaning that
was compatible with the Linux kernel, and you decided to gratuitously
change it because you don't care.

 for V=2 but if you want make to spit out
 dependency decisions then just run
 make -d -p
 or something.

I don't want dependency decisions.  I want V=1 to give me verbatim
commands the ay it did in 0.9.31.

You broke compatability with your _previous_release_.

 Note that we do _not_ use kbuild in uClibc, so please
 don't expect kbuild behaviour...

I expected 0.9.31 behavior.

Rob
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

arm-oabi and mips and such not building for me with NPTL.

[Rob Landley]

So the NPTL versions of i686 and arm-eabi build with the same invocation
pthreads.old used, but none of the other targets I've tried do.  Instead
those fail with:

libpthread/nptl/libpthread_so.a(pthread_once.oS): In function
`__pthread_once_internal':
pthread_once.c:(.text+0x78): undefined reference to `_Unwind_SjLj_Register'
libpthread/nptl/libpthread_so.a(pthread_once.oS): In function `.L15':
pthread_once.c:(.text+0x164): undefined reference to `_Unwind_SjLj_Resume'
pthread_once.c:(.text+0x16c): undefined reference to
`_Unwind_SjLj_Unregister'
pthread_once.c:(.text+0x180): undefined reference to `__gcc_personality_sj0'
collect2: ld returned 1 exit status

Those symbols live in libgcc_eh.a so I tried adding that to the end of
the build command line.  Now it dies with:

/home/landley/play/aboriginal/build/simple-cross-compiler-armv4l/bin/../cc/lib/libgcc_eh.a(unwind-sjlj.o):
In function `_Unwind_GetCFA':
unwind-sjlj.c:(.text+0x54): multiple definition of `_Unwind_GetCFA'
libpthread/nptl/libpthread_so.a(unwind-forcedunwind.oS):unwind-forcedunwind.c:(.text+0x108):
first defined here
/home/landley/play/aboriginal/build/simple-cross-compiler-armv4l/lib/../armv4l-unknown-linux/bin/ld:
Warning: size of symbol `_Unwind_GetCFA' changed from 64 in
libpthread/nptl/libpthread_so.a(unwind-forcedunwind.oS) to 16 in
/home/landley/play/aboriginal/build/simple-cross-compiler-armv4l/bin/../cc/lib/libgcc_eh.a(unwind-sjlj.o)
collect2: ld returned 1 exit status

I am kind of amused that the uClibc version is 64 bytes and the gcc
version is 16...

Rob
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: arm-oabi and mips and such not building for me with NPTL.

[Rob Landley]

On 03/18/2011 09:51 AM, Peter Mazinger wrote:
 Hi Rob
 
 So the NPTL versions of i686 and arm-eabi build with the same invocation
 pthreads.old used, but none of the other targets I've tried do.  Instead
 those fail with:

 libpthread/nptl/libpthread_so.a(pthread_once.oS): In function
 `__pthread_once_internal':
 pthread_once.c:(.text+0x78): undefined reference to
 `_Unwind_SjLj_Register'
 libpthread/nptl/libpthread_so.a(pthread_once.oS): In function `.L15':
 pthread_once.c:(.text+0x164): undefined reference to `_Unwind_SjLj_Resume'
 pthread_once.c:(.text+0x16c): undefined reference to
 `_Unwind_SjLj_Unregister'
 pthread_once.c:(.text+0x180): undefined reference to
 `__gcc_personality_sj0'
 collect2: ld returned 1 exit status
 
 if that is missing from libgcc*, you might want to compile gcc with
 --enable-sjlj-exceptions

I did.  I also compiled it with --disable-shared since it's a stage 1
compiler, so the code wound up in libgcc_eh.a.

I build a stage 1 compiler, then build the target system (busybox,
uClibc, and a native toolchain) with that.  None of that actually needs
thread support, but uClibc needs to exist before building a stage 2
compiler (so it can link libgcc_s.so against it).

Previously I was building uClibc once and it always worked fine.  (The
stack unwinding code is actually used these days by setjmp/longjmp so it
needs to be present as part of most toolchains.)  Unfortunately, the
uClibc build sequence for NPTL is manually overriding the toolchain's
normal link stuff but isn't including libgcc_eh.a, and when I patch it
in (which I'm willing to do at this end), it conflicts with a symbol
that libpthread_so.a redundantly implements.

The weird part is that the old build sequence still works fine,
unmodified, for arm-eabi and i686, even with NPTL...

 Peter

Rob
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: pregenerated locales

[Rob Landley]

On 03/04/2011 10:54 AM, Peter Mazinger wrote:
 Hi,
 
 were can I find the referenced (extra/locale/Makefile.in) pregenerated 
 locales? Is there some download site for them as I find only the really old 
 one from 2003
 
 Thanks, Peter

This is vaguely on my todo list since forever.

Relevant blog entries about my last struggle with uClibc
internationalization in november are at:

  http://landley.net/notes-2010.html#17-11-2010
  http://landley.net/notes-2010.html#19-11-2010
  http://landley.net/notes-2010.html#20-11-2010

I need to take a new stab at it with current -git.

The problem I had with just making a pregen locale tarball is uClibc
doesn't contain locale data, it copies it out of glibc.  And that gets
into GPL preferred source questions which bernhard had one opinion on
and I wasn't sure I was comfortable with.  (It's in the list archive
somewhere a few months back.)

In February somebody had a patch so the uClibc locale generation ran
better under uClibc, I dunno if this avoids the need for external
locales or not.

Rob
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: LEGAL: LG Electronics LGPL violations

[Rob Landley]

On 02/23/2011 12:20 AM, Mike Frysinger wrote:
 On Tuesday, February 22, 2011 23:38:02 Rob Landley wrote:
 On 02/22/2011 05:18 PM, Mike Frysinger wrote:
 On Wednesday, January 12, 2011 02:52:19 jenya wrote:
 RELEASE of 50PK550-ZE is dynamically linked now.
 We recommend you update your TV with latest version and you can make
 RELEASE without object files. 

 I replied that they were required to provide the object files for the
 version that is installed on my TV when buying (am I right? Correct me
 if not).

 i think this question is better posed to the SFLC.  from my non-lawyer
 understanding, if they are no longer distributing binary releases, the
 fact you received one in the past is no longer relevant.

 By that logic, if I pirate a bunch copies of Office, Microsoft can't go
 after me for damages but can only get a cease and desist preventing me
 from shipping any _more_ copies in future.  That's not actually how
 copyright law works.
 
 i was talking about license enforcement from jenya's point of view.  
 copyright 
 law is irrelevant when jenya doesnt hold any copyrights on the code in 
 question.

No it isn't.  The license terms obligate them to provide source code to
him, even years after they distribute the binaries.  Denys and I did a
big long explanation of our interpretation of the details here, and ran
it by the SFLC to polish out anything obviously wrong with it:

  http://busybox.net/license.html

(3B says 3 years but if they didn't provide a written offer with the
device there's a good case that the clock hasn't started yet.  Some
details may differ in LGPLv2 vs GPLv2, but the principle's the same.
The uClibc project could distance itself from busybox if it wanted to,
but probably only by claiming a more _rigid_ interpretation since Erik
Andersen founded both projects and he's onboard with the SFLC.)

So to be in compliance with the license terms, the company needs to
offer/deliver source code to Jenya if they created Jenya's binaries from
our copyrighted code.

You're right that if the company isn't in compliance with the license
terms Jenya hasn't got standing to sue, which is where the SFLC comes
in: as the designated legal representatives of the project's maintainers
and some senior developers, they do.

Complying with the license terms by satisfying Jenya's claims is the
issue the SFLC would be suing _about_.  That's not irrelevant.

 -mike

Rob
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: LEGAL: LG Electronics LGPL violations

[Rob Landley]

On 02/23/2011 05:18 PM, Mike Frysinger wrote:
 On Wednesday, February 23, 2011 14:18:11 Rob Landley wrote:
 On 02/23/2011 12:20 AM, Mike Frysinger wrote:
 On Tuesday, February 22, 2011 23:38:02 Rob Landley wrote:
 On 02/22/2011 05:18 PM, Mike Frysinger wrote:
 On Wednesday, January 12, 2011 02:52:19 jenya wrote:
 RELEASE of 50PK550-ZE is dynamically linked now.
 We recommend you update your TV with latest version and you can make
 RELEASE without object files. 

 I replied that they were required to provide the object files for the
 version that is installed on my TV when buying (am I right? Correct me
 if not).

 i think this question is better posed to the SFLC.  from my non-lawyer
 understanding, if they are no longer distributing binary releases, the
 fact you received one in the past is no longer relevant.

 By that logic, if I pirate a bunch copies of Office, Microsoft can't go
 after me for damages but can only get a cease and desist preventing me
 from shipping any _more_ copies in future.  That's not actually how
 copyright law works.

 i was talking about license enforcement from jenya's point of view. 
 copyright law is irrelevant when jenya doesnt hold any copyrights on the
 code in question.

 No it isn't
 
 yeah, it really is.  you yourself said so:
 You're right that if the company isn't in compliance with the license
 terms Jenya hasn't got standing to sue
 .  The license terms obligate them to provide source code to
 him, even years after they distribute the binaries.
 
 3 years isnt relevant if the company simply doesnt bother to comply with that 
 release (which is what LV seems to be doing for their static builds).  the 
 penalty for non-compliance from Jeny'a pov is that they no longer get to 
 distribute the binaries.  which is what they've done.

1) The SFLC has gotten source releases out of companies.

2) They're telling him to upgrade to a new version, which they have no
incentive to reliably distribute source for, and your advice to people
is to accept that because we set up an enforcement mechanism purely for
our own entertainment which should never actually be _used_.

If Jenya decided not to go through with it, fine, but you saying that
the SFLC isn't ever worth messing with is yet another strange judgement
call of yours which I strongly disagree with.

Rob
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: LEGAL: LG Electronics LGPL violations

[Rob Landley]

On 02/22/2011 05:18 PM, Mike Frysinger wrote:
  On Wednesday, January 12, 2011 02:52:19 jenya wrote:
  RELEASE of 50PK550-ZE is dynamically linked now.
  We recommend you update your TV with latest version and you can make
  RELEASE without object files. 
 
  I replied that they were required to provide the object files for the
  version that is installed on my TV when buying (am I right? Correct me
  if not).
  
  i think this question is better posed to the SFLC.  from my non-lawyer 
  understanding, if they are no longer distributing binary releases, the fact 
  you received one in the past is no longer relevant.

By that logic, if I pirate a bunch copies of Office, Microsoft can't go
after me for damages but can only get a cease and desist preventing me
from shipping any _more_ copies in future.  That's not actually how
copyright law works.

But yeah, you want to talk to the SFLC.  I think we have a
g...@uclibc.org alias set up (if not g...@busybox.net works, all the same
guys reading it).

Rob
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [ANNOUNCE] 0.9.32-rc1 released

[Rob Landley]

On 02/22/2011 05:23 PM, Mike Frysinger wrote:
 On Monday, December 27, 2010 15:30:21 Peter Korsgaard wrote:
 There unfortunately seems to be an issue on ppc with NPTL and
 UCLIBC_USE_NETLINK=y

   CC libc/inet/herror.os
   CC libc/inet/if_index.os
 In file included from libc/inet/if_index.c:37:
 libc/inet/netlinkaccess.h:29: error: redefinition of typedef '__u8'
 /home/peko/source/buildroot/output/toolchain/linux/include/asm-generic/int-
 ll64.h:20: note: previous declaration of '__u8' was here

 stdio.h seems to eventually include asm/types.h, which then conflicts
 with the local typedefs in netlinkaccess.h. The same config works on
 ARM.

 Why are we adding those local typedefs in the first place? They were
 added back in 2006 by Mike, but the commit message doesn't really
 explain why:
 
 i think you forget how screwed up kernel headers used to be
 -mike

Which is why Maszur provided sanitized headers and distros provided
sanitized headers before make headers_install was introduced (circa
2.6.15) to sanitize its own headers.  An environment that used
unsanitized (or improperly sanitized) 2.6 headers was always broken, and
adding bugs to uClibc to work around a broken toolchain or environment
was never the correct approach.

Rob
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Ah, figured out the -mfdpic thing, [PATCH] included.

[Rob Landley]

On 02/21/2011 06:03 PM, Mike Frysinger wrote:
 On Friday, February 11, 2011 21:34:22 Rob Landley wrote:
 On 02/11/2011 12:55 PM, Bernhard Reutner-Fischer wrote:
 On Thu, Feb 10, 2011 at 01:42:01PM -0600, Rob Landley wrote:
 I mentioned that my build was dying due to trying to use -mfdpic which

 is a target-specific option for the FRV processor:

 It's not only for FRV, it's also used on bfin (should be fixed in the
 docs).

 Right, so when mike changed that in gcc he didn't bother to update the
 docs, when he changed it in uClibc he didn't bother to put any docs on
 the config entry...
 
 no idea what you're talking about.  i didnt do the gcc nor uClibc port for 
 FDPIC for Blackfin processors.

Then whoever did didn't update the gcc man page.

I assumed it was you because you didn't add help test for the
UCLIBC_FORMAT_FDPIC_ELF menu entry in commit 14db067a8bdcd,
you maintained an out-of-tree uClibc blackfin tree back when
Erik handed maintainership of uClibc off to you and then you didn't
post on the list for three months, and you were the guy working
on qemu support for blackfin back when we had this exchange:

  http://comments.gmane.org/gmane.linux.kernel.embedded/39

But I can't say I've been keeping particularly close track,
my bad.

 Why do you want to have two user-visible symbols that mean exactly the
 same thing?  (What part of my explanation was incorrect?)
 
 no, the has mmu is there for the kconfig tree to make the the use mmu 
 available to the user.  the source then keys off of use mmu.  nowhere does 
 the user select i have a mmu, they only select i want to use the mmu.  
 seems pretty straightforward to me.
 -mike

Do a make allnoconfig, then select target architecture arm.

Now go to the target architecture features and options menu,
and confirm the following cut and paste:

  │ │Target ABI (OABI)  ---  │ │  
  │ │Target Processor Type (Generic Arm)  ---│ │  
  │ │Target File Format (FDPIC ELF)  --- │ │  
  │ │Target Processor Endianness (Big Endian)  ---   │ │  
  │ │[*] Target CPU has a memory management unit (MMU)│ │  
  │ │[ ]   Do you want to utilize the MMU?│ │  
  │ │[ ] Enable floating point number support │ │  
  │ │(/usr/include) Linux kernel header location

There is ARCH_HAS_MMU, user selectable, and ARCH_USE_MMU,
being separately user selectable.

There is no reason for both symbols to even EXIST, let alone
the user having to separately select both of them.  Luckily
this is just arm, it's not like anybody actually _uses_
the single most common CPU type on the planet...

Rob
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [not x86 host; not glibc host; build error] bootstrapping uclibc with locale support: is it possible at all?

[Rob Landley]

On 02/14/2011 04:36 PM, Douglas Mencken wrote:
  any attempt to build uclibc with UCLIBC_HAS_LOCALE=yes yields with:
 
LN include/bits/posix_opt.h
HOSTCC extra/locale/gen_wc8bit -D__UCLIBC_GEN_LOCALE
  -DCTYPE_PACKED=1 -DDO_WIDE_CHAR=1
  extra/locale/gen_wc8bit.c: In function 'main':
  extra/locale/gen_wc8bit.c:375:28: warning: array subscript is above
array bounds
  extra/locale/gen_wc8bit.c:434:29: warning: array subscript is above
array bounds
  extra/locale/gen_wc8bit.c:500:27: warning: array subscript is above
array bounds
GEN extra/locale/codesets.txt
GEN extra/locale/c8tables.h
  sh: locale: not found
  make: *** [extra/locale/c8tables.h] Error 1

I got locale support to sort of work in Aboriginal Linux last year, when
I was building Linux From Scratch under uClibc, although it was
converting locale data from the build host rather than containing its
own so I wound up switching it off again because it introduced extra
build dependencies.  (I need to package up the minimal ones for all the
appropriate targets, it's on my todo list, but the way uClibc was trying
to do it shipped the binaries of LGPL code without shipping the source...)

I blogged about it several times:

  http://landley.net/notes-2010.html#17-11-2010
  http://landley.net/notes-2010.html#19-11-2010
  http://landley.net/notes-2010.html#20-11-2010

Basically I switched on these symbols:

  UCLIBC_HAS_LOCALE=y
  UCLIBC_HAS_XLOCALE=y
  UCLIBC_BUILD_MINIMAL_LOCALE=y

And then debugged a lot.

HOSTCC extra/locale/gen_locale -D_GNU_SOURCE
  In file included from extra/locale/gen_locale.c:13:0:
  extra/locale/c8tables.h:1:7: error: expected '=', ',', ';', 'asm' or
  '__attribute__' before 'not'
  extra/locale/gen_locale.c: In function 'do_locale_names':
  extra/locale/gen_locale.c:227:42: error: 'lc_names' undeclared (first
  use in this function)
  extra/locale/gen_locale.c:227:42: note: each undeclared identifier is
  reported only once for each function it appears in
  extra/locale/gen_locale.c: In function 'lc_monetary_C':
  extra/locale/gen_locale.c:1083:2: warning: #warning fix the char
  entries for monetary... target signedness of char may be different!
  make: *** [extra/locale/gen_locale] Error 1
  ERROR: 'make' error. Abort.

It produces gazillions of warning as a matter of course.

  ./extra/locale/gen_wc8bit.c does include this:
 
   if (!setlocale(LC_CTYPE, en_US.UTF-8)) {
  /* Silly foreigners disabling en_US locales */
  fp = popen(locale -a, r);
 
  I don't know anything about any silly foreigners, but I'm sure that
  uclibc built w/o UCLIBC_HAS_LOCALE set to yes has nor 'setlocale'
  returning non-zero, nor 'locale' command.
  So how is it possible to bootstrap locale-aware uclibc?

You need locales installed on the build machine.  I.E. it pretty mch
only builds on a glibc host.

Sucks, doesn't it?

  Also (from 'extra/locale/gen_wc8bit.c'):
 
  int main(int argc, char **argv)
  {
  FILE *fp;
 
  and then
 
  FILE *fp = popen(locale -a, r);
 
  does anyway produce an error, despite any host/target (which at least
  is easily correctable: just remove FILE * from FILE *fp).

This infrastructure was never finished.  It _mostly_ works, but has some
serious rough edges, is non-obvious to set up, and may have bit-rotted a
bit with newer distro locale source files.

Manuel Nova started work on a big out-of-tree fork of the code and then
started yelling at people who were checking code into the main tree and
making more work for him to keep his fork in sync, and managed to
actually chase away developers like Peter Mazinger who were doing such.
 (Meanwhile Erik Andersen, the maintainer at the time, was off
distracted by buildroot and by his day job...)

For a while the consensus here was that doing development in a common
public repository you could actually cut releases from was a quaint
notion inhibiting the progress of uClibc.  (And you wonder why it's
taken five years to ship NPTL?)

Alas, internationalization is still half-finished due to it.  Manuel
hasn't posted on here in years, and nobody else has picked it back up.

Rob
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Ah, figured out the -mfdpic thing, [PATCH] included.

[Rob Landley]

On 02/12/2011 12:01 AM, Khem Raj wrote:
 On (10/02/11 13:42), Rob Landley wrote:
 I mentioned that my build was dying due to trying to use -mfdpic which
 is a target-specific option for the FRV processor:

   http://lists.uclibc.org/pipermail/uclibc/2011-January/044701.html
   https://bugs.busybox.net/show_bug.cgi?id=3193

 The problem is that uClibc has an utterly useless user-visible
 TARGET_HAS_MMU as well as TARGET_USE_MMU, and I took the first out
 of miniconfig because I'd complained about the redundant option during
 the dev cycle and thought it was gone.
 
 hmmm yeah seems notion of using mmu and having mmu could be combined. 
 The case where chip has mmu but one still would like to not use it 
 can be deemed as
 
 TARGET_HAS_MMU is not set

I don't see why the MMU choice and the floating point coprocessor choice
are significantly different at the design level.  We don't have separate
has floating point and would like to use floating point symbols.
From the C library's point of view, it's a binary decision.

The kernel may need to know an FPU is there just so it can quiesce the
thing even if it's not adding extra register saves to each process
context switch.  But from the C library's point of view either the
kernel's giving it access to a working MMU, or it isn't.

 I dont see any particular use of knowing that I have mmu when I dont
 want to use it

I could just about imagine the kernel needing to do something to get the
MMU out of the way, so it needs to know it's there even when it's not
going to set up page tables.

But the kernel is not the C library.  From libc's point of view you
either have one or you don't.  Having two different user visible config
options for the same choice is strange and confusing.

Rob
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Ah, figured out the -mfdpic thing, [PATCH] included.

[Rob Landley]

On 02/11/2011 12:55 PM, Bernhard Reutner-Fischer wrote:
 On Thu, Feb 10, 2011 at 01:42:01PM -0600, Rob Landley wrote:
 I mentioned that my build was dying due to trying to use -mfdpic which
 is a target-specific option for the FRV processor:
 
 It's not only for FRV, it's also used on bfin (should be fixed in the
 docs).

Right, so when mike changed that in gcc he didn't bother to update the
docs, when he changed it in uClibc he didn't bother to put any docs on
the config entry...

  http://lists.uclibc.org/pipermail/uclibc/2011-January/044701.html
  https://bugs.busybox.net/show_bug.cgi?id=3193

 The problem is that uClibc has an utterly useless user-visible
 TARGET_HAS_MMU as well as TARGET_USE_MMU, and I took the first out
 of miniconfig because I'd complained about the redundant option during
 the dev cycle and thought it was gone.

 Here's a patch to remove the redundant option.  The only decision the
 end user has to make is Do I want MMU or NOMMU?, and TARGET_USE_MMU is
 the thing that selects that.  (There's even code in the test suite
 making sure nothing in the actual build ever uses ARCH_HAS_MMU, it's
 JUST a dependency guard on the only symbol that actually matters.)

 Architectures that have no MMU still set ARCH_HAS_NO_MMU, and that's
 used directly as the visibility guard for TARGET_USE_MMU which is the
 only user visible setting, and which defaults to y just like it always
 did.  (The previous code that selected TARGET_HAS_MMU was selecting a
 symbol that defaulted to Y, for no apparent reason.  There was a whole
 lotta NOP going on, and I've removed it.)

 The fact that when you select a nommu system, it defaults to creating a
 binary format that's only available on the FRV architecture with no hint
 that it's a target-specific format, is a separate bug introduced without
 explanation in commit 14db067a8bdcdc7a25.  I'm leaving that for now, in
 hopes somebody either fixes it or writes a help option explaining what
 they were thinking.

 Rob
 
 NAK.

Why?

 I also think a
   prompt Target File Format
 + default UCLIBC_FORMAT_ELF if ARCH_USE_MMU
 + default UCLIBC_FORMAT_FDPIC if !ARCH_USE_MMU  TARGET_frv
 + default UCLIBC_FORMAT_SHARED_FLAT if !ARCH_USE_MMU
 
 is not ideal, please just configure your format properly according to
 your needs (throughout your setup).

Why do you want to have two user-visible symbols that mean exactly the
same thing?  (What part of my explanation was incorrect?)

Rob
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Ah, figured out the -mfdpic thing, [PATCH] included.

[Rob Landley]

I mentioned that my build was dying due to trying to use -mfdpic which
is a target-specific option for the FRV processor:

  http://lists.uclibc.org/pipermail/uclibc/2011-January/044701.html
  https://bugs.busybox.net/show_bug.cgi?id=3193

The problem is that uClibc has an utterly useless user-visible
TARGET_HAS_MMU as well as TARGET_USE_MMU, and I took the first out
of miniconfig because I'd complained about the redundant option during
the dev cycle and thought it was gone.

Here's a patch to remove the redundant option.  The only decision the
end user has to make is Do I want MMU or NOMMU?, and TARGET_USE_MMU is
the thing that selects that.  (There's even code in the test suite
making sure nothing in the actual build ever uses ARCH_HAS_MMU, it's
JUST a dependency guard on the only symbol that actually matters.)

Architectures that have no MMU still set ARCH_HAS_NO_MMU, and that's
used directly as the visibility guard for TARGET_USE_MMU which is the
only user visible setting, and which defaults to y just like it always
did.  (The previous code that selected TARGET_HAS_MMU was selecting a
symbol that defaulted to Y, for no apparent reason.  There was a whole
lotta NOP going on, and I've removed it.)

The fact that when you select a nommu system, it defaults to creating a
binary format that's only available on the FRV architecture with no hint
that it's a target-specific format, is a separate bug introduced without
explanation in commit 14db067a8bdcdc7a25.  I'm leaving that for now, in
hopes somebody either fixes it or writes a help option explaining what
they were thinking.

Rob
diff --git a/extra/Configs/Config.alpha b/extra/Configs/Config.alpha
index 144924a..9aab976 100644
--- a/extra/Configs/Config.alpha
+++ b/extra/Configs/Config.alpha
@@ -11,6 +11,5 @@ config FORCE_OPTIONS_FOR_ARCH
 	bool
 	default y
 	select ARCH_LITTLE_ENDIAN
-	select ARCH_HAS_MMU
 	select ARCH_HAS_NO_LDSO
 	select UCLIBC_HAS_LFS
diff --git a/extra/Configs/Config.arm b/extra/Configs/Config.arm
index b060ace..5c919b4 100644
--- a/extra/Configs/Config.arm
+++ b/extra/Configs/Config.arm
@@ -62,11 +62,9 @@ config CONFIG_GENERIC_ARM
 
 config CONFIG_ARM610
 	bool Arm 610
-	select ARCH_HAS_MMU
 
 config CONFIG_ARM710
 	bool Arm 710
-	select ARCH_HAS_MMU
 
 config CONFIG_ARM7TDMI
 	bool Arm 7TDMI
@@ -74,35 +72,27 @@ config CONFIG_ARM7TDMI
 
 config CONFIG_ARM720T
 	bool Arm 720T
-	select ARCH_HAS_MMU
 
 config CONFIG_ARM920T
 	bool Arm 920T
-	select ARCH_HAS_MMU
 
 config CONFIG_ARM922T
 	bool Arm 922T
-	select ARCH_HAS_MMU
 
 config CONFIG_ARM926T
 	bool Arm 926T
-	select ARCH_HAS_MMU
 
 config CONFIG_ARM10T
 	bool Arm 10T
-	select ARCH_HAS_MMU
 
 config CONFIG_ARM1136JF_S
 	bool Arm 1136JF-S
-	select ARCH_HAS_MMU
 
 config CONFIG_ARM1176JZ_S
 	bool Arm 1176JZ-S
-	select ARCH_HAS_MMU
 
 config CONFIG_ARM1176JZF_S
 	bool Arm 1176JZF-S
-	select ARCH_HAS_MMU
 
 config CONFIG_ARM_CORTEX_M3
 	bool Arm Cortex-M3
@@ -116,18 +106,14 @@ config CONFIG_ARM_CORTEX_M1
 
 config CONFIG_ARM_SA110
 	bool Intel StrongArm SA-110
-	select ARCH_HAS_MMU
 
 config CONFIG_ARM_SA1100
 	bool Intel StrongArm SA-1100
-	select ARCH_HAS_MMU
 
 config CONFIG_ARM_XSCALE
 	bool Intel Xscale
-	select ARCH_HAS_MMU
 
 config CONFIG_ARM_IWMMXT
 	bool Intel Xscale With WMMX PXA27x
-	select ARCH_HAS_MMU
 
 endchoice
diff --git a/extra/Configs/Config.avr32 b/extra/Configs/Config.avr32
index cbadb4c..a5eb157 100644
--- a/extra/Configs/Config.avr32
+++ b/extra/Configs/Config.avr32
@@ -19,7 +19,6 @@ choice
 
 config CONFIG_AVR32_AP7
 	bool AVR32 AP7
-	select ARCH_HAS_MMU
 
 endchoice
 
diff --git a/extra/Configs/Config.cris b/extra/Configs/Config.cris
index 52ca0c3..db9293c 100644
--- a/extra/Configs/Config.cris
+++ b/extra/Configs/Config.cris
@@ -24,11 +24,9 @@ choice
 		- CRISv32  Support for Axis' CRISv32 architecture.
 
 config CONFIG_CRIS
-	select ARCH_HAS_MMU
 	bool CRIS
 
 config CONFIG_CRISV32
-	select ARCH_HAS_MMU
 	bool CRISv32
 
 endchoice
diff --git a/extra/Configs/Config.hppa b/extra/Configs/Config.hppa
index 1323de2..b8699bf 100644
--- a/extra/Configs/Config.hppa
+++ b/extra/Configs/Config.hppa
@@ -11,7 +11,6 @@ config FORCE_OPTIONS_FOR_ARCH
 	bool
 	default y
 	select ARCH_BIG_ENDIAN
-	select ARCH_HAS_MMU
 	select HAS_NO_THREADS
 	select ARCH_HAS_NO_LDSO
 	select HAVE_NO_SSP
diff --git a/extra/Configs/Config.i386 b/extra/Configs/Config.i386
index 288aa5e..f23646c 100644
--- a/extra/Configs/Config.i386
+++ b/extra/Configs/Config.i386
@@ -11,7 +11,6 @@ config FORCE_OPTIONS_FOR_ARCH
 	bool
 	default y
 	select ARCH_LITTLE_ENDIAN
-	select ARCH_HAS_MMU
 
 choice
 	prompt Target x86 Processor Family
diff --git a/extra/Configs/Config.ia64 b/extra/Configs/Config.ia64
index ae88be7..c7a1f63 100644
--- a/extra/Configs/Config.ia64
+++ b/extra/Configs/Config.ia64
@@ -11,5 +11,4 @@ config FORCE_OPTIONS_FOR_ARCH
 	bool
 	default y
 	select ARCH_LITTLE_ENDIAN
-	select ARCH_HAS_MMU
 	select ARCH_HAS_NO_LDSO
diff --git a/extra/Configs/Config.in.arch b/extra/Configs/Config.in.arch

The crtreloc dependencies are wrong for SMP builds in -rc2.

[Rob Landley]

It builds fine for make -j 1, but with make -j 4 I get:

  MKDIR include/bits
make: *** No rule to make target `libc/sysdeps/linux/mips/crtreloc.c',
needed by `lib/crtreloc.o'.  Stop.
make: *** Waiting for unfinished jobs
  MKDIR lib

(Not just mips, arm did it too.)

Rob
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: A modest proposal: call it 1.0

[Rob Landley]

On 02/09/2011 01:48 PM, Bernhard Reutner-Fischer wrote:
 On Wed, Feb 09, 2011 at 01:38:00PM -0600, ANDY KENNEDY wrote:
 -Original Message-
 From: uclibc-boun...@uclibc.org [mailto:uclibc-boun...@uclibc.org] On
 Behalf Of Bernhard Reutner-
 Fischer
 Sent: Wednesday, February 09, 2011 1:33 PM
 To: ander...@codepoet.org; Rob Landley; uclibc@uclibc.org
 Subject: Re: A modest proposal: call it 1.0
   Where '+' means ported, 'o' means TODO/needs verification
   o mips

 I'm using NPTL on Mips, if you consider this verification, then you have
 it.
 
 i've updated the TODO file accordingly.

 I too support the bump to 1.0 -- why wait?
 
 why not wait. Remember that it's a version number, nothing more. See
 TODO
 

Do you mean We've had meaningless release numbers for so long, why stop
now?

The reason not to wait is that if we don't call the NPTL release be 1.0,
after 5 years of development, we will never have a 1.0 release.  If
you're waiting for the todo list to run out, it's not going to happen.
There will always be SOMETHING left to do.

As for the nothing more, it signals that it's ready for significant
use and that people should give the thing a try.  Linux Weekly News or
H-online could probably be convinced to cover a 1.0 release of uClibc
and do a comparison between eglibc and uClibc.  They're much less likely
to do so (and people are less likely to read it) for a 0.9.32 release.
Remember that the project is still recovering from a multi-year
development drought, and that the eglibc and klibc projects were
launched because uClibc was not seen as a reasonable alternative to
glibc so people created their own.  (Yes, I asked.)

The majority of your needs verification list boils down to we can't
have bugs in our 1.0 release.  Um... that means we can't have a 1.0
release.  A more charitable reading is We have to do everything we can
to make sure there are no bugs in our 1.0 release, if there are things
left that we could do then it's not time for 1.0 yet, see always going
to be something left to do above...

When the Linux kernel had its 1.0 release in 1994, the project was a
little over 3 years old.  BusyBox (which is about as old as uClibc,
maintained by the same set of people for the start of that, and hit its
you can build a usable system out of this stage at about the same
time) had its 1.0 release six years ago, and that was after more than a
year of 1.0-pre and 1.0-rc releases.

I believe getting our development process unblocked to the point where
we could conceivably switch to time based releases (as the linux kernel,
busybox, most distributions... pretty much everything interesting) has
already done, is a milestone.  The previous milestone (0.9.26, stuff now
just works by default so we stop tracking a known-working application
list) went by unremarked.  No upcoming milestone is more significant
than either of those, and if we _aren't_ already planning what to do
next by the time we reach them something is wrong.


Rob
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: How to port uclibc to Windows CE

[Rob Landley]

On 02/08/2011 01:43 AM, taowei wrote:
 Hello, everyone:
 I'm a newer for uclibc. I have two questions about uclibc and I look forward 
 to your reply. Thank you very much.
 Question1: Is uclibccompatible with POSIX?

Reasonably, yes.  Still catching up with Posix 2008 in places.

 Question2: uclibc supports embedded linux. I want to port it to Windows CE,

Why?

 but I don't know how to do it. Can you give me some advices on it?

Not really.  It makes about as much sense to me as rewriting it in
cobol, but it's your life.

 Or Is there an existing library that is compatible with POSIX on
Windows CE?

Posix is the portable unix standard.  That's where the name comes from.
 Portable Operating System with the -ix extension of a unix clone.

WinCE is Windows, which is almost the only remaining general purpose OS
that isn't Unix based (outside of the surviving cobol-centric mainframes
or some of the really tiny embedded systems, anyway, and things like
Cisco IOS and game consoles that are only an OS if you squint and don't
even provide virtual memory).  Unix clones took over the operating
system world the way the microchip took over the hardware world.  MacOS
X is a unix variant, Linux is a unix variant, supercomputers run unix
variants, both android and iphone run unix variants...

Windows isn't.  Paul Allen retrofitted a lot of Unix stuff onto it, but
the base system is an extension of a clone of CP/M which Dave Cutler
then slathered bits of OS/2, the Vax VMS, and some microkernel ideas on
top of, and then Windows CE happened when microsoft entered the embedded
world with a hilariously unsuccessful attempt to clone the Apple Newton:

  http://www.hpcfactor.com/support/windowsce/

And it sort of hairballed from there.

I have no idea why you'd want to get any of that on you, but as I said:
it's your life.  But asking about posix support for windows is like
asking about the nutritional value of a twinkie.  There's just no point
going there, that's not what it's _for_.

Rob
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: How to port uclibc to Windows CE

[Rob Landley]

On 02/08/2011 01:33 PM, David Lynch Jr. wrote:
 
 
 On Tue, 2011-02-08 at 14:18 -0500, Rich Felker wrote:
 On Tue, Feb 08, 2011 at 09:56:24AM -0500, David Lynch Jr. wrote:
 I am not specifically familiar with Windows CE. But I have done lots of
 cross platform work with windows.  Ignoring tangents like the Windows
 Posix subsystem and Cygwin, normal windows - microsoft's C libraries
 provides a significant portion of POSIX support.  The critical problem
 is that windows developers almost univerally use the Windows specific
 API's over the more portable POSIX API's. 

 This is not true. The Microsoft libc (MSVCRT) does not even conform to
 ancient versions of the C standard, much less C99, and the degree to
 which the functions with names that mirror POSIX functions differ from
 the POSIX-specified behavior is laughable. (For instance, sockets and
 file descriptors are not the same and cannot be used interchangibly,
 and they're not allocated in lowest-available order.)

 
   I did not claim that Microsoft conformed to the POSIX spec, just that
 with a small amount of care on the part of the developers, it was
 possible to write portable code.

With a small amount of care, goldfish are drinkable.  Many things are
possible if you only care a small amount about the end result.

Code can be ported back and forth between windows and sane operating
systems, yes.  From that perspective all code is portable, in the same
way that Howard Tayler remarked Everything is air-droppable at least once.

   I am not particularly enamored of the POSIX standards. Not that there
 is something wrong with them, but I know very very few developers that
 use more than a small fraction of the API.

More than a small fraction of the posix API?  I've used most of it at
one point or another.  I've even occasionally sent in bug reports and
fixes on some weird corner case behavior to improve our compatability
with it.  (Both in busybox and in uClibc.)

If you mean Use more than a small fraction of the Windows API?

A personal point of pride is that I've never written a program for the
Windows API.  Programs that ran on windows because they were java or
javascript or built under cygwin, sure.  Programs for OS/2 API including
the workplace shell that windows copied heavily from (although they did
things like reverse the order of arguments in functions with the same
name, to make sure the two were intentionally incompatible), sure.
Kept track of Win32s vs Win32c to figure out what would run on WinOS2
and what wouldn't, including reading some programming books Charles
Petzold wrote on the subject, sure.

Posix isn't the only standard Windows doesn't conform to.  In addition
to C99, there's LP64, the standard specifying type sizes which Linux,
MacOS X, BSD, and pretty much everything except Windows all conform to:

  Standard: http://www.unix.org/whitepapers/64bit.html
  Rationale: http://www.unix.org/version2/whatsnew/lp64_wp.html

But Windows intentionally chose _not_ to do so, and instead did LLP64
because their developers used long and int interchangeably for years
and rather than clean up their headers they bent their 64 bit API into a
pretzel:

  http://blogs.msdn.com/oldnewthing/archive/2005/01/31/363790.aspx

Which really has to do with Microsoft internal politics explained by an
ex-microsoft employee here:

  http://www.joelonsoftware.com/articles/APIWar.html

Did you know that Windows was written off as a loss by Microsoft until
one guy (David Weiss) single-handedly resurrected it by inventing
Thunking and turning their 16 bit toy into something that could access
4 gigs of ram without recompiling the applications?  (Still
segment/offset addressing, but the segments no longer had to overlap.)

  http://blogs.msdn.com/b/larryosterman/archive/2005/02/02/365635.aspx

Did you know that the reason Windows XP was a technical regression from
Windows 2000 (with regards to stability and the device model and such)
had to do with Microsoft losing a class action lawsuit against its own
employees and accidentally firing the build team responsible for
COMPILING windows?  Meaning they stopped being able to build Windows
2000, had to back up to the last thing they _could_ build (NT 4),
retasked the dev team coming off of Windows Millenium to backport as
much of Windows 2000 to the older codebase as they could and then Make
it pretty enough to sell as an upgrade.

I collected links at the time, but they tend to go stale after a while
if you don't mirror 'em:


http://blog.valerieaurora.org/2009/03/12/parallel-file-system-worlds/#comment-802

I am fairly familiar with Windows.  It is crap.  When I say it's a point
of pride that I've never written a windows program, I'm not speaking out
of ignorance of the technology.

Yes, it can be made to work, with the aid of billions of dollars of
corporate funding and a complete disregard for technological
advisability.  So can cobol.  Both survive for similar reasons, and
experts in both command 

Re: How to port uclibc to Windows CE

[Rob Landley]

On 02/08/2011 06:45 PM, Rich Felker wrote:
But if you are trying to develop applications that you expect to build
  and work on many platforms, and you have control over the coding
  standards, portability is not that hard to achieve. 
  
  I still think it's a lot of work. If nothing else, you'll end up
  re-inventing half of POSIX, and doing things in suboptimal ways
  because you're working with a crippled subset of the usual system
  facilities.

It's called Cygwin.

The Cygwin developers deserve credit for an enormous amount of hard
  work, but their solution has sufficient complexity that you might as
  well switch to Linux. 
  
  I would really like to see a stripped-down cygwin (or
  massively-improved mingw) with no global configuration that can break
  your apps, and no attempt to make Windows look/work like Linux, just
  fixing the important library functions to conform to C99 and
  halfway-conform to POSIX, and providing a UTF-8 view of the filesystem
  and command line so that programs can use fopen or open without
  resorting to Windows-specific alternatives.

Cygwin provides something vaguely like posix semantics for Windows, by
essentially sticking an ENTIRE NEW OPERATING SYSTEM in between your
application and Windows.  The result isn't actually very good, but to
even approach Posix on windows, your transaltion layer really does need
to be that thick.

Mingw provides no translation layer, it just rehosts the tools and lets
you program to the Win32 API with them.  Minimal Gnu for Windows.  If
you program for Posix and build with Mingw, it won't work.

People keep wanting something between the two, because they don't
understand the problem.  They don't really _believe_ that providing
Posix semantics for Windows is a horrible crawling nightmare from the
depths of R'yleh come to devour the innocent, and they want somebody to
magically make Windows work like Unix by waving a wand without actually
adding any code or complexity ot the result.

If this was easy to do, somebody would have done it by now.  If it was
HARD to do, the result would look a lot like Cygwin.

Suggesting that you can just tweak a couple of lines and make uClibc run
on Windows when it hasn't even been ported to MacOS X or FreeBSD...
Laugh.  It's funny.

Suggesting Porting uClibc to work within the context of Cygwin might be
technically possible, but would be a horribly bad idea utterly at odds
with the micro part of uClibc.  (The cygwin developers had to hack up
glibc until it was unrecognizable.)  Doing so would defeat the purpose
of using (or developing) uClibc, and by complicating the uClibc code and
making it harder for the Linux developers to understand and maintain the
Linux version would make it a worse thing to use on Linux.

Executive summary: bad idea, killit with fire.

Rob
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

A modest proposal: call it 1.0

[Rob Landley]

On 02/02/2011 11:35 AM, Bernhard Reutner-Fischer wrote:
  I know have an ARM target to use, I'll try to test the sh
  implementation (simply based on dwarf2) to see if it can be
  exported to all archs
 
  It would be great if we could have a DWARF4 (or DWARF2 for that
  matter) impl, yes!
  What is your delta on this? Could we get it into an eventual -rc3?

If you're going to add NPTL support after five years of development, and
you're going to have at least 3 release candidates, and we're going to
test everything to the hilt...

Call the release 1.0.0 please.  Just do it.  Don't worry about binary
ABI stability because that ain't happening ever, since there's a number
of different ways to break the ABI by changing the .config and the
various discussions about annotating the thing over the years always
wandered off into INSANE complexity.

Say that bugfix only dot releases (1.0.1 and friends), built with the
same config, won't break the ABI.  But development stabiliziation
releases (1.1.x and so on) may do so, but you can always stick with the
old version and there's this thing called static linking which uClibc
not only supports but is actually _good_ at, which is always an option...

After five years of developmental constipation, it's time for a 1.0
release, like busybox had six years ago.  Because if we don't do it now,
we never will and it's officially an unattainable platonic ideal.

1.0 just means feature complete, not bug free.  (No software is
perfect.)  And with NPTL and the ability to build just about any
arbitrary userspace package against uClibc, we're there.

Rob
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: uClibc-0.9.31 for ARM, linker problem

[Rob Landley]

On 01/30/2011 03:35 PM, Torsten Mohr wrote:
 Hello,
 
 i try to compile uClibc-0.9.31 for target ARM, which fails.  There are the 
 same problems for uClibc-0.9.32-rc2:

Worked fine for me.

  http://landley.net/aboriginal/downloads/binaries

The build scripts are a directory up from there.

I'm applying a bunch of patches to 0.9.31, several of them for arm, but
I don't remember one for this specific issue, and I think the
interesting ones went upstream by 32-rc2...

 I configured and installed binutils-2.21 and gcc-4.5.2 for arm-linux-elf.
 I compile with:
 
 make CROSS=arm-linux-elf- 
 KERNEL_HEADERS=/local/armbuild/sysroot/usr/include/include
 
 At linking i get:
 
 libc/libc_so.a(dl-iterate-phdr.oS): In function `dl_iterate_phdr':
 dl-iterate-phdr.c:(.text+0x80): undefined reference to `_dl_loaded_modules'

It's in ldso/ldso/dl-symbols.c

 libc/libc_so.a(__uClibc_main.oS): In function `__uClibc_fini':
 __uClibc_main.c:(.text+0xb0): undefined reference to `_dl_app_fini_array'
 libc/libc_so.a(__uClibc_main.oS): In function `__uClibc_main':
 __uClibc_main.c:(.text+0x25c): undefined reference to `_dl_app_init_array'
 collect2: ld returned 1 exit status
 make: *** [lib/libc.so] Fehler 1

 
 After changing in libc/misc/internals/__uClibc_main.c (found in the archives):
 
 From:
 extern void _dl_app_init_array(void);
 extern void _dl_app_fini_array(void);
 
 To:
 extern void weak_function _dl_app_init_array(void) attribute_hidden;
 extern void weak_function _dl_app_fini_array(void) attribute_hidden;

Huh, I'm not doing that and it works for me.  I've built most of Linux
From Scratch against the result.

 My .config, for reference:

I attached mine.  (Note that the pthreads build works for me and the
nptl build doesn't, I don't remember which config that is but all the
other symbols should be the same.)

Rob
#
# Automatically generated make config: don't edit
# Version: 0.9.32-rc2
# Sun Jan 23 14:59:35 2011
#
# TARGET_alpha is not set
TARGET_arm=y
# TARGET_avr32 is not set
# TARGET_bfin is not set
# TARGET_cris is not set
# TARGET_e1 is not set
# TARGET_frv is not set
# TARGET_h8300 is not set
# TARGET_hppa is not set
# TARGET_i386 is not set
# TARGET_i960 is not set
# TARGET_ia64 is not set
# TARGET_m68k is not set
# TARGET_microblaze is not set
# TARGET_mips is not set
# TARGET_nios is not set
# TARGET_nios2 is not set
# TARGET_powerpc is not set
# TARGET_sh is not set
# TARGET_sh64 is not set
# TARGET_sparc is not set
# TARGET_v850 is not set
# TARGET_vax is not set
# TARGET_x86_64 is not set
# TARGET_xtensa is not set

#
# Target Architecture Features and Options
#
TARGET_ARCH=arm
FORCE_OPTIONS_FOR_ARCH=y
# CONFIG_ARM_OABI is not set
CONFIG_ARM_EABI=y
CONFIG_GENERIC_ARM=y
# CONFIG_ARM610 is not set
# CONFIG_ARM710 is not set
# CONFIG_ARM7TDMI is not set
# CONFIG_ARM720T is not set
# CONFIG_ARM920T is not set
# CONFIG_ARM922T is not set
# CONFIG_ARM926T is not set
# CONFIG_ARM10T is not set
# CONFIG_ARM1136JF_S is not set
# CONFIG_ARM1176JZ_S is not set
# CONFIG_ARM1176JZF_S is not set
# CONFIG_ARM_CORTEX_M3 is not set
# CONFIG_ARM_CORTEX_M1 is not set
# CONFIG_ARM_SA110 is not set
# CONFIG_ARM_SA1100 is not set
# CONFIG_ARM_XSCALE is not set
# CONFIG_ARM_IWMMXT is not set
TARGET_SUBARCH=

#
# Using ELF file format
#
ARCH_ANY_ENDIAN=y
ARCH_LITTLE_ENDIAN=y
# ARCH_WANTS_BIG_ENDIAN is not set
ARCH_WANTS_LITTLE_ENDIAN=y
ARCH_HAS_MMU=y
ARCH_USE_MMU=y
UCLIBC_HAS_FLOATS=y
# UCLIBC_HAS_FPU is not set
UCLIBC_HAS_SOFT_FLOAT=y
DO_C99_MATH=y
# DO_XSI_MATH is not set
UCLIBC_HAS_FENV=y
KERNEL_HEADERS=/usr/include
HAVE_DOT_CONFIG=y

#
# General Library Settings
#
# HAVE_NO_PIC is not set
DOPIC=y
# ARCH_HAS_NO_SHARED is not set
# ARCH_HAS_NO_LDSO is not set
HAVE_SHARED=y
# FORCE_SHAREABLE_TEXT_SEGMENTS is not set
# LDSO_LDD_SUPPORT is not set
LDSO_CACHE_SUPPORT=y
# LDSO_PRELOAD_ENV_SUPPORT is not set
# LDSO_PRELOAD_FILE_SUPPORT is not set
LDSO_BASE_FILENAME=ld-uClibc.so
UCLIBC_STATIC_LDCONFIG=y
LDSO_RUNPATH=y
LDSO_SEARCH_INTERP_PATH=y
UCLIBC_CTOR_DTOR=y
# LDSO_GNU_HASH_SUPPORT is not set
# HAS_NO_THREADS is not set
LINUXTHREADS_OLD=y
# LINUXTHREADS_NEW is not set
# UCLIBC_HAS_THREADS_NATIVE is not set
UCLIBC_HAS_THREADS=y
PTHREADS_DEBUG_SUPPORT=y
UCLIBC_HAS_SYSLOG=y
UCLIBC_HAS_LFS=y
# MALLOC is not set
# MALLOC_SIMPLE is not set
MALLOC_STANDARD=y
MALLOC_GLIBC_COMPAT=y
UCLIBC_DYNAMIC_ATEXIT=y
# COMPAT_ATEXIT is not set
UCLIBC_SUSV3_LEGACY=y
UCLIBC_SUSV3_LEGACY_MACROS=y
UCLIBC_SUSV4_LEGACY=y
# UCLIBC_HAS_STUBS is not set
UCLIBC_HAS_SHADOW=y
UCLIBC_HAS_PROGRAM_INVOCATION_NAME=y
UCLIBC_HAS___PROGNAME=y
UCLIBC_HAS_PTY=y
ASSUME_DEVPTS=y
UNIX98PTY_ONLY=y
# UCLIBC_HAS_GETPT is not set
UCLIBC_HAS_LIBUTIL=y
UCLIBC_HAS_TM_EXTENSIONS=y
UCLIBC_HAS_TZ_CACHING=y
UCLIBC_HAS_TZ_FILE=y
UCLIBC_HAS_TZ_FILE_READ_MANY=y
UCLIBC_TZ_FILE_PATH=/etc/TZ
# UCLIBC_FALLBACK_TO_ETC_LOCALTIME is not set

#
# Advanced Library Settings
#
UCLIBC_PWD_BUFFER_SIZE=256
UCLIBC_GRP_BUFFER_SIZE=256

#
# Support various families of functions
#
# 

Re: NPTL not building?

[Rob Landley]

On 01/29/2011 11:42 AM, Carmelo Amoroso wrote:
 That's a show-stopper bug for me.

 Rob
 
 In understand.
 An option could be to transform all .cfi_xxx pseudo ops in a corresponding 
 macro cfi_xxx
 that expands to nothing if the binutils or arch does not support (or the user 
 does not want) CFI.
 
 A lot of CFI ops are already managed in this way. There is a define under 
 uClibc_arch_feature that could be used for this
 
  /* define if target supports CFI pseudo ops */
  #undef __UCLIBC_HAVE_ASM_CFI_DIRECTIVES__
 
 Does it sound reasonable ?

Ooh, yes please!

Sparc, i386, x86_64, and sh.  This implies that if I build the simple
armv5l target (without building a second stage cross compiler), it
should work...

My buildall.sh script builds an x86 cross compiler first, and then
builds the other target cross compiler twice doing the gcc stage1/stage2
thing except taking manual control and supplying a uClibc-based host
compiler so it can statically link the compiler binaries against uClibc
on the host.  This is part of letting you grab the tarball and run it
out of your home directory on an arbitrary Linux system.

(Alas, this involves building an i686 compiler, which is where I hit
this.  Because statically linked 32 bit code runs on just about all
x86-64 systems, and due to exerting less L1 cache pressure it isn't
actually noticeably slower than a native 64 bit version, although I
haven't benched them recently...)

And the uClibc build broke for armv5l target:

#
# configuration written to ./.config
#
  MKDIR include/bits
make: *** No rule to make target `libc/sysdeps/linux/arm/crtreloc.c',
needed by `lib/crtreloc.o'.  Stop.
make: *** Waiting for unfinished jobs

Ok, that didn't work.  Is it due to the make -j 6?  Try with CPUS=1...

  AS lib/crt1.o
  AS lib/Scrt1.o
  AS lib/crti.o
cc1: error: unrecognized command line option -mfdpic
make: *** [lib/crti.o] Error 1

Well, at least it died in a different place...

Let's see how a mips build does:

  AS lib/crt1.o
libc/sysdeps/linux/mips/crt1.S: Assembler messages:
libc/sysdeps/linux/mips/crt1.S:117: Warning: No .cprestore pseudo-op
used in PIC code
  AS lib/Scrt1.o
libc/sysdeps/linux/mips/crt1.S: Assembler messages:
libc/sysdeps/linux/mips/crt1.S:117: Warning: No .cprestore pseudo-op
used in PIC code
  AS lib/crti.o
cc1: error: unrecognized command line option -mfdpic
make: *** [lib/crti.o] Error 1

Exiting due to errors (mips simple-cross-compiler uClibc)

Died in the same place, but emitted more warnings first.

 We should review all the code and transform the missing one.

Um, dunno what that means?

 I had a similar problem with ARM/NPTL where my binutils 2.10 does not support 
 .cfi_sections that is used
 in some the unwdiner asm code. I have a my own patch for this, not yet fully 
 complete.
 
 I'll see to find some time to come with a proposal patch.

Cool.  I'm eager to test this as soon as you've got something for me,
although I don't see why a config option or build-time compiler probe to
switch off the #define wouldn't work too...

By the way, what do cfi_sections _do_?  Google found this:

http://us.generation-nt.com/patch-x86-use-cfi-sections-help-198180281.html

http://stackoverflow.com/questions/3564752/what-is-cfi-and-lfe-in-assembly-code-produced-by-gcc-from-c-program

Both of which imply it's to do with stack unwinding, either for debug
purposes or for c++.  Isn't half the code lin libgcc_eh.a already to do
with stack unwinding?  This is at least fourth stack unwinding mechanism
they've introduced (frame pointers, sjlj, dwarf2).  Not to mention the
original setjmp not needing this at all before c++ crapped all over the
C spec...

Oh well, I'm sure they'll have rewritten it all over again in five
years.  A bit like the C++ String class...

(I've still got my compiler configured for sjlj exceptions because it
worked, I've never had cause to revisit it, and it doesn't really come
up much with pure C code which includes the runtimes for higher level
languages like Perl and Python.  I'm just now getting around to swithing
from pthreads to NPTL in part because glibc's code to build under a
non-NTPL Linux system bit-rotted about 3 years ago and no longer works,
so I can't bootstrap current glibc on a uClibc-0.9.31 system.  My
aboriginal project is designed to make cross compiling go away, I.E. all
about getting a native development environment on the target which you
can then completely replace via native building if you want to, either
on appropriate native hardware or under QEMU.  I even provide a few
example bootstrap scripts to show you how to do it.  Bit of a hole in
the design if you can't build glibc.)

Rob
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: NPTL not building?

[Rob Landley]

On 01/27/2011 08:37 AM, Carmelo AMOROSO wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 On 1/27/2011 3:34 PM, Rob Landley wrote:
 AS
 libpthread/nptl/sysdeps/unix/sysv/linux/i386/i686/pthread_cond_timedwait.oS
 libpthread/nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/pthread_cond_timedwait.S:
 Assembler messages:
 libpthread/nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/pthread_cond_timedwait.S:40:
 Error: unknown pseudo-op: `.cfi_personality'
 libpthread/nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/pthread_cond_timedwait.S:42:
 Error: unknown pseudo-op: `.cfi_lsda'
 make: ***
 [libpthread/nptl/sysdeps/unix/sysv/linux/i386/i686/pthread_cond_timedwait.oS]
 Error 1

 Did I hork something in my .config? I replaced:

 LINUXTHREADS_OLD=y

 With

 UCLIBC_HAS_THREADS_NATIVE=y

 And it stopped building. Switched it back and it built fine.

 Rob
 
 Rob,
 it seems that your binutils is too old and does not support CFI pseudo
 ops (or part of them).

It's the last GPLv2 release, binutils 2.17.  So you're saying that NPTL
support won't build under non-GPLv3 toolchain.

That's a show-stopper bug for me.

Rob
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Quick test of -rc2.

[Rob Landley]

So I pulled -rc2 and built the Aboriginal targets with it.  Using pretty
much the same .configs as my 0.9.31 build (specifically still
pthreads.old, not NPTL), and a 2.6.37 kernel, most of the targets worked.

Testing armv4eb:FAIL
Testing armv4l:PASS
Testing armv4tl:PASS
Testing armv5l:PASS
Testing armv6l:FAIL
Testing i486:PASS
Testing i586:PASS
Testing i686:PASS
Testing m68k:NONE
Testing mips:PASS
Testing mips64:FAIL
Testing mipsel:PASS
Testing powerpc:PASS
Testing sh4:NONE
Testing sparc:NONE
Testing x86_64:PASS

The armv4eb target is expected to fail because qemu doesn't emulate it
properly, and armv6l also fails for QEMU board emulation reaons.

The mips64 smoketest fails because the native compiler segfaults trying
to build hello world, but that's not a new problem.

The sparc build failed due to:

libpthread/linuxthreads.old/libpthread_so.a(manager.os): In function
`__pthread_manager':
manager.c:(.text+0xb30): undefined reference to `clone'

The sh4 build failed due to:

libc/libc_so.a(longjmp.os): In function `__libc_longjmp':
longjmp.c:(.text+0x48): undefined reference to `_longjmp_unwind'
libc/libc_so.a(popen.os): In function `popen':
popen.c:(.text+0x2d8): undefined reference to `__GI_vfork'
collect2: ld returned 1 exit status

m68k dies with an internal compiler error, I was patching .31 to take
out the optimization but haven't done that to this one.  Couldn't test
it anyway.  Not a big deal:

libc/inet/addr.c: In function 'inet_ntoa_r':
libc/inet/addr.c:135: internal compiler error: in output_move_qimode, at
config/m68k/m68k.c:1900

Rob
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Trying out -git, sparc sh4 and powerpc didn't build.

[Rob Landley]

On Tuesday 14 December 2010 07:11:35 Konrad Eisele wrote:
 Rob Landley wrote:
  On Monday 13 December 2010 10:58:06 Konrad Eisele wrote:
  Rob Landley wrote:
  All three of these worked with the previous stable release, but not
  with current -git.  Building against 2.6.36:

 Appended is a patch that fixes the build error.
 The problem occures when  __LONG_DOUBLE_128__ and hence long double support
 is not defined. For a gcc that doesnt support long double I revert to the
 old qp_ops.c that includes the quad foat _Q* stubs.

 Does this resolve the build error on your machine ?
 Can you apply that patch then? ...

It now makes it to:

  LD libthread_db-0.9.32-git.so
libpthread/linuxthreads.old/libpthread_so.a(manager.os): In function 
`__pthread_manager':
manager.c:(.text+0xb30): undefined reference to `clone'
collect2: ld returned 1 exit status
make: *** [lib/libpthread.so] Error 1
make: *** Waiting for unfinished jobs

Thanks,

Rob
-- 
GPLv3: as worthy a successor as The Phantom Menace, as timely as Duke Nukem 
Forever, and as welcome as New Coke.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Trying out -git, sparc sh4 and powerpc didn't build.

[Rob Landley]

All three of these worked with the previous stable release, but not with 
current -git.  Building against 2.6.36:

sparc died with:

In file included from libc/sysdeps/linux/sparc/soft-fp/q_div.c:24:
libc/sysdeps/linux/sparc/soft-fp/quad.h:63: error: unable to emulate 'TF'
In file included from libc/sysdeps/linux/sparc/soft-fp/q_fle.c:24:
libc/sysdeps/linux/sparc/soft-fp/quad.h:63: error: unable to emulate 'TF'
libc/sysdeps/linux/sparc/soft-fp/q_fle.c: In function '_Q_fle':
libc/sysdeps/linux/sparc/soft-fp/q_fle.c:28: warning: unused variable '_fcw'
make: *** [libc/sysdeps/linux/sparc/soft-fp/q_fle.os] Error 1
make: *** Waiting for unfinished jobs
make: *** [libc/sysdeps/linux/sparc/soft-fp/q_div.os] Error 1

sh4 died with:

  LD libuClibc-0.9.32-git.so
libc/libc_so.a(longjmp.os): In function `__libc_longjmp':
longjmp.c:(.text+0x48): undefined reference to `_longjmp_unwind'
libc/libc_so.a(popen.os): In function `popen':
popen.c:(.text+0x2d8): undefined reference to `__GI_vfork'
collect2: ld returned 1 exit status
make: *** [lib/libc.so] Error 1

Oddly powerpc broke but powerpc-440 built.  (Go figure?)

In file included from libc/inet/if_index.c:37:
libc/inet/netlinkaccess.h:29: error: redefinition of typedef '__u8'
/home/landley/aboriginal/aboriginal/build/simple-cross-compiler-
powerpc/include/asm-generic/int-ll64.h:20: error: previous declaration of 
'__u8' was here
libc/inet/netlinkaccess.h:30: error: redefinition of typedef '__u16'
/home/landley/aboriginal/aboriginal/build/simple-cross-compiler-
powerpc/include/asm-generic/int-ll64.h:23: error: previous declaration of 
'__u16' was here
libc/inet/netlinkaccess.h:31: error: redefinition of typedef '__u32'
/home/landley/aboriginal/aboriginal/build/simple-cross-compiler-
powerpc/include/asm-generic/int-ll64.h:26: error: previous declaration of 
'__u32' was here
libc/inet/netlinkaccess.h:32: error: redefinition of typedef '__u64'
/home/landley/aboriginal/aboriginal/build/simple-cross-compiler-
powerpc/include/asm-generic/int-ll64.h:30: error: previous declaration of 
'__u64' was here
libc/inet/netlinkaccess.h:33: error: redefinition of typedef '__s32'
/home/landley/aboriginal/aboriginal/build/simple-cross-compiler-
powerpc/include/asm-generic/int-ll64.h:25: error: previous declaration of 
'__s32' was here
make: *** [libc/inet/if_index.os] Error 1
make: *** Waiting for unfinished jobs

I can provide more information on request, dunno what you need.

I'm building the old threading first (basically the same .config as 0.9.31).  
I'll worry about NPTL once I'm sure the base system didn't regress too badly.

Rob
-- 
GPLv3: as worthy a successor as The Phantom Menace, as timely as Duke Nukem 
Forever, and as welcome as New Coke.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Trying out -git, sparc sh4 and powerpc didn't build.

[Rob Landley]

On Monday 13 December 2010 10:58:06 Konrad Eisele wrote:
 Rob Landley wrote:
  All three of these worked with the previous stable release, but not with
  current -git.  Building against 2.6.36:
 
  sparc died with:
 
  In file included from libc/sysdeps/linux/sparc/soft-fp/q_div.c:24:
  libc/sysdeps/linux/sparc/soft-fp/quad.h:63: error: unable to emulate 'TF'
  In file included from libc/sysdeps/linux/sparc/soft-fp/q_fle.c:24:
  libc/sysdeps/linux/sparc/soft-fp/quad.h:63: error: unable to emulate 'TF'
  libc/sysdeps/linux/sparc/soft-fp/q_fle.c: In function '_Q_fle':
  libc/sysdeps/linux/sparc/soft-fp/q_fle.c:28: warning: unused variable
  '_fcw' make: *** [libc/sysdeps/linux/sparc/soft-fp/q_fle.os] Error 1
  make: *** Waiting for unfinished jobs
  make: *** [libc/sysdeps/linux/sparc/soft-fp/q_div.os] Error 1

 Can you send me gcc's configure line for the sparc toolchain that you use?

All targets build with:

  # Are we building C only, or C and C++?
  [ -z $NO_CPLUSPLUS ] 
STUFF=--enable-languages=c,c++ --disable-libstdcxx-pch ||
STUFF=--enable-languages=c

  # Configure gcc
  $CURSRC/configure --target=$CROSS_TARGET --prefix=$STAGE_DIR \
--disable-multilib --disable-nls --enable-c99 --enable-long-long \
--enable-__cxa_atexit $STUFF --program-prefix=$TOOLCHAIN_PREFIX \
$@ $GCC_FLAGS 

And in the case of the simple cross compiler (which is what's failing), the 
call to the configure function would be:

  AR_FOR_TARGET=${ARCH}-ar configure_gcc \
--disable-threads --disable-shared --host=$CROSS_HOST

In sources/targets/sparc/settings we have:

  GCC_FLAGS=--enable-sjlj-exceptions

And then in sources/functions.sh the generic setup gives us:

  CROSS_TARGET=${ARCH}-unknown-linux
  CROSS_HOST=$(uname -m)-walrus-linux

Which gives us:

AR_FOR_TARGET=sparc-ar ../gcc-core/configure --target=sparc-unknown-linux \
  --prefix=/big/long/irrelevant/path --disable-multilib --disable-nls \
  --enable-c99 --enable-long-long --enable-__cxa_atexit \
  --enable-languages=c,c++ --disable-libstdcxx-pch \
  --program=prefix=sparc- --disable-threads --disable-shared \
  --host=x86_64-walrus-linux --enable-sjlj-exceptions

(And yes, using the wrong ar breaks some target, I forget which.  Wasn't 
sparc.  I remember the target that broke when using the wrong strip was sh4.)

 Are you using a setup with a gcc/config/sparc/t-* snippet that has FPBIT
 and DPBIT not set?

Possibly?  I dunno what FPBIT and DPBIT are.

I'm building stock gcc 4.2.1 with binutils 2.17 (last GPLv2 release of each, I 
await either LLVM or PCC maturing to usability with bated breath).  I am 
applying a few patches but none of them are sparc stuff.  (Half of them fix 
various issues with arm, one makes libgcc_eh.a build during the --disable-
shared pass, and the rest fix OBVIOUS breakage with sh4, alpha, and mips64 of 
the how did they ever use those targets variety).

However, sparc previously built and booted to a shell prompt under qemu for 
me.  (Dynamic linking was broken but static worked just fine.)  Not saying it 
was correct, I'm just saying it worked for me.

 FPBIT =
 DPBIT =

 t-elf for instance defines:
 ...
 FPBIT = fp-bit.c
 DPBIT = dp-bit.c

gcc/config/sparc/t-linux contains no mention of those.

You're saying that to build for linux I need to specify sparc-elf instead of 
sparc-unknown-linux the way all the other targets work?  (I can patch gcc if 
it would help.  I'm more or less maintaining a feature-frozen GPLv2 fork of 
the thing until LLVM/PCC/tinycc/something matures, since I refuse to get any 
GPLv3 on me unless paid to do so.  However, the previous release didn't need 
this...)

 dp-bit.c: $(srcdir)/config/fp-bit.c
   cat $(srcdir)/config/fp-bit.c  dp-bit.c

 fp-bit.c: $(srcdir)/config/fp-bit.c
   echo '#define FLOAT'  fp-bit.c
   cat $(srcdir)/config/fp-bit.c  fp-bit.c
 ...

 if I can reproduce the error here (if you send the gcc configure line) I
 can try to post a patch that handles the error...
 -- Greetings Konrad

Cool.  Thanks.

(I can send you a binary version of a cross compiler that build 0.9.31 if 
you'd like.  I have tarballs up at 
http://landley.net/aboriginal/downloads/binaries for all the targets I've 
gotten to work so far.  It's 32 bit x86 host binaries statically linked 
against uClibc and wrapped to be path-agnostic, so you can just drop them into 
your home directory or something and add the bin subdirectory to your $PATH, 
then use the prefixed tool names ala sparc-cc and sparc-ld and such.)

Rob
-- 
GPLv3: as worthy a successor as The Phantom Menace, as timely as Duke Nukem 
Forever, and as welcome as New Coke.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: release? (Was: Re: bison and m4 with uclibs linuxthreads (new): error: field '_sp' has incomplete type)

[Rob Landley]

On Sunday 28 November 2010 07:11:14 Natanael Copa wrote:
 On Sun, Nov 28, 2010 at 12:34 AM, Bernhard Reutner-Fischer

 rep.dot@gmail.com wrote:
  Hi,
 
  I will have a look at the strtoq ASAP. Feel free to test current master
  which is what RC1 will essentially be.

 I would like to have the 2 patches in here
 https://bugs.busybox.net/show_bug.cgi?id=2713 too.

 I will *try* allocate some time to take a closer look at the protected
 symbol cleanup next week. I looked at it abit and it seems to be more
 complicated than I first thought.

 I have also a fesetround() for x86_64 comming up. Its needed for building
 qemu.

 Thanks!

I note that the point of an -rc1 isn't necessarily to have all known issues 
resolved, but to inform the community that we've switched from development of 
new features to release stabilization (I.E. a feature freeze is in place until 
we get the release out), and that we want _bug_reports_ now, so they'd better 
test their stuff with this and let us know what's broken or else it may not 
work in that release.

Release notes saying X, Y, and Z are known issues is more or less expected.  
(Heck, the final version is guaranteed to have _something_ wrong with it.  
That's why bugfix-only dot releases are a good idea. :)

Rob
-- 
GPLv3: as worthy a successor as The Phantom Menace, as timely as Duke Nukem 
Forever, and as welcome as New Coke.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: release? (Was: Re: bison and m4 with uclibs linuxthreads (new): error: field '_sp' has incomplete type)

[Rob Landley]

On Tuesday 02 November 2010 14:22:00 Bernhard Reutner-Fischer wrote:
 Well, I need to merge in microblaze (pending input, not a show-stopper
 but would be nice) but other than that, i'm not aware of any other
 blockers for 0.9.32.. are you?

 Let's install a mental countdown.. burry my grandma on 4th (7th death in
 my family during the last 12 months -- literally. uncool, ain't it :(
 ), resurrect microblaze tuesday/wednesday next week (that'd be 9th-10th)
 declare an RC1 on 2010, finish theme-suppoert for open-phd-guiding,
 wait a week then release uClibc-0.9.32.

I'm looking forward to testing the -rc1, how goes this?  (Nothing in 
downloads, no mention on the website...)

Rob
-- 
GPLv3: as worthy a successor as The Phantom Menace, as timely as Duke Nukem 
Forever, and as welcome as New Coke.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

[PATCH] Assertion `iter-cur.wc == 0' failed.

[Rob Landley]

Still trying to build Linux From Scratch 6.7 packages against the last uClibc 
stable release, and I hit this strange assertion breaking shadow build:

# find man -name Makefile.in -exec sed -i 's/groups\.1 / /' {} \;
find: mbuiter.h: 171: mbuiter_multi_next: Assertion `iter-cur.wc == 0' failed.

That's not the busybox find breaking, that's the findutils one installed by 
an 
earlier part of the LFS build.  So I worked around it by rephrasing the LFS 
instructions to find | xargs and continued on, and then the texinfo build 
died with:

..//makeinfo/makeinfo: mbuiter.h: 171: mbuiter_multi_next: Assertion `iter-
cur.wc == 0' failed.

Which is a pattern.  So I googled, and found this:

  http://bugs.gentoo.org/show_bug.cgi?format=multipleid=288743

What I learned from that is:

  1) This has been a known bug in gentoo for over a year now.
  2) Their fix is to back off to 0.9.28.

What I also happen to know is that the uClibc repository is an extremely 
unpleasant thing to try to git bisect because half the commits between release 
versions don't even _compile_, let alone let you build packages against them.

Does anyone have an opinion on this?  (Other than why the hell is the FSF 
force-inlining a 59-line C function, because if they weren't crazy there 
wouldn't be much need for uClibc or busybox...)  I really don't know anything 
about internationalization, and am thus not the best candidate to try to make 
it work.  That said, it's been more or less stagnant since 2003 (and 
completely stagnant since 2005) while everybody fails to put out a release 
containing NPTL, so I guess if I want it to work I'll have to fix it myself.

(I'm tempted to just install http://penma.de/code/gettext-stub/ and see how 
far I get with that, but it was a one line fix.  Attached.)

Rob
-- 
GPLv3: as worthy a successor as The Phantom Menace, as timely as Duke Nukem 
Forever, and as welcome as New Coke.
diff -ruN uClibc/libc/misc/wchar/wchar.c uClibc.bak2/libc/misc/wchar/wchar.c
--- uClibc/libc/misc/wchar/wchar.c	2010-04-02 10:34:27.0 -0500
+++ uClibc.bak2/libc/misc/wchar/wchar.c	2010-11-20 21:57:16.0 -0600
@@ -286,6 +286,7 @@
 		s = empty_string;
 		n = 1;
 	} else if (*s == '\0') {
+		if (pwc) *pwc = 0;
 	/* According to the ISO C 89 standard this is the expected behaviour.  */
 		return 0;
 	} else if (!n) {
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: release? (Was: Re: bison and m4 with uclibs linuxthreads (new): error: field '_sp' has incomplete type)

[Rob Landley]

On Tuesday 02 November 2010 14:22:00 Bernhard Reutner-Fischer wrote:
 On Mon, Nov 01, 2010 at 02:42:48PM +0100, Natanael Copa wrote:
 On Sun, Oct 31, 2010 at 11:37 PM, Rob Landley r...@landley.net wrote:
  I hate to bring up the word release on this list, but is there any
  chance of integrating this patch actually meaning something in the
  forseeable future?
 
 I wonder the same.

 Sorry, i've been busy buring Onkel Emil and taking over his duties to
 prepare $HOME for the winter.

 I am about to create the second release of Alpine Linux based off a
 git snapshot of uclibc. Atleast for x86 the git master with NPTL have
 been very stable recently, infact better than any previous release.
 
 What are the big show stoppers for next uclibc release?

 Well, I need to merge in microblaze (pending input, not a show-stopper
 but would be nice) but other than that, i'm not aware of any other
 blockers for 0.9.32.. are you?

 Let's install a mental countdown.. burry my grandma on 4th (7th death in
 my family during the last 12 months -- literally. uncool, ain't it :(

Suckage. :(

 ), resurrect microblaze tuesday/wednesday next week (that'd be 9th-10th)
 declare an RC1 on 2010, finish theme-suppoert for open-phd-guiding,
 wait a week then release uClibc-0.9.32.

 So.. outstanding issues for 0.9.32, code-wise?

Um, wow.  Really?

Caught by surprise here.  I suppose this means I should start actually testing 
-git again.  (Is feeding a 0.9.31 .config into the thing and doing make 
oldconfig likely to produce a remotely useful result?)

I'm up to applying 10 patches to uClibc 0.9.31 to get my various targets and 
about 95% of the Linux From Scratch 6.7 build to complete.  (Currently trying 
to figure out why udev is mis-extracting.)  I think I've waved all of these at 
the list at one point or another, but just in case:

  http://landley.net/hg/aboriginal/file/tip/sources/patches

I'll try to finish up the Linux From Scratch build automation with the old 
uClibc, then I can regression test the new one against that...

Rob
-- 
GPLv3: as worthy a successor as The Phantom Menace, as timely as Duke Nukem 
Forever, and as welcome as New Coke.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH] ld.so: ldd crashes when __LDSO_SEARCH_INTERP_PATH__ is not #defined

[Rob Landley]

On Monday 15 November 2010 15:50:38 Bernhard Reutner-Fischer wrote:
 On Mon, Nov 15, 2010 at 02:14:00PM -0500, Mark Mentovai wrote:
 Poke?
 
 This is a simple fix to a reproducible crash. I’m surprised it hasn’t been
  committed, or if there’s a problem with the patch, that it hasn’t been
  raised.

 I didn't look in detail yet but it sounds like it penalized
 LDSO_SEARCH_INTERP_PATH more than it ought to (i.e. there must be a
 better way).

Um, the patch is inside if (trace_loaded_objects) and prints out crap to 
stdout:

 if (trace_loaded_objects) {
  -  _dl_dprintf(1, \t%s = %s (%x)\n,
  -  rpnt-dyn-libname + _dl_strlen(_dl_ldsopath) + 1,
  -  rpnt-dyn-libname, 
  DL_LOADADDR_BASE(rpnt-dyn-loadaddr));
  +  /* glibc ld.so/ldd would just do
  +   * _dl_dprintf(1, \t%s (%x)\n, rpnt-dyn-libname,
  +   * DL_LOADADDR_BASE(rpnt-dyn-loadaddr));
  +   * but uClibc has always used the = format. */
  +  char *ptmp = _dl_strrchr(rpnt-dyn-libname, '/');
  +  if (ptmp != rpnt-dyn-libname)
  +  ++ptmp;
  +  _dl_dprintf(1, \t%s = %s (%x)\n, ptmp, rpnt-dyn-libname,
  +  DL_LOADADDR_BASE(rpnt-dyn-loadaddr));
 _dl_exit(0);
 }
  #endif

This is a performance-critical codepath?

Rob
-- 
GPLv3: as worthy a successor as The Phantom Menace, as timely as Duke Nukem 
Forever, and as welcome as New Coke.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Poking at PREBUILT_LOCALES...

[Rob Landley]

On Monday 15 November 2010 11:48:02 Bernhard Reutner-Fischer wrote:
 On Mon, Nov 15, 2010 at 06:45:40PM +0100, Bernhard Reutner-Fischer wrote:
 On Sun, Nov 14, 2010 at 09:32:12PM -0600, Rob Landley wrote:
 Does anybody still understand the uClibc locale stuff?  It _seems_ to be
 generating them well enough to build gettext under the resulting root
 filesystem, for what that's worth.  But I can't run the build on my
  gentoo server unless I want to install locale stuff on the host, and I'm
  trying to make this build portable and with minimal environmental
  dependencies so I'd probably rip locale stuff back out and just install
  libiconv natively on target to make Linux From Scratch happy (I already
  checked and that works) if I can't get it to build on a host that
  doesn't have locales already...
 
 The old tarball (that didn't work on a handful of machines -- don't
 remember which ones but ISTR that it was an endian issue) can still be
 found in http://uclibc.org/downloads/
 Current setups would need the same files as that tarball. If you can
 verify that

 [pressed send too fast, sorry]
 If you can verify that the wordsize or endianess does not matter then
 even better.

I dunno about matter, but for the new files it's actually installling the 
word size and endianness don't actually _differ_.

But the files I listed (all header files) were the only new files it was 
installing.  I have no idea what locale_data.c is used for.  Possibly some of 
the locale stuff winds up as extra .o content in existing libraries that are 
installed even if locale support is disabled.  I utterly despise Makefiles 
because of their horribly nonlinear nature meaning trying to figure out what a 
makefile DOES with a given file, where its sources coe from and where its 
output 
goes, is a sad exercise is pointless frustration  But I'll try to schedule 
some frustration time this evening...

Rob
-- 
GPLv3: as worthy a successor as The Phantom Menace, as timely as Duke Nukem 
Forever, and as welcome as New Coke.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Poking at PREBUILT_LOCALES...

[Rob Landley]

On Monday 15 November 2010 14:18:56 Will Newton wrote:
 On Mon, Nov 15, 2010 at 5:48 PM, Bernhard Reutner-Fischer

 rep.dot@gmail.com wrote:
  On Mon, Nov 15, 2010 at 06:45:40PM +0100, Bernhard Reutner-Fischer wrote:
 On Sun, Nov 14, 2010 at 09:32:12PM -0600, Rob Landley wrote:
 Does anybody still understand the uClibc locale stuff?  It _seems_ to be
 generating them well enough to build gettext under the resulting root
 filesystem, for what that's worth.  But I can't run the build on my
  gentoo server unless I want to install locale stuff on the host, and
  I'm trying to make this build portable and with minimal environmental
  dependencies so I'd probably rip locale stuff back out and just install
  libiconv natively on target to make Linux From Scratch happy (I already
  checked and that works) if I can't get it to build on a host that
  doesn't have locales already...
 
 The old tarball (that didn't work on a handful of machines -- don't
 remember which ones but ISTR that it was an endian issue) can still be
 found in http://uclibc.org/downloads/
 Current setups would need the same files as that tarball. If you can
 verify that
 
  [pressed send too fast, sorry]
  If you can verify that the wordsize or endianess does not matter then
  even better.

 I found problems on our little endian 32bit systems that have more
 stringent structure alignment than x86 (8 bytes). I didn't manage to
 debug it any further because I can easily cope without locales.

I'm trying to build Linux From Scratch 6.7 against uClibc, doing i686 first as 
the low hanging fruit, and gettext very much wanted internationlization 
support on the host.  I added it, it compiled and moved on, but I'm not really 
_doing_ anything with internationalization.  I suspect I'm not installing it 
correctly, but there's no special install target for it, so...

What problems were you seeing?  How do I reproduce/test?  I have test 
environments for arm, mips, powerpc, x86, x86-64, and bits of sparc and sh4 
support that I really need to clean up after I get untangled from this.

Rob
-- 
GPLv3: as worthy a successor as The Phantom Menace, as timely as Duke Nukem 
Forever, and as welcome as New Coke.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Poking at PREBUILT_LOCALES...

[Rob Landley]

I added this to my uClibc 0.9.31 config:

  UCLIBC_HAS_LOCALE=y
  UCLIBC_HAS_XLOCALE=y
  UCLIBC_BUILD_MINIMAL_LOCALE=y

Which worked fine on my ubuntu laptop, but won't build on a host that doesn't 
have locale data installed (such as my gentoo server).  So I'd like to switch 
on the PREBUILT_LOCALE stuff, except it doesn't exist so I have to supply my 
own.

In theory, what it tries to do is download a tarball with the 
BUILD_MINIMAL_LOCALE results for the appropriate endianness and word size, and 
since I'm building a gazillion targets anyway this shouldn't be too hard for 
me to fish out of the uClibc build directory and save.

Except I have no idea what should go in this tarball.  The make clean stuff 
in the top level makefile is attempting to delete *.tgz tarballs out of the 
extras/locale directory, but there aren't any.  I find the whole thing 
confusing.

As far as I can tell, the only locale information that uClibc actually 
installs into the target filesystem is some header files.  (This comes from 
diffing the resulting filesystems with locales installed and not installed.)  
Specifically these three:

  root-filesystem-i686/usr/include/bits/uClibc_locale_data.h
  root-filesystem-i686/usr/include/iconv.h
  root-filesystem-i686/usr/include/xlocale.h

Of those, the only one that varies at all is uClibc_locale_data.h.  In 
_theory_ I should be able to just snapshot that one file.  But that's not what 
the current PREBUILT_LOCALES stuff is _doing_, and I don't see where the 
complaints about it being endian-dependent and word-size dependent and such 
come from if it's a .h file...?

Does anybody still understand the uClibc locale stuff?  It _seems_ to be 
generating them well enough to build gettext under the resulting root 
filesystem, for what that's worth.  But I can't run the build on my gentoo 
server unless I want to install locale stuff on the host, and I'm trying to 
make this build portable and with minimal environmental dependencies so I'd 
probably rip locale stuff back out and just install libiconv natively on target 
to make Linux From Scratch happy (I already checked and that works) if I can't 
get it to build on a host that doesn't have locales already...

Rob
-- 
GPLv3: as worthy a successor as The Phantom Menace, as timely as Duke Nukem 
Forever, and as welcome as New Coke.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Should BusyBox and uClibc also make a flag version like Embedded Linux?

[Rob Landley]

On Thursday 11 November 2010 09:51:34 Jonathan Corbet wrote:
 Hi, Rob,

  Look: Linux has to deal with binary only modules, which the developers
  hate. To compensate for this, they go out of their way to avoid having a
  stable internal API (which could argualy be used as a copyright barrier
  and thus prevent the modules from being derived works of the Linux kernel
  to which GPLv2 must apply).  To avoid this, they break internal
  compatability essentially every release.  They go out of their way _not_
  to make forward- porting modules easy (otherwise they'd have a checklist
  each release saying do this this and this, and you'll be up to date).

 Suffice to say I disagree with this characterization; one should not
 confuse a lack of sympathy for maintainers of out-of-tree modules with a
 deliberate attempt to make life hard.

There's a fine line between wilfully obtuse and actively obstructive.  The 
merge your damn code already camp has excellent engineering motivations, and 
they certainly have plausible deniability.  Having seen Greg speak on the 
topic more than once (his OLS binary only modules are definitely illegal talk 
comes to mind), I find it easy to ascribe deliberation to him, but I'm not a 
mind reader.

 There are other reasons for the
 internal API policy, but I doubt anybody would benefit from an extended
 discussion of them here.

I readily admit I'm over-simplifying the actions of ~300 guys over the past 
decade, and they don't all agree.  Linus's policy seems merely to be Shut up 
and show me the code, as always, and nobody else speaks authoritatively for 
the kernel.

 One little point of fact, though:
  Some people weren't happy with that, and decided to set up an
  intermediate staging area to help distros coordinate their long term
  support efforts. Adrian Bunk backported bugfixes to 2.6.16 for several
  years:
 
http://kerneltrap.org/node/6930
http://kerneltrap.org/node/7164
http://lwn.net/Articles/266707/
 
  And when that became hopelessly out of date he moved to 2.6.27:
 
http://lkml.org/lkml/2008/10/12/2

 Adrian has not had a patch merged for over a year, and has never gone near
 2.6.27.  That kernel is maintained by Greg Kroah-Hartman; it looks like
 Willy Tarreau may pick it up at some future point.

I vaguely recall a message wandering by from Adrian circa 2008 about him 
giving up on 2.6.16 and picking up a new kernel.  Doesn't mean it happened.  
For one thing, Greg's -stable series was well underway by then, and he picked 
up my suggestion of one last -stable when the new kernel comes out so there's 
no gap between versions bugfix-wise, and anybody stuck on an old kernel can 
look at all the bugfix-only patches for the new kernels since them and try to 
backport fixes without any obvious gaps between the last 2.6.n.x and the start 
of 2.6.n+1 where bugfixes went in but weren't broken out.

It's not perfect, but -stable took a lot of the wind out of the LTS kernel 
sails.  I believe he moved on to maintaining the regression list instead (same 
motivation, different solution).

Between the busybox FAQ entry I linked to earlier, and the time based releases 
video, I hope I've documented why attempting to maintain old stable versions 
does not help an open source project actually do development.  For a project 
like the kernel that's got engineering effort coming out its years, yay.  They 
have spare bandwidth.

For a project like uClibc or busybox where we've had major architectural todo 
items going begging for MORE THAN FIVE YEARS now? (Yes seriously: uClibc still 
has pthreads.old, pthreads.new, _and_ NPTL hanging around unfinished.  Busybox 
has three shell implementations and none of them is a decent bash replacement, 
we've settled on hush as the way forward but it needs six months of full-time 
work before we can delete the crufty old maze of ash code, plus the testsuite 
is in three different formats and bits of it are scattered all over the 
tree...)

Pulling existing developers off of that to babysit a dead tree version of the 
code is not the best use of their time.  If that's what a new developer wants 
to do, they're welcome to bell that cat.

 jon

Rob
-- 
GPLv3: as worthy a successor as The Phantom Menace, as timely as Duke Nukem 
Forever, and as welcome as New Coke.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Should BusyBox and uClibc also make a flag version like Embedded Linux?

[Rob Landley]

On Thursday 11 November 2010 09:07:31 Mark Brown wrote:
 On Wed, Nov 10, 2010 at 04:04:06PM -0600, Rob Landley wrote:
  Look: Linux has to deal with binary only modules, which the developers
  hate. To compensate for this, they go out of their way to avoid having a
  stable internal API (which could argualy be used as a copyright barrier
  and thus prevent the modules from being derived works of the Linux kernel
  to which GPLv2 must apply).  To avoid this, they break internal
  compatability essentially every release.  They go out of their way _not_
  to make forward- porting modules easy (otherwise they'd have a checklist
  each release saying do this this and this, and you'll be up to date).

 Pretty much all of this, especially the bit about the motivations behind
 the API changes that do occur, is inaccurate.

Pretty much all of this is inaccurate.

So you're saying the linux developers don't hate binary only modules?  They 
like the idea of a stable internal API?  Driver and filesystem patches can 
regularly expect to apply unmodified to multiple versions?  Somewhere in the 
release notes or some such there's a checklist of changes you'd need to make 
to update an out of tree driver to the next kernel version?

I'd love to find that last one.  http://lwn.net/Articles/2.6-kernel-api/ was 
last updated over a year ago, and never claimed to be complete.  Neither 
http://kernelnewbies.org/LinuxChanges nor http://www.h-
online.com/open/features/What-s-new-in-Linux-2-6-36-1103009.html are 
specifically about API changes.  (Also, none of these are actually part of the 
kernel release process.)

I'm not a mind reader, and can only give my impression/opinion of their 
motivations for doing stuff.  There's one closed-mouthed linus, a dozen 
argumentative lieutenants, and hundreds of active maintainers: they don't have 
a single monolithic motivation.  Heck, last I checked (um, 2006?) Linus still 
had a strong pesonal dislike for Richard Stallman, but continued to use the 
FSF's compiler.

I also agree the kernel developers have good engineering justifications for 
what they do.  I'm not trying to accuse them of anything.  But I've been paid 
to do open source and I do open source to get paid are not equivalent 
statements, the world contains more subtleties than that.

My point was merely the kernel has its own issues that do not apply to uClibc 
or busybox.  One of those things is different political undercurrents.  (And 
yes the embedded world has its own.  You can't explain _our_ users or 
developers' behavior entirely in terms of engineering either.)

Rob
-- 
GPLv3: as worthy a successor as The Phantom Menace, as timely as Duke Nukem 
Forever, and as welcome as New Coke.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Should BusyBox and uClibc also make a flag version like Embedded Linux?

[Rob Landley]

No, they shouldn't.

On Friday 05 November 2010 11:33:36 Bradley M. Kuhn wrote:
 LWN.net  wrote at 18:30 (EDT) on Thursday:
  As a result of discussions held at two recent embedded Linux summits
  (and reported back to the recent Kernel Summit), the [Linux] community
  has decided to identify specific kernel versions as flag versions to
  try to reduce version fragmentation. On the linux-embedded mailing
  list, Tim Bird ... has announced that 2.6.35 will be the first
  embedded flag version, and it will be supported by (at least) Sony,
  Google, MeeGo, and Linaro. First, it should be explained what having
  a flag version means. It means that suppliers and vendors throughout
  the embedded industry will be encouraged to use a particular version
  of the kernel for software development, integration and testing. Also,
  industry and community developers agree to work together to maintain a
  long-term stable branch of the flag version of the kernel (until the
  next flag version is declared), in an effort to share costs and
  improve stability and quality.

 Tim Bird's email post that LWN is quoting from above can be seen at:
 http://lwn.net/Articles/413341/rss

 (There's also a brief summary at
 http://lwn.net/SubscriberLink/413036/a954ac0a143a99d9/ of the discussion
 that took place at the embedded kernel summit on this).

Neither uClibc nor busybox has even 1% of the churn of the linux kernel.

Look: Linux has to deal with binary only modules, which the developers hate.  
To compensate for this, they go out of their way to avoid having a stable 
internal API (which could argualy be used as a copyright barrier and thus 
prevent the modules from being derived works of the Linux kernel to which 
GPLv2 must apply).  To avoid this, they break internal compatability 
essentially every release.  They go out of their way _not_ to make forward-
porting modules easy (otherwise they'd have a checklist each release saying do 
this this and this, and you'll be up to date).

Instead they promote as much churn as possible, every single release, and make 
keeping up with it a black art.  This is to force a stark binary choice with 
no middle ground: either get your code merged in-tree where they forward port 
it, or your code remains stuck on older versions and can only be forward-
ported by a labor-intensive combination of research, guesswork, and elbow 
grease, and luck.

BusyBox does not have this problem.  A patch against an 18 month old version 
of the linux kernel is 6 releases out of date, and has almost no chance of 
applying or working on a current kernel.  A patch against an 18 month old 
version of busybox will probably apply to current busybox unmodified.

 I read this and began wondering if uClibc and BusyBox had an interest in
 doing flag versions in tandem with Linux.

uClibc has gone entire years without a release on more than one occasion.  
(And I don't mean like 2009 where there was no new _development_ release and 
only the 0.9.30.1 bugfix-only release.  No, I mean there wasn't any new release 
of any kind from uClibc in the calendar year 2006, and there was a year and a 
half gap between 0.9.29 and the following 0.9.30-rc with nothing in between.)

Even under the new management, the project's last release was seven months 
ago, and my Aboriginal Linux project is carrying eight uClibc fix patches since 
then.  I just posted to uclibc about something that got a fix posted in 
February but still isn't fixed in 0.9.31, and of course there have been no 
releases since so it's still broken in current.  I've forwarded patches to the 
uclibc list from 2007 that hadn't been applied to the development branch yet, 
let alone made it into a release.  I reply to six month old messages more 
often than I reply to current ones.

As for the development branch: the OLS paper on NPTL for uClibc was published 
in 2006, but NPTL support still hasn't made it onto a uClibc release yet.  A 
human this constipated would be dead by now.

In that context, the idea of marking specific releases of uClibc special is 
black comedy.  There aren't enough release of this project for any release 
_not_ to be special.

 As most of you know, I do a
 lot of GPL enforcement work for BusyBox, and I find frequently companies
 stuck on ridiculously old versions of BusyBox and uClibc.  I constantly
 encourage companies, as part of compliance efforts, to use more recent
 versions but I have been mostly unsuccessful in that part of the effort.

Flag versions will do nothing for this.  Embedded developers aren't stuck on 
ridiculously old versions of busybox because newer versions of busybox don't 
_work_.  Or because newer versions of busybox aren't a drop-in replacement for 
the old ones.  They're stuck because they don't replace software that works 
for them.  Last I checked, linksys routers were still using a kernel from 
2003, and since then Cisco dissolved its linksys engineering team.

The kernel is creating workarounds for its own 

Re: Bug: forward declaration of __uclibc_locale_struct

[Rob Landley]

On Tuesday 13 July 2010 09:45:41 Bernhard Reutner-Fischer wrote:
 On Mon, Jul 12, 2010 at 09:20:13AM -0700, Khem Raj wrote:
 On Mon, Jul 12, 2010 at 7:41 AM, Evan Kroske e.kro...@gmail.com wrote:
  I'm trying to compile a uClibc cross-toolchain with locale support,
 
 I would suggest to use something like crosstool-ng, buildroot or
  openemebedded where these toolchains are already generated and you might
  have to do little locale support on uclibc might need some patches to gcc
  or vice versa.

 https://bugs.uclibc.org/show_bug.cgi?id=53#c13
 ___
 uClibc mailing list
 uClibc@uclibc.org
 http://lists.busybox.net/mailman/listinfo/uclibc

For the record, this bug is still present in the last stable release of uClibc 
(0.9.31), and when going through and building Linux From Scratch 6.7 it breaks 
building gettext for i686:

libtool: compile:  gcc -c -DLOCALEDIR=\/usr/share/locale\ -
DLOCALE_ALIAS_PATH=\/usr/share/locale\ -DLIBDIR=\/usr/lib\ -
DBUILDING_LIBINTL -DBUILDING_DLL -DIN_LIBINTL -DENABLE_RELOCATABLE=1 -
DIN_LIBRARY -DINSTALLDIR=\/usr/lib\ -DNO_XMALLOC -
Dset_relocation_prefix=libintl_set_relocation_prefix 
-Drelocate=libintl_relocate 
-DDEPENDS_ON_LIBICONV=1 -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -
fvisibility=hidden ./localename.c  -fPIC -DPIC -o .libs/localename.o
./localename.c: In function '_nl_locale_name_thread_unsafe':
./localename.c:2619: error: dereferencing pointer to incomplete type
make[3]: *** [localename.lo] Error 1
make[3]: Leaving directory `/home/gettext/gettext-runtime/intl'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/gettext/gettext-runtime'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/gettext/gettext-runtime'
make: *** [all-recursive] Error 1
Command exited with non-zero status 1

Rob
-- 
GPLv3: as worthy a successor as The Phantom Menace, as timely as Duke Nukem 
Forever, and as welcome as New Coke.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: bison and m4 with uclibs linuxthreads (new): error: field '_sp' has incomplete type

[Rob Landley]

On Sunday 31 October 2010 16:43:00 Khem Raj wrote:
 heh it was a suggestion rather than an order as you interpreted :) and
 because you have spend time to understand the problem to its entirety
 it would be more effective if you looked
 this aspect of it as well, which you did so thanks for it.

Sorry, stressful week.  (My last contract ended unexpectedly because the 
department I was working for didn't get its budget approved.  Just did a two 
week push to try to get as much finished and handed off as possible, and now 
I'm 
catching up on open source todo items on my first really free weekend in 
months...)

I'm a bit snappish right now, trying to focus more on coding than 
correspondence. :)

  More to the point, _when_ I dug down into it I found out (and explained
  in the above email) that this codepath only triggers when we _haven't_
  got posix_spawn(), and as far as I can tell it wouldn't work in glibc
  either but since they do have posix_spawn() it doesn't come up.

 Whats your opinion if we implement posix_spawn in uclibc ?

Considering that it's in posix, probably a good idea?  At least as a config 
option...

There's a longish thread about why the _kernel_ doesn't have it here:

  http://lwn.net/Articles/360509/

According to the copyright on spawn.h, it's been in glibc since 2003.  And the 
problems comes in when we claim to be glibc, then don't provide things glibc 
does.  It tends to send configure scripts and #ifdef trees down untested paths. 
 
(A config option to not pretend to be glibc would be entertaining to test. :)

*shrug*  The header change I posted wired around the need for it in m4 and 
bison.  What we _really_ need is a lot more regression testing against actual 
packages, which I'm working on now.  (I'm teaching Aboriginal LInux to auto-
build Linux From Scratch on every supported target, and then I can do Beyond 
Linuxx From Scratch, and then I can get back to bootstrapping gentoo.  I was 
trying to bootstrap gentoo first, but getting packages to work against uclibc 
and busybox _and_ getting portage and catalyst to work all in one go...  bit 
much to chew at once.  Getting the packages to work, _then_ getting portage to 
work, makes much more sense...)

  By the way, as long as you're ordering me to do more work, I note that
  this is from 2008:
 
  http://repository.timesys.com/buildsources/u/uClibc/uClibc-0.9.30/uClibc-
 0.9.30- unexport_ruserpass.patch

 this patch looks good to me. We should integrate it.

Woot.

I hate to bring up the word release on this list, but is there any chance of 
integrating this patch actually meaning something in the forseeable future?

Rob
-- 
GPLv3: as worthy a successor as The Phantom Menace, as timely as Duke Nukem 
Forever, and as welcome as New Coke.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: bison and m4 with uclibs linuxthreads (new): error: field '_sp' has incomplete type

[Rob Landley]

On Tuesday 30 March 2010 06:11:44 Michael Deutschmann wrote:
 On Tue, 30 Mar 2010, Natanael Copa wrote:
  and with m4-1.4.14 i get this:
 
  In file included from pipe.c:48:
  ./spawn.h:112: error: field '_sp' has incomplete type
  make[3]: *** [pipe.o] Error 1

 This sounds like a problem I've had on my own system, which is
 threadless.  So linuxthreads has nothing to do with it.

 My local patch to m4, supressing the bug, is appended.  The comment next
 to the conditional I've spiked makes it clear what is going on.
 Apparently, glibc's headers expose the full definition of struct
 sched_param in cases not required by the standard, and gnulib attempts to
 optimize based on this. uClibc does not share glibc's behavior in this one
 case, but since it defines __GLIBC__, gnulib sees no need for caution.

That's not actually the problem, although your workaround does work.  (So does 
using struct __sched_param instead of struct sched_param for the _sp definition 
in the struct.)

But the actual problem is that uClibc hasn't got posix_spawn(), thus no 
/usr/include/spawn.h.  In m4's lib/spawn.in.h:

#if @REPLACE_POSIX_SPAWN@ || !...@have_posix_spawnattr_t@
typedef struct
{
  short int _flags;
  pid_t _pgrp;
  sigset_t _sd;
  sigset_t _ss;
  struct sched_param _sp;
  int _policy;
  int __pad[16];
} posix_spawnattr_t;
#endif

./configure sets HAVE_POSIX_SPAWNATTR_T to 1 for glibc, 0 for uClibc.  So this 
chunk of code doesn't get sucked in for glibc (#if 0 || !1) because because 
the struct is defined in /usr/include/spawn.h.  For uClibc (#if 0 || !0) it 
gets sucked in, but never gets triggered due to the if # __GLIBC__ (making it 
work for BSD).

So the fix is either:

1) Don't claim to be glibc.
2) Provide posix_spawn() so it doesn't try to replace it.
3) Patch multiple upstream packages that have copied code from each other.
4) export CFLAGS=-Dsched_param=__sched_param
5) Tweak our bits/sched.h to always provide sched_param when it provides 
__sched_param, which is what the upstream packages seem to expect.

I went with #5, using the attached patch to uClibc.

Rob
-- 
GPLv3: as worthy a successor as The Phantom Menace, as timely as Duke Nukem 
Forever, and as welcome as New Coke.

diff -ru uClibc/libc/sysdeps/linux/common/bits/sched.h uClibc.bak/libc/sysdeps/linux/common/bits/sched.h
--- uClibc/libc/sysdeps/linux/common/bits/sched.h	2010-04-02 10:34:27.0 -0500
+++ uClibc.bak/libc/sysdeps/linux/common/bits/sched.h	2010-10-15 13:38:43.0 -0500
@@ -61,6 +61,7 @@
 # define CLONE_STOPPED	0x0200 /* Start in stopped state.  */
 #endif
 
+#undef sched_param
 /* The official definition.  */
 struct sched_param
   {
@@ -82,6 +83,8 @@
 
 __END_DECLS
 
+#else
+#define sched_param __sched_param
 #endif	/* need schedparam */
 
 #if !defined __defined_schedparam \
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

uClibc++ stuff.

[Rob Landley]

Garrett: do you still work on uClibc++ at all anymore?  I can't seem to find 
the git repo, if so, and the last release was three years ago.

I mention this because Aboriginal Linux is using uClibc++-0.2.2, and I'm 
trying to build Linux From Scratch 6.7 under it, and it gets here in the gmp 
build:

/bin/bash ../libtool --tag=CXX   --mode=compile g++ -DHAVE_CONFIG_H -I. -I.. -
D__GMP_WITHIN_GMPXX -I..-m32 -O2 -pedantic -fomit-frame-pointer -
mtune=pentiumpro -march=pentiumpro -c -o ismpf.lo ismpf.cc
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I.. -D__GMP_WITHIN_GMPXX -I.. -m32 
-O2 -pedantic -fomit-frame-pointer -mtune=pentiumpro -march=pentiumpro -c 
ismpf.cc  -fPIC -DPIC -o .libs/ismpf.o
ismpf.cc: In function 'std::istream operator(std::istream, 
__mpf_struct*)':
ismpf.cc:53: error: 'use_facet' was not declared in this scope
ismpf.cc:53: error: 'numpunct' was not declared in this scope
ismpf.cc:53: error: expected primary-expression before 'char'
ismpf.cc:53: error: expected ',' or ';' before 'char'
ismpf.cc:65: error: expected initializer before '' token
ismpf.cc:71: error: 'ct' was not declared in this scope
ismpf.cc:71: error: 'ctype_base' has not been declared
make[2]: *** [ismpf.lo] Error 1

And I'm rusty enough on C++ I thought I'd ask first before trying to dig into 
it myself.  I can provide reproduction sequences and narrow down the code 
snippet a bit if it helps...

Rob
-- 
GPLv3: as worthy a successor as The Phantom Menace, as timely as Duke Nukem 
Forever, and as welcome as New Coke.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

[PATCH] Re: Anybody used mips64 recently?

[Rob Landley]

On Tuesday 01 June 2010 13:17:04 Khem Raj wrote:
 On (01/06/10 04:35), Rob Landley wrote:
  On Sunday 23 May 2010 16:11:50 Khem Raj wrote:
   On Sun, May 23, 2010 at 12:36 PM, Rob Landley r...@landley.net wrote:
On mips64, I built hello world, it segfaulted.  Built it dynamic, got
this:
   
 hello: symbol 'ntp_gettime': can't handle reloc type 0x3 in lib
'/lib/libc.so.0'
  
   hmm that would be R_MIPS_REL in mips64. Would you post the binaries
   somewhere to look at.
   and are you using NPTL or LinuxThreads.
  
   -Khem
 
  Finally managed to bisect the commit that horked this up for me:

 Hi Rob

 Attached it untested patch. Please try it out and let me know if it
 compiles and runs your test program or not.

 Thanks
 -Khem

Yup, this patch fixes it.

Signed-off-by: Rob Landley r...@landley.net

Could we please get out a 0.9.31.1 release with at least the x86-64 fix and 
this one?

Thanks,

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds
diff --git a/ldso/ldso/mips/elfinterp.c b/ldso/ldso/mips/elfinterp.c
index b6e0932..a56ee81 100644
--- a/ldso/ldso/mips/elfinterp.c
+++ b/ldso/ldso/mips/elfinterp.c
@@ -172,8 +172,8 @@ int _dl_parse_relocation_information(struct dyn_elf *xpnt,
 	for (i = 0; i  rel_size; i++, rpnt++) {
 		reloc_addr = (unsigned long *) (tpnt-loadaddr +
 			(unsigned long) rpnt-r_offset);
-		reloc_type = ELF32_R_TYPE(rpnt-r_info);
-		symtab_index = ELF32_R_SYM(rpnt-r_info);
+		reloc_type = ELF_R_TYPE(rpnt-r_info);
+		symtab_index = ELF_R_SYM(rpnt-r_info);
 		symbol_addr = 0;
 
 		debug_sym(symtab,strtab,symtab_index);
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: chiming in 1.0.0-rc1

[Rob Landley]

On Tuesday 25 May 2010 17:12:20 Bernhard Reutner-Fischer wrote:
 Hi,

 TODO list for 1.0.0-rc1, random order.

 - Adjust Rules.mak MAJOR_VERSION, MINOR_VERSION, SUBLEVEL, EXTRAVERSION
   Make sure that soname remains at .0
 - disable !NPTL for arches that have NPTL impls.
   Disable threads for everybody who doesn't have NPTL to force
   psychological strain (one could argue about this).

If you're going to do that, remove the pthreads implementaiton.  If not, 
don't.

   Where '+' means ported, 'o' means TODO/needs verification

I vaguely tested powerpc (it sort of worked, but not entirely).  I can test 
arm, mips, and sparc.

   Arches that pretend to support threads (i.e. NPTL) have to submit
   sensible testresults to be whitelisted (ideally on a regular base,
   automated).

You're not going to get this for vax, m68k, alpha, hppa.  That doesnt' mean 
nobody's using those platforms, just that there aren't many of them and 
they're not following head very closely.

For the architectures QEMU and my build system support, I can set up a cron 
job to test stuff under qemu.  (I might be able to test m68k under Aranym, but 
that's has no serial console and is thus not scriptable.)  What counts as 
sensible test results?

My problem is right now I've got a day job that eats all my time and energy 
during the week, so I'm down under 10 hours a week (including weekends) of 
open source programming time...

 - SUSv4 audit
   This would be the big thing, API-wise, to warrant a 1.0.

 I'd aim for 2010-06-30 for a 1.0.0-rc1 (on master), i.e. one month from
 now on.

I'll see what I can do. :)

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Anybody used mips64 recently?

[Rob Landley]

On mips64, I built hello world, it segfaulted.  Built it dynamic, got this:

  hello: symbol 'ntp_gettime': can't handle reloc type 0x3 in lib 
'/lib/libc.so.0'

Has anybody else used this target?  I can post binaries if it'll help.  I
suspect I'm doing something wrong, but don't know what...

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Fix fcntl64 for 64 bit targets.

[Rob Landley]

64 bit targets often don't have a separate fcntl64() system call, because they 
don't need one.

Signed-off-by: Rob Landley r...@landley.net

--- uClibc/include/fcntl.h  2010-04-02 10:34:27.0 -0500
+++ uClibc.bak/include/fcntl.h  2010-05-16 04:54:10.0 -0500
@@ -73,7 +73,7 @@
 
This function is a cancellation point and therefore not marked with
__THROW.  */
-#ifndef __USE_FILE_OFFSET64
+#if !defined(__USE_FILE_OFFSET64) || defined(__LP64__)
 extern int fcntl (int __fd, int __cmd, ...);
 libc_hidden_proto(fcntl)
 #else
@@ -83,7 +83,7 @@
 #  define fcntl fcntl64
 # endif
 #endif
-#ifdef __USE_LARGEFILE64
+#if defined(__USE_LARGEFILE64)  !defined(__LP64__)
 extern int fcntl64 (int __fd, int __cmd, ...);
 libc_hidden_proto(fcntl64)
 #endif

-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

RFC: move ldconfig to make utils and remove UCLIBC_STATIC_LDCONFIG

[Rob Landley]

Wouldn't it simplify things to move ldconfig to utils build?  It's easy 
enough to feed CCFLAGS=--static to make utils, so there would be no need for 
UCLIBC_STATIC_LDCONFIG.

Just wondering why this is currently A) special cased, B) in a different area 
than the other executables like ldd and such.

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Why is make utils so complicated?

[Rob Landley]

The ldd build is essientially:
  gcc -I ldso/include utils/ldd.c

The ldconfig build adds two #defines from the command line:
  -DUCLIBC_RUNTIME_PREFIX=\$(RUNTIME_PREFIX)\
  -DUCLIBC_LDSO=$(UCLIBC_LDSO)

To build readelf with the host toolchain, you do:
  ln -s ../include/elf.h utils/elf.h
  gcc -I utils ldso/include utils/readelf.c

This is not brain surgery.  Why on earth does this require a makefile that's so 
complicated it prevents you from feeding --static in via CFLAGS, uses a 
special case .config option for whether you want to statically link ldconfig, 
but doesn't provide the _option_ to statically link ldd?

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH] MIPS: restore INLINE_SYSCALL macro

[Rob Landley]

On Tuesday 27 April 2010 11:05:25 Austin Foxley wrote:
 On 04/06/2010 08:56 AM, Gabor Juhos wrote:
  The ideal solution would to fix the 'internal_syscall' macros to generate
  correct code for the NCS case as well. However the INLINE_SYSCALL macro
  generates smaller code if the syscall number is constant, so it is
  useful in such cases.
 
  Additionally, the current INLINE_SYSCALL_NCS in the 'mips/bits/syscall.h'
  is a duplicate of the one in the 'common/bits/syscalls-common.h' so it
  should be removed anyway.
  ---
   libc/sysdeps/linux/mips/bits/syscalls.h |4 ++--
   1 files changed, 2 insertions(+), 2 deletions(-)

 Thanks, Applied. Can someone with a MIPS test setup confirm this fix
 with current HEAD?

Well, I couldn't:

  AS libc/sysdeps/linux/mips/clone.os
In file included from libc/sysdeps/linux/mips/clone.S:25:
./libc/sysdeps/linux/mips/sysdep.h:41:20: error: regdef.h: No such file or 
directory
make: *** [libc/sysdeps/linux/mips/clone.os] Error 1
make: *** Waiting for unfinished jobs

Builds fine with 0.9.31, possibly I need a .config tweak?

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds

___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

UCLIBC_EXTRA_LDFLAGS

[Rob Landley]

UCLIBC_EXTRA_CFLAGS is in Config.in.  Rules.mak has a similar 
UCLIBC_EXTRA_LDFLAGS, but that one's not in Config.in.

I'm confused?  This was introduced in 3936de030a9c53a by Bernhard...

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Apparently, glibc's static linking support is deprecated?

[Rob Landley]

On Thursday 13 May 2010 06:32:27 Laurent Bercot wrote:
  Ulrich Drepper, the glibc maintainer, has gone crazy and believes that
  static linking should never be used for anything:
 
http://people.redhat.com/drepper/no_static_linking.html

  Think about it. *Who* in his sane mind would become the glibc maintainer ?
  Even if Ulrich Drepper still had a functional brain at the time, years of
 dealing with glibc aren't a healthy thing. I can't really blame him.

  But it's okay. If glibc drops supporting static linking, it's going to
 become a niche libc. Things will break. And uClibc will fill the gap.
 Good news all in all.

  I'm *much* more concerned about gcc, because if the gcc people go insane
 - I mean, even more insane - there's still no serious alternative to gcc
 and the free software world will be in trouble.

What do you mean if?  They went GPLv3, didn't they?  Past tense.

That triggered the OpenBSD guys to dig up the compiler BSD used before gcc 
(the Portable C Compiler from the 1970's) and extend it to full C99 and x86-64 
support with a modern optimizer:

  http://pcc.ludd.ltu.se/

Meanwhile Apple hung back at gcc 4.2.1 (the last GPLv2 release) and funded 
work on LLVM/CLANG to form their new official compiler:

  http://clang.llvm.org/

Other people are working on others.  This one has a google summer of code 
project coming up:

  http://www.open64.net/

Tinycc turned into a windows-only project for a while but the Debian guys have 
recently started attacking it...  And so on.

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Ok, it works. (Was Re: powerpc NPTL port)

[Rob Landley]

Had to switch on several more things in your config to make the native 
toolchain and busybox happy, but it built and ran.  And the native toolchain 
in the system image built and ran a threaded test program (/usr/src/thread-
hello2.c), which seemed to work ok.

You can download tarballs of the binaries I built from here:

  http://landley.net/code/aboriginal/downloads/snapshots/

See http://landley.net/code/aboriginal/downloads/binaries/README for docs on 
what those tarballs are for if it's non-obvious...

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Ok, it works. (Was Re: powerpc NPTL port)

[Rob Landley]

On Tuesday 11 May 2010 10:30:08 Khem Raj wrote:
 On (11/05/10 01:29), Rob Landley wrote:
  Had to switch on several more things in your config to make the native
  toolchain and busybox happy, but it built and ran.  And the native
  toolchain in the system image built and ran a threaded test program
  (/usr/src/thread- hello2.c), which seemed to work ok.

 cool. now you have the native build environment. Can you give a shot at
 running uclibc tests too. make -k check UCLIBC_ONLY=1

I can, but you can too.  It's just an emulator. :)

1) Install qemu-system-ppc (if you think you should already have it, but 
don't, see http://impactlinux.com/fwl/FAQ.html#ubuntu_mispackaged_qemu for a 
rant about Ubuntu being weird).

2) download and extract the system image, cd into the resulting directory.

3) run ./dev-environment.sh.

(I might get around to poking at the test suite tonight, but in the meantime I 
have day job stuff to do...)

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: 1.0 release?

[Rob Landley]

On Monday 10 May 2010 06:22:07 Bernhard Reutner-Fischer wrote:
 On Sun, May 09, 2010 at 10:51:53PM -0700, Khem Raj wrote:
 On (10/05/10 00:02), Rob Landley wrote:
  So now that NPTL is in, it sounds like the next release should be either
  1.0 or 1.0-pre.  It is more or less feature complete, isn't it?
 
 yeah I have mentioned it on IRC couple of times to have next release be
  1.0

 the nptl addition would warrant bumping the version to 0.10.0, yes.
 I don't think messing around with the major version and thus
 UCLIBC_DYNAMIC_LINKER is justified for mere cosmetic numbers.

Since when does being libc.so.0 have anything to do with the C library's 
version number?

$ ls -l /lib/libc.so.6
lrwxrwxrwx 1 root root 11 2009-09-28 00:56 /lib/libc.so.6 - libc-2.9.so

I.E. my crufty old ubuntu 9.04 laptop is using version 2.9 of libc6.  The 6 
and the 2.9 are unrelated.  libc5 vs libc6 were two completely different C 
library implementations.  In that context, uClibc is libc0.  That isn't a 
version number, that's as a replacement for the OSABI field in the Elf header 
(e_ident byte 7), because libc5 and libc6 needed to expose the difference at 
the path level to coexist on the same system, and thus couldn't use the ELF 
fields in the file for this.

In that context, we're libc0, and we can be version 1.0 of libc0 just like 
glibc is version 2.9 of libc6.

Going 0.10.0 is just silly.  1.0 means the project is feature complete, and 
can be used as a replacement for glibc.  That appears to be the case.  (It's 
actually been the case since 0.9.26, we're overdue.  Busybox had its 1.0 
release 5 years ago.  Does that mean it ran out of stuff to do?  No, it means 
it's not a toy anymore and we think you should be able to _use_ it.)

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: powerpc NPTL port

[Rob Landley]

On Saturday 08 May 2010 20:06:39 Khem Raj wrote:
 On (08/05/10 19:40), Rob Landley wrote:
And this time it died with:
   
  HOSTCC utils/getconf.host
../utils/getconf.c:1025: error: '_SC_V7_ILP32_OFF32' undeclared here
(not in a function)
../utils/getconf.c:1026: error: '_SC_V7_ILP32_OFFBIG' undeclared here
(not in a function)
../utils/getconf.c:1027: error: '_SC_V7_LP64_OFF64' undeclared here
(not in a function)
../utils/getconf.c:1028: error: '_SC_V7_LPBIG_OFFBIG' undeclared here
(not in a function)
../utils/getconf.c: In function 'main':
../utils/getconf.c:1130: error: 'GETCONF_DIR' undeclared (first use
in this function)
../utils/getconf.c:1130: error: (Each undeclared identifier is
reported only once
../utils/getconf.c:1130: error: for each function it appears in.)
../utils/getconf.c:1130: warning: pointer type mismatch in
conditional expression
../utils/getconf.c:1157: warning: implicit declaration of function
'mempcpy' ../utils/getconf.c:1157: warning: incompatible implicit
declaration of built- in function 'mempcpy'
../utils/getconf.c:1220: warning: incompatible implicit declaration
of built- in function 'mempcpy'
make[1]: *** [../utils/getconf.host] Error 1
make: *** [hostutils] Error 2
   
Any ideas?
  
   you need to have libc6-dev installed on your build box.
 
  It is:
 
  aptiland...@driftwood:~/firmware/firmware$ aptitude show libc6-dev
  Package: libc6-dev
  State: installed

 seems definitely something is missing on your build machine. I have
 kubuntu 10.04 and builds fine. You can
 disable building hostutils for now to workaround.

*shrug*  0.9.31 built fine.

I just checked my headers and confirmed that /usr/include/bits/confname.h 
includes _SC_V6_ILP32_OFF32 and friends, but doesn't include 
_SC_V7_ILP32_OFF32 and friends.

Lines 681 through 748 carefully #ifdef all the V7 stuff, but lines 1015 through 
1030 don't test anything, just fail if it's not there.  So you've modified 
uClibc so that it no longer builds under a 13 month old release of the most 
popular Linux distro.  Presumably this means it doesn't build under the 
previous LTS version either.

Hmmm, when I do git log utils/getconf.c all I get was Bernhard moving it 
from somewhere else on April 6.

(I hate git.  I really hate git.  The UI is horrendous.  Even with -v it won't 
tell me the names of hte files that were involved in the commit.  There's no 
obvious way to get it to follow renames.  Yes, I added -M and it still 
didn't.  Right, it wanted --follow.  And it's _STILL not showing me the names 
of the files...)

Anyway:

commit 0aee3966d647af55231db535b61553531f64d02e
Author: Bernhard Reutner-Fischer rep.dot@gmail.com
Date:   Wed Nov 25 15:56:28 2009 +0100

sync confname, environments with glibc

Plus related synch.
Add a testcase for the sysconf variables based on the one from glibc

Signed-off-by: Bernhard Reutner-Fischer rep.dot@gmail.com

Didn't this used to be a very small, very simple shell script?  What's the 
point of having uClibc at all if it's going to copy gnu bloat verbatim?

 Then if you can preprocess the getconf.c(for host build)
 and paste somewhere I can have
 a look

Attached.

 Thx
 -Khem

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds


getconf.out.gz
Description: GNU Zip compressed data
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: powerpc NPTL port

[Rob Landley]

On Saturday 08 May 2010 20:20:27 Khem Raj wrote:
And this time it died with:
   
  HOSTCC utils/getconf.host
../utils/getconf.c:1025: error: '_SC_V7_ILP32_OFF32' undeclared here
(not in a function)
../utils/getconf.c:1026: error: '_SC_V7_ILP32_OFFBIG' undeclared here
(not in a function)
../utils/getconf.c:1027: error: '_SC_V7_LP64_OFF64' undeclared here
(not in a function)
../utils/getconf.c:1028: error: '_SC_V7_LPBIG_OFFBIG' undeclared here
(not in a function)

 I dont get the above errors.

../utils/getconf.c: In function 'main':
../utils/getconf.c:1130: error: 'GETCONF_DIR' undeclared (first use
in this function)

 This one I do get and I fixed it you can try the patch here
 http://uclibc.org/~kraj/0001-utils-Makefile.in-Define-GETCONF_DIR-for-host-
builds.patch

I switched the utils build off for the moment.  I can try that again later.

Sanity test: building Hello World.
/home/landley/firmware/temp/aboriginal/build/simple-cross-compiler-
powerpc/lib/../powerpc-unknown-linux/bin/ld: cannot find /lib//libc.so.0
collect2: ld returned 1 exit status

Your .config has HARDWIRED_ABSPATH switched on, meaning its linker scripts 
assume the libraries have already been installed into a specific location on 
the host at build time, which isn't something I want to do when cross 
compiling...  So, switching that off in the .config and rebuilding...

powerpc-cc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -O2 --static -o 
size size.o bucomm.o version.o filemode.o  ../bfd/.libs/libbfd.a 
../libiberty/libiberty.a -lm
bucomm.o: In function `make_tempname':
bucomm.c:(.text+0x200): undefined reference to `mktemp'
bucomm.c:(.text+0x24c): undefined reference to `mktemp'
collect2: ld returned 1 exit status

That's where it died next.

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: powerpc NPTL port

[Rob Landley]

On Sunday 09 May 2010 13:30:58 Khem Raj wrote:
 On (09/05/10 11:45), Rob Landley wrote:
  On Saturday 08 May 2010 20:20:27 Khem Raj wrote:
  And this time it died with:
 
HOSTCC utils/getconf.host
  ../utils/getconf.c:1025: error: '_SC_V7_ILP32_OFF32' undeclared
  here (not in a function)
  ../utils/getconf.c:1026: error: '_SC_V7_ILP32_OFFBIG' undeclared
  here (not in a function)
  ../utils/getconf.c:1027: error: '_SC_V7_LP64_OFF64' undeclared
  here (not in a function)
  ../utils/getconf.c:1028: error: '_SC_V7_LPBIG_OFFBIG' undeclared
  here (not in a function)
  
   I dont get the above errors.
  
  ../utils/getconf.c: In function 'main':
  ../utils/getconf.c:1130: error: 'GETCONF_DIR' undeclared (first
  use in this function)
  
   This one I do get and I fixed it you can try the patch here
   http://uclibc.org/~kraj/0001-utils-Makefile.in-Define-GETCONF_DIR-for-h
  ost- builds.patch
 
  I switched the utils build off for the moment.  I can try that again
  later.

 ok

  Sanity test: building Hello World.
  /home/landley/firmware/temp/aboriginal/build/simple-cross-compiler-
  powerpc/lib/../powerpc-unknown-linux/bin/ld: cannot find /lib//libc.so.0
  collect2: ld returned 1 exit status
 
  Your .config has HARDWIRED_ABSPATH switched on, meaning its linker
  scripts assume the libraries have already been installed into a specific
  location on the host at build time, which isn't something I want to do
  when cross compiling...  So, switching that off in the .config and
  rebuilding...
 
  powerpc-cc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -O2 --static
  -o size size.o bucomm.o version.o filemode.o  ../bfd/.libs/libbfd.a
  ../libiberty/libiberty.a -lm
  bucomm.o: In function `make_tempname':
  bucomm.c:(.text+0x200): undefined reference to `mktemp'
  bucomm.c:(.text+0x24c): undefined reference to `mktemp'
  collect2: ld returned 1 exit status
 
  That's where it died next.

 you probably have to enable UCLIBC_SUSV3_LEGACY

  Rob
  --
  Latency is more important than throughput. It's that simple. - Linus
  Torvalds

It built with CPUS=1, but when I took that out and it autodetected an SMP 
build (it does real CPUs *1.5, thus make -j 3 in this case), the build died 
with:

  CC libpthread/nptl/sysdeps/unix/sysv/linux/gen_lowlevelbarrier.s
In file included from ./include/sys/syscall.h:24,
 from ./libc/sysdeps/linux/common/sysdep.h:20,
 from ./libc/sysdeps/linux/powerpc/sysdep.h:19,
 from libpthread/nptl/sysdeps/powerpc/tcb-offsets.c:1:
./include/features.h:187:33: error: bits/uClibc_config.h: No such file or 
directory
In file included from ./include/sched.h:23,
 from 
libpthread/nptl/sysdeps/unix/sysv/linux/gen_lowlevelbarrier.c:2:
./include/features.h:187:33: error: bits/uClibc_config.h: No such file or 
directory
make: *** [libpthread/nptl/sysdeps/unix/sysv/linux/gen_lowlevelbarrier.s] 
Error 1
make: *** Waiting for unfinished jobs
In file included from ./libpthread/nptl/sysdeps/pthread/pthread.h:34,
 from 
./libpthread/nptl/sysdeps/powerpc/../../../nptl_db/thread_db.h:26,
 from ./libpthread/nptl/sysdeps/powerpc/../../descr.h:32,
 from ./libpthread/nptl/sysdeps/powerpc/tls.h:71,
 from ./include/tls.h:6,
 from libpthread/nptl/sysdeps/powerpc/tcb-offsets.c:2:
./libc/sysdeps/linux/common/bits/uClibc_pthread.h:36: error: expected 
identifier or '(' before 'void'
./libc/sysdeps/linux/common/bits/uClibc_pthread.h:36: error: expected ')' 
before numeric constant
./libc/sysdeps/linux/common/bits/uClibc_pthread.h:39: error: expected 
identifier or '(' before 'void'
./libc/sysdeps/linux/common/bits/uClibc_pthread.h:39: error: expected ')' 
before numeric constant
./libc/sysdeps/linux/common/bits/uClibc_pthread.h:40: error: expected 
identifier or '(' before 'void'
./libc/sysdeps/linux/common/bits/uClibc_pthread.h:40: error: expected ')' 
before numeric constant
./libc/sysdeps/linux/common/bits/uClibc_pthread.h:41: error: expected 
identifier or '(' before 'void'
./libc/sysdeps/linux/common/bits/uClibc_pthread.h:41: error: expected ')' 
before numeric constant
In file included from ./libpthread/nptl/sysdeps/pthread/pthread.h:34,
 from 
./libpthread/nptl/sysdeps/powerpc/../../../nptl_db/thread_db.h:26,
 from ./libpthread/nptl/sysdeps/powerpc/../../descr.h:32,
 from ./libpthread/nptl/sysdeps/powerpc/tls.h:71,
 from ./include/tls.h:6,
 from libpthread/nptl/sysdeps/powerpc/tcb-offsets.c:2:
./libc/sysdeps/linux/common/bits/uClibc_pthread.h:44:42: error: macro 
_pthread_cleanup_push_defer passed 3 arguments, but takes just 1
./libc/sysdeps/linux/common/bits/uClibc_pthread.h:47:16: error: macro 
_pthread_cleanup_pop_restore passed 2 arguments, but takes just 1
In file included from ./libpthread/nptl/sysdeps/powerpc/tls.h:71

1.0 release?

[Rob Landley]

So now that NPTL is in, it sounds like the next release should be either 1.0 
or 1.0-pre.  It is more or less feature complete, isn't it?

It also sounds like a stable ABI for uClibc pretty much isn't in the cards, 
because when you change the uClibc .config you change the ABI.  Also, there's 
nothing magical about the 1.0 release that'll stop people from wanting to 
switch to new kernel APIs and coming up with more efficient layouts for 
structures in response to that sort of thing...

I'd also like to remind people of the awesome video:

  http://video.google.com/videoplay?docid=-5503858974016723264

April 19, 2007 Release Management in Large Free Software Projects - Martin 
Michlmayr (Debian)

ABSTRACT: Time based releases are made according to a specific time interval, 
instead of making a release when a particular functionality or set of features 
have been implemented. This talk argues that time based release management 
acts as an effective coordination mechanism in large volunteer projects and 
shows examples from seven projects that have moved to time based releases: 
Debian, GCC, GNOME, Linux, OpenOffice, Plone, and X.org.

Just thought I'd mention that...
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH] fcntl.h: add hack to kill fcntl64 on x86_64

[Rob Landley]

On Monday 26 April 2010 13:43:45 Bernhard Reutner-Fischer wrote:
 Special-coding x86_64 is unacceptable. I have a proposed patch pending for
 0.9.31ff, will CFT ASAP.

Did this ever happen?  (A 0.9.31.1 that fixes this would be really nice...)

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds

___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: Trying to cross compile with uClibc, no sucess!

[Rob Landley]

On Tuesday 04 May 2010 09:00:13 Takaite Takehara wrote:
Hi guys;
I'm quite sure that somebody already ask this, but I could not find in
the mail list search.
I'll work with a MIPS platform and want to use uClibc. To improve my
development, I want to test in my PC and then cross-compile to MIPS and
test again.

I've got prebuilt binary cross compilers and system images here:

  http://impactlinux.com/fwl/downloads/binaries

That includes got tarballs there supporting i686, x86_64, and mips targets.

The cross-compiler tarballs are statically linked to run on i686 hosts (which 
includes x86-64).  They even support uClibc++, so you can build c++ stuff if 
you like.

The system-image tarballs provide virtual development systems you boot under 
QEMU to do native development within.  (Obviously, you need to install QEMU to 
do that.)   Extract that and run the ./run-emulator.sh script in there to boot 
a virtual Linux system.

The ./dev-environment.sh script is a wrapper around run-emulator.sh that sets 
up a more full-featured development environment.  For one thing, it creates a 
2 gigabyte /dev/hdb image mounted on /home inside the emulator, so you have 
plenty of writeable scratch space to build in.  For another, if you install 
distccd on your host and add the appropraite cross compiler's /bin 
subdirectory to your host's $PATH, dev-environment.sh detects this and will 
automatically configure the emulated target system to call out to that cross 
compiler via distcc.  (This speeds up your builds but still avoids having to 
think about cross compiling in your build.  It acts fully native, it just 
builds about 7 times faster.)

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: powerpc NPTL port

[Rob Landley]

On Saturday 08 May 2010 18:15:42 Khem Raj wrote:
 On (08/05/10 17:36), Rob Landley wrote:
  # Plug in your .config
 
  wget http://uclibc.org/~kraj/config.nptl.ppc \
-O sources/targets/powerpc/miniconfig-alt-uClibc
 
  And it went:
 
  --2010-05-08 17:32:07--  http://uclibc.org/~kraj/config.nptl.ppc
  Resolving uclibc.org... 140.211.167.224
  Connecting to uclibc.org|140.211.167.224|:80... connected.
  HTTP request sent, awaiting response... 403 Forbidden
  2010-05-08 17:32:07 ERROR 403: Forbidden.
 
  Wanna fix that?

 hmmm permission problem. Fixed now. Retry please.

Yup.

  In theory the next steps would be:
 
  USE_UNSTABLE=uClibc ./build.sh powerpc
  cd build/system-image-powerpc
  ./run-emulator.sh
 
  And that should boot up a virtual powerpc system under QEMU using the
  snapshot of the current -git version, with your patches.  And there would
  be a native development toolchain in there that builds stuff against
  current -git, too.

 cool stuff. Let me know how it goes.

  CC libpthread/nptl/sysdeps/powerpc/tcb-offsets.s
cc1: error: unrecognized command line option -Wold-style-declaration
make: *** [libpthread/nptl/sysdeps/powerpc/tcb-offsets.s] Error 1

Doesn't like gcc 4.2.1 looks like.  (The last GPLv2 release, I haven't moved 
to an alternative yet.)

Commenting out that line...

And this time it died with:

  HOSTCC utils/getconf.host
../utils/getconf.c:1025: error: '_SC_V7_ILP32_OFF32' undeclared here (not in a 
function)
../utils/getconf.c:1026: error: '_SC_V7_ILP32_OFFBIG' undeclared here (not in 
a function)
../utils/getconf.c:1027: error: '_SC_V7_LP64_OFF64' undeclared here (not in a 
function)
../utils/getconf.c:1028: error: '_SC_V7_LPBIG_OFFBIG' undeclared here (not in 
a function)
../utils/getconf.c: In function 'main':
../utils/getconf.c:1130: error: 'GETCONF_DIR' undeclared (first use in this 
function)
../utils/getconf.c:1130: error: (Each undeclared identifier is reported only 
once
../utils/getconf.c:1130: error: for each function it appears in.)
../utils/getconf.c:1130: warning: pointer type mismatch in conditional 
expression
../utils/getconf.c:1157: warning: implicit declaration of function 'mempcpy'
../utils/getconf.c:1157: warning: incompatible implicit declaration of built-
in function 'mempcpy'
../utils/getconf.c:1220: warning: incompatible implicit declaration of built-
in function 'mempcpy'
make[1]: *** [../utils/getconf.host] Error 1
make: *** [hostutils] Error 2

Any ideas?

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: powerpc NPTL port

[Rob Landley]

On Saturday 08 May 2010 19:30:30 Khem Raj wrote:
 On (08/05/10 19:13), Rob Landley wrote:
  On Saturday 08 May 2010 18:15:42 Khem Raj wrote:
   On (08/05/10 17:36), Rob Landley wrote:
# Plug in your .config
   
wget http://uclibc.org/~kraj/config.nptl.ppc \
  -O sources/targets/powerpc/miniconfig-alt-uClibc
   
And it went:
   
--2010-05-08 17:32:07--  http://uclibc.org/~kraj/config.nptl.ppc
Resolving uclibc.org... 140.211.167.224
Connecting to uclibc.org|140.211.167.224|:80... connected.
HTTP request sent, awaiting response... 403 Forbidden
2010-05-08 17:32:07 ERROR 403: Forbidden.
   
Wanna fix that?
  
   hmmm permission problem. Fixed now. Retry please.
 
  Yup.
 
In theory the next steps would be:
   
USE_UNSTABLE=uClibc ./build.sh powerpc
cd build/system-image-powerpc
./run-emulator.sh
   
And that should boot up a virtual powerpc system under QEMU using the
snapshot of the current -git version, with your patches.  And there
would be a native development toolchain in there that builds stuff
against current -git, too.
  
   cool stuff. Let me know how it goes.
 
CC libpthread/nptl/sysdeps/powerpc/tcb-offsets.s
  cc1: error: unrecognized command line option -Wold-style-declaration
  make: *** [libpthread/nptl/sysdeps/powerpc/tcb-offsets.s] Error 1
 
  Doesn't like gcc 4.2.1 looks like.  (The last GPLv2 release, I haven't
  moved to an alternative yet.)
 
  Commenting out that line...
 
  And this time it died with:
 
HOSTCC utils/getconf.host
  ../utils/getconf.c:1025: error: '_SC_V7_ILP32_OFF32' undeclared here (not
  in a function)
  ../utils/getconf.c:1026: error: '_SC_V7_ILP32_OFFBIG' undeclared here
  (not in a function)
  ../utils/getconf.c:1027: error: '_SC_V7_LP64_OFF64' undeclared here (not
  in a function)
  ../utils/getconf.c:1028: error: '_SC_V7_LPBIG_OFFBIG' undeclared here
  (not in a function)
  ../utils/getconf.c: In function 'main':
  ../utils/getconf.c:1130: error: 'GETCONF_DIR' undeclared (first use in
  this function)
  ../utils/getconf.c:1130: error: (Each undeclared identifier is reported
  only once
  ../utils/getconf.c:1130: error: for each function it appears in.)
  ../utils/getconf.c:1130: warning: pointer type mismatch in conditional
  expression
  ../utils/getconf.c:1157: warning: implicit declaration of function
  'mempcpy' ../utils/getconf.c:1157: warning: incompatible implicit
  declaration of built- in function 'mempcpy'
  ../utils/getconf.c:1220: warning: incompatible implicit declaration of
  built- in function 'mempcpy'
  make[1]: *** [../utils/getconf.host] Error 1
  make: *** [hostutils] Error 2
 
  Any ideas?

 you need to have libc6-dev installed on your build box.

It is:

aptiland...@driftwood:~/firmware/firmware$ aptitude show libc6-dev
Package: libc6-dev
State: installed
Automatically installed: no
Version: 2.9-4ubuntu6.1
Priority: optional
Section: libdevel
Maintainer: Ubuntu Core developers ubuntu-devel-disc...@lists.ubuntu.com
Uncompressed Size: 11.7M
Depends: libc6 (= 2.9-4ubuntu6.1), linux-libc-dev
Recommends: gcc | c-compiler
Suggests: glibc-doc, manpages-dev
Conflicts: libstdc++2.10-dev ( 1:2.95.2-15), gcc-2.95 ( 1:2.95.3-8), binutils
   ( 2.17cvs20070426-1), libc-dev
Replaces: man-db (= 2.3.10-41), gettext (= 0.10.26-1), ppp (= 2.2.0f-24),
  libgdbmg1-dev (= 1.7.3-24)
Provides: libc-dev
Description: GNU C Library: Development Libraries and Header Files
 Contains the symlinks, headers, and object files needed to compile and link
 programs which use the standard C library.

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH] nptl: proper soname handling

[Rob Landley]

On Sunday 02 May 2010 14:23:29 Timo Teräs wrote:
 Rob Landley wrote:
  You're saying you want to support having two installations of uClibc the
  same system.  Starting from separate dynamic linkers, and going through
  segregated library search paths.  Because nothing says lightweight and
  embedded like installing two or three complete copies of your entire
  library search path side by side.
 
  What are you going to do about things like X11's libraries?  Build that
  twice too?  Along with zlib and openssl and whatever else the system
  needs? (Because it seems like you'd have to; how is shared library code
  calling into libc any different than an executable calling into libc? 
  Either you have a stable ABI with glue code and a collection of
  version-annotated obsolete symbols to bind against, or you don't.  When
  sizeof(sigset_t) changes, or you flip a config switch like
  UCLIBC_HAS_COMPAT_RES_STATE or
  UCLIBC_HAS_TM_EXTENSIONS or ipv6 or internationalization support...  Well
  libSDL.so depends on libc (and librt, libpthread, libm...) just as much
  as /bin/ls does.
 
  It sonds like you're inviting users to experience the joy of _subtle_
  bugs caused by library version skew.  (And, of course, to post them to
  this mailing list...)
 
  Why are we opening this can of worms again?  I missed a curve...

 No, the idea is not to have two versions installed all the time. The idea
 is to allow the coexistance temporarily while package manager is upgrading
 system.

Isn't this what static linking is for?

 If we targeted flashable upgrade, then this would not be needed as
 everything would be updated in one go.

 If stuff is upgraded package at time, where libc is in one packages, and
 e.g. busybox in separate package, we do need temporarily to have two
 libc's if the ABI is incompatible. Otherwise the package manager would
 have to have lots of extra kludge for libc upgrade.

Or the package manager would have to be statically linked?  (Yeah there's some 
implementation details making sure the stuff it calls during its operation 
still works, too, changing the $PATH to point to a static busybox covers a 
multitude of sins...)

 After full dist upgrade
 the old libc should be gone, and new in place. But temporarily it needs to
 work so e.g. perl/bb/shells/whatever works while their libc is mismatching.

 And yes, it's not full solution. Deep library wise dependencies can be
 temporarily broken. And yes, we do need stable API for uclibc at some
 point. But since we don't have that yet, the temporary install of two
 libraries during upgrade is the best option.

Or you could just statically link the package manager?

 As conclusion was previously, it does not make sense to set ABI_VERSION
 due to gcc dynamic-linker issues. But it'll help distro which tries to
 keep compatibility on packages level (sets the dependencies right and
 wants to perform clean upgrades).

*shrug*

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH] nptl: proper soname handling

[Rob Landley]

On Friday 23 April 2010 09:29:10 Austin Foxley wrote:
  Since it seems that ld.so soname is hardcoded in GCC. If you want to
  use something else than /lib/ld-uClibc.so.0 as dynamic linker, you also
  need to update GCC default configration, create alternate specfile
  overriding the hardcoded -dynamic-linker, or pass-in
  -Wl,-dynamic-linker,...
  when compiling.

 Hmm, I didn't realize GCC hardcoded that. I'll push a fix.

What does pushing a fix mean in this context?

ELF requires hardcoding an absolute path to the dynamic linker, because the 
kernel calls it directly and putting a search path in the kernel would be 
policy in kernel space.  So the compiler _has_ to put a hardcoded path in 
there, all you can do is change which one.  There are a number of ways to do 
that (command line options, gcc spec file, environment variables...)  The one I 
use is an updated version of the old uClibc wrapper script from 2005, which I 
maintain for my own use.  (Attached.)

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds
/* vi: set ts=4 :*/
/*
 * Copyright (C) 2000 Manuel Novoa III
 * Copyright (C) 2002-2003 Erik Andersen
 * Copyright (C) 2006-2010 Rob Landley r...@landley.net
 *
 * Wrapper to use make a C compiler relocatable.
 *
 * Licensed under GPLv2.
 */

// No, we don't need to check the return value from asprintf().

#undef _FORTIFY_SOURCE

#define _GNU_SOURCE
#include alloca.h
#include stdio.h
#include stdlib.h
#include stdarg.h
#include string.h
#include strings.h
#include unistd.h
#include errno.h
#include sys/stat.h
#include sys/wait.h

static char *topdir;
static char nostdinc[] = -nostdinc;
static char nostartfiles[] = -nostartfiles;
static char nodefaultlibs[] = -nodefaultlibs;
static char nostdlib[] = -nostdlib;

// For C++
static char nostdinc_plus[] = -nostdinc++;

// gcc 4.3 generates tons of spurious warnings which you can't shut off.

#define xasprintf(...) do {(void)asprintf(__VA_ARGS__);} while(0)

// Confirm that a regular file exists, and (optionally) has the executable bit.
int is_file(char *filename, int has_exe)
{
	// Confirm it has the executable bit set, if necessary.
	if (!has_exe || !access(filename, X_OK)) {
		struct stat st;

		// Confirm it exists and is not a directory.
		if (!stat(filename, st)  S_ISREG(st.st_mode)) return 1;
	}
	return 0;
}

// Find an executable in a colon-separated path

char *find_in_path(char *path, char *filename, int has_exe)
{
	// Don't segfault if $PATH wasn't exported
	if (!path) return 0;

	char *cwd = getcwd(NULL, 0);

	if (index(filename, '/')  is_file(filename, has_exe))
		return realpath(filename, NULL);

	for (;;) {
		char *str, *next = path ? index(path, ':') : NULL;
		int len = next ? next-path : strlen(path);

		// The +3 is a corner case: if strlen(filename) is 1, make sure we
		// have enough space to append .. to make topdir.
		str = malloc(strlen(filename) + (len ? len : strlen(cwd)) + 3);
		if (!len) sprintf(str, %s/%s, cwd, filename);
		else {
			char *str2 = str;

			strncpy(str, path, len);
			str2 = str+len;
			*(str2++) = '/';
			strcpy(str2, filename);
		}

		// If it's not a directory, return it.
		if (is_file(str, has_exe)) {
			char *s = realpath(str, NULL);
			free(str);
			return s;
		} else free(str);

		if (!next) break;
		path += len;
		path++;
	}
	free(cwd);

	return NULL;
}

int main(int argc, char **argv)
{
	int linking = 1, use_static_linking = 0, use_shared_libgcc;
	int use_stdinc = 1, use_start = 1, use_stdlib = 1, use_shared = 0;
	int source_count = 0, verbose = 0;
	int i, argcnt, liblen, lplen;
	char **cc_argv, **libraries, **libpath;
	char *dlstr, *devprefix;
	char *cc, *toolprefix;
	char *debug_wrapper=getenv(CCWRAP_DEBUG);

	// For C++

	char *cpp = NULL;
	int prefixlen, ctor_dtor = 1, use_nostdinc_plus = 0;

	// For profiling
	int profile = 0;

	if(debug_wrapper) {
		fprintf(stderr,incoming: );
		for(cc_argv=argv;*cc_argv;cc_argv++)
			fprintf(stderr,%s ,*cc_argv);
		fprintf(stderr,\n\n);
	}

	// Allocate space for new command line
	cc_argv = alloca(sizeof(char*) * (argc + 128));

	// What directory is the wrapper script in?
	if(!(topdir = find_in_path(getenv(PATH), argv[0], 1))) {
		fprintf(stderr, can't find %s in $PATH (did you export it?)\n, argv[0]);
		exit(1);
	} else {
		char *path = getenv(PATH), *temp;

		// Add that directory to the start of $PATH.  (Better safe than sorry.)
		*rindex(topdir,'/') = 0;
		temp = malloc(5+strlen(topdir)+1+strlen(topdir)+14+strlen(path)+1);
		sprintf(temp,PATH=%s:%s/../tools/bin:%s,topdir,topdir,path);
		putenv(temp);

		// The directory above the wrapper script should have include, cc,
		// and lib directories.  However, the script could have a symlink
		// pointing to its directory (ala /bin - /usr/bin), so append ..
		// instead of trucating the path.
		strcat(topdir,/..);
	}

	// What's the name of the C compiler we're wrapping?  (It may have a
	// cross-prefix.)
	cc = getenv(CCWRAP_CC);
	if (!cc) cc = rawcc;

	// Check end of name

Re: [PATCH] nptl: proper soname handling

[Rob Landley]

On Friday 23 April 2010 10:08:42 Timo Teräs wrote:
 Austin Foxley wrote:
  On 04/23/2010 07:18 AM, Timo Teräs wrote:
  Austin Foxley wrote:
  On 04/20/2010 07:49 AM, Natanael Copa wrote:
  Since sublevel releases are not ABI compatible we need to adjust
  the soname to include the sublevel version.
 
  This makes it possible to install ABI incompatible versions of the
  library side by side so clean upgrades are possible.
 
  Applied, minus the mistaken LDFLAGS hunk
 
  It might be useful to do:
 
  -ABI_VERSION   := $(VERSION)
  +ABI_VERSION   := $(MAJOR_VERSION)
 
  Since it seems that ld.so soname is hardcoded in GCC. If you want to
  use something else than /lib/ld-uClibc.so.0 as dynamic linker, you also
  need to update GCC default configration, create alternate specfile
  overriding the hardcoded -dynamic-linker, or pass-in
  -Wl,-dynamic-linker,...
  when compiling.
 
  Hmm, I didn't realize GCC hardcoded that. I'll push a fix.

 Me neither. Actually the dynamic section is generated properly. It's
 the .interp section that goes wrong. And I didn't notice that until
 trying to run things side-by-side where ld-uClibc.so.0 and
 ld-uClibc.so.0.9.32 did not refer to same file.

So let me get this straight:

You're saying you want to support having two installations of uClibc the same 
system.  Starting from separate dynamic linkers, and going through segregated 
library search paths.  Because nothing says lightweight and embedded like 
installing two or three complete copies of your entire library search path 
side by side.

What are you going to do about things like X11's libraries?  Build that twice 
too?  Along with zlib and openssl and whatever else the system needs?  
(Because it seems like you'd have to; how is shared library code calling into 
libc any different than an executable calling into libc?  Either you have a 
stable ABI with glue code and a collection of version-annotated obsolete 
symbols to bind against, or you don't.  When sizeof(sigset_t) changes, or you 
flip a config switch like UCLIBC_HAS_COMPAT_RES_STATE or 
UCLIBC_HAS_TM_EXTENSIONS or ipv6 or internationalization support...  Well 
libSDL.so depends on libc (and librt, libpthread, libm...) just as much as 
/bin/ls does.

It sonds like you're inviting users to experience the joy of _subtle_ bugs 
caused by library version skew.  (And, of course, to post them to this mailing 
list...)

Why are we opening this can of worms again?  I missed a curve...

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: various nptl patches

[Rob Landley]

On Monday 26 April 2010 00:43:35 Timo Teräs wrote:
 Joakim Tjernlund wrote:
  So this is what I came up with. I do wonder if not linux_resolver
  need PROTECTED support too? Have you tested with LAZY relocation too?
 
  Have not tested lazy yet.
 
  The LAZY relocs is a bigger problem though. That has to work so it would
  be great if you could test that too.
 
  Hi Timo, did you get a chance to test LAZY relocs too? Now that
  NPTL is in main line it would be good to know if PROTECTED works
  as is or if more work is needed.

 Tested them now. LAZY works as expected too.

How do I test this?

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Re: [PATCH] nptl: proper soname handling

[Rob Landley]

On Thursday 22 April 2010 05:10:41 Michael Deutschmann wrote:
 On Thu, 22 Apr 2010, Natanael Copa wrote:
  Do you have any better suggestions how to upgrade a running system?

 First, build the new uClibc, but don't install it yet.

 Build a customized ld-uclibc.so.0, from the previous uClibc source, that
 looks in a different place for shared libraries and ignores the
 /etc/ld.so.* files.  Install it under a different filename.

Or just build it that way in the first place...

 Write a utility to modify the INTERP filename specified in an executable
 from /lib/ld-uclibc.so.0 to the filename of the special ld.so.  (This is
 much simpler if the temporary ld.so filename is the same length as the
 original.)

Try probably only feasible if. 

Also, note that the library paths the linker searches internally aren't 
necessarily obvious:

/* Lastly, search the standard list of paths for the library.
   This list must exactly match the list in uClibc/ldso/util/ldd.c */
_dl_if_debug_dprint(\tsearching full lib path list\n);
tpnt1 = search_for_named_library(libname, secure,
UCLIBC_RUNTIME_PREFIX lib:
UCLIBC_RUNTIME_PREFIX usr/lib
#ifndef __LDSO_CACHE_SUPPORT__
: UCLIBC_RUNTIME_PREFIX 
usr/X11R6/lib
#endif
, rpnt);

If you build with UCLIB_RUNTIME_PREFIX=/ or similar (as I tend to)...

 Hardlink the existing shared libraries into the alternate position, then
 hack every existing installed executable in this way.

Don't forget that pretty much every other shared library (zlib, ncurses, 
openssl, etc) also links against libc, so you have to move those to the 
alternate position and rebuild them too.

So every binary and every shared library in the entire filesystem essentially 
get moved to the new position.

This is usually called a chroot.

 I intend to do something like this for my 0.9.30.3 to 0.9.31 rollover,
 but I haven't finished writing the necessary utilities yet.

I look foward to hearing about the result.

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc