The goal of this package is to be able to compile stuff against uclibc, without too much PITA.

After build of this package, headers and libs seem to end up in /usr/{lib,include}/uClibc. Ok. How we will use them to build apps?


This is what I do at home to achieve it:
http://busybox.net/~vda/HOWTO/i486-linux-uclibc/HOWTO.txt

And here is Rob's automatic build system for uclibc toolchain for several architectures:
http://landley.net/code/firmware/

My approach (described at the URL above) basically amounts to building a separate cross-compiler for uclibc because:

(1) AFAIK, libc forms a part of the platform's ABI:

# i486-linux-uclibc-gcc -v
Using built-in specs.
Target: i486-linux-uclibc
                   ^^^^^^
$ gcc -v
Reading specs from /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/specs
                                              ^^^
(above: "gnu" basically means "glibc", I think)

and (2) it is easier to follow the same scheme for all uclibc builds, "native" and true cross-compiling ones.

But - this method will install cross-compiling gcc and cross-compiling binutils.
Not sure Fedora would want that. (Comments from the people in the know? Is it possible/acceptable for Fedora to package cross-compiling toolchains?)

I expect Fedora would rather want to use native toolchain, just coerced into using uclibc headers and libs. This is an understandable desire to reuse what we already have installed.

But this is not easy. At least I failed when I tried. Problems usually manifest as gcc and/or ld using start files and/or libs which do not exist, and do not contain some required symbols. Because native gcc/ld expect to link against glibc.

Hi Denys,

I packaged uClibc on openSUSE back in the days when I still worked at SUSE. My primary concern was to use uClibc to build static binaries of busybox and some other essentials that I needed to create a really small boot environment. 

Installing a cross-toolchain was not an option back then, I was told so. So I started by reading the mailing list about uClibc and compiling with native gcc. In the end I came up with a little script that uses gcc supplied with openSUSE and overrides all kinds of default paths to use uClibc headers and stuff.

That worked to the extend that I could compile busybox statically. I failed to get shared library support working but that wasn't my main focus. Let me attach the script so you can have a look at it. I'd be happy to get some feedback, knowing this won't be your prefered way of dealing with this ;-) This will need some tweaking for using it in Fedora of course, it's just meant to get an idea.

Thanks!
  Stefan

Created attachment 348501 [details]
gcc-uClibc

Is there a particular reason we want to ship uClibc other than 'it's there'?

The reason is to have it separated from busybox - for now busybox use it to be smaller and more optimized.

Right, but we explicitly discourage static linking, much less static linking to another C library. (I know that the busybox-anaconda package is actually dynamically linked.)

Re static linking:

busybox is a rescue package thing. It is useful when dynamic libraries are busted (think rm -rf /lib).

Also, busybox is used when it's critical to minimize the size. glibc really is not caring about code size anymore.

I don't know where exactly busybox is used in Fedora, but in above two cases people usually use statically linked busybox.


Re static linking to another C library: uclibc can be configured and built as a dynamic library. What is the Fedora policy on this? Are alternative libc's allowed?

BTW, in effect we already have two libc's on x86_64: 32-bit and 64-bit glibc have different ABIs and live in different directories.

Adding more libc's boils down to selecting a directory for them (I don't know, /lib-i[456]86-uclibc?)

> $ rpmlint ../SRPMS/uClibc-0.9.30.1-1.fc11.src.rpm 
> uClibc.src:69: E: hardcoded-library-path in $RPM_BUILD_ROOT/lib/*
> uClibc.src:70: E: hardcoded-library-path in $RPM_BUILD_ROOT/lib/
OK, these don't appear in the binary package.
> $ rpmlint ../RPMS/x86_64/uClibc-devel-0.9.30.1-1.fc11.x86_64.rpm 
> 1 packages and 0 specfiles checked; 0 errors, 0 warnings.

Blockers:
- License: should AFAICS be "LGPLv2" (no "+")
- "No debuginfo needed" is rather useless reason for disabling debuginfo.
  Perhaps "This package only contains a static library".
- Use %global instead of %define

Other requirements:
- Use %{?_smp_mflags} in (make V=1)
- All patches should have an upstream bug link or comment 

Notes:
- You can use
    %files ...
    %{_includedir}/uClibc
  instead of
    %files ...
    %dir %{_includedir}/uClibc
    %{_includedir}/uClibc/*
  (and the same for _libdir)
- Please consider setting PREFIX instead of DEVEL_PREFIX
- CFLAGS do not use %{optflags}, it probably doesn't make sense in this case
- The ExcludeArch: comment will have to be filed as a bug component creation in bugzilla
- My POV is that uClibc is a package that can be correctly packaged and made
  available to users of Fedora.
  I probably wouldn't approve a review of any other Fedora package linking
  against uClibc - both anaconda and mkinitrd link against glibc, after all.

Thanks fixed:
Spec URL: http://people.redhat.com/varekova/new/uClibc.spec
SRPM URL: http://people.redhat.com/varekova/new/uClibc-0.9.30.1-1.fc12.src.rpm

add notes 
- Please consider setting PREFIX instead of DEVEL_PREFIX
for now I leave DEVEL_PREFIX, but if you want it then I will do the change
- CFLAGS do not use %{optflags}, it probably doesn't make sense in this case
I don't think tit has a sense
-  The ExcludeArch: comment will have to be filed as a bug component creation in
bugzilla
I plan to create the bz, thanks

Thanks, but that package is missing all patches and it does not build any more.

Thanks, fixed.

OK, accepted.

I see the fedora-cvs flag was set, but there's nothing here indicating what you need to CVS folks to do.  Please see http://fedoraproject.org/wiki/CVS_admin_requests for some documentation on doing that.

New Package CVS Request
=======================
Package Name: uClibc
Short Description: C library for embedded Linux
Owners: varekova vda
Branches: F-11 devel
InitialCC: varekova

CVS done.

The package has been still not imported into CVS and built, what prevents that?

Thanks, just build in fc12.

fc11 build is done too (identical to fc12):

http://koji.fedoraproject.org/koji/buildinfo?buildID=130251