Modify

Opened 7 years ago

Closed 6 years ago

Last modified 4 years ago

#9483 closed defect (wontfix)

glibc support needs work

Reported by: peter@… Owned by: nico
Priority: normal Milestone: Barrier Breaker 14.07
Component: packages Version: Trunk
Keywords: Cc:

Description

This is a meta bug against issues I have seen. This applies to glibc + trunk, but I think it's also relevant to eglibc and last release.

Apologies if this should be several bugs or if I've obviously repeated bugs. That are mentioned elsewhere. I know this is far from ideal.

glibc + openwrt doesn't build because:

#7133 patches have not been applied.

The patch applied here needs applying to glibc:

http://old.nabble.com/-crosstool-ng---patch--glibc-2.9-patch-for-%22undefined-reference-to-%09%60_begin%27-td22751673.html

#8342 is still true. The Makefile explicitly references uClibc++. Something like this is required:

CONFIGURE_VARS += \

CXXFLAGS="$$$$CXXFLAGS -fno-builtin -fno-rtti -nostdinc++" \

  • CPPFLAGS="$$$$CPPFLAGS -I$(STAGING_DIR)/usr/include/uClibc++" \

+ CPPFLAGS="$$$$CPPFLAGS" \

LDFLAGS="$$$$LDFLAGS" \

  • LIBS="-nodefaultlibs -luClibc++ -lm $(LIBGCC_S)" \
  • CLIENTCLIBS="-nodefaultlibs -luClibc++ -lm $(LIBGCC_S)" \

+ LIBS="-lstdc++ -lm" \
+ CLIENTCLIBS="-nodefaultlibs -lstdc++ -lm"

Obviously the Makefile should be modified to do alternate selection of vars depending upon library, so this isn't a proper patch.

Also:

uCLibc++ is built needlessly under this configuration. If you turn it off in advanced options, you end up trying to run the command "no" later on. e.g, building libncurses.

libstdc++ is not installed into the final image.

It appears that /usr/lib is not included in standard search path in the final image, so utilities in /usr/bin cannot find their libraries. e.g.:
ldd /usr/bin/php-cli

libcrypt.so.1 => /lib/libcrypt.so.1 (0x40109000)
libz.so.1 => not found
libpcre.so.0 => not found
libm.so.6 => /lib/libm.so.6 (0x40141000)
libsqlite3.so.0 => not found
libpthread.so.0 => /lib/libpthread.so.0 (0x401e0000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x401fe000)
libc.so.6 => /lib/libc.so.6 (0x40212000)
libdl.so.2 => /lib/libdl.so.2 (0x4032f000)
/lib/ld-linux.so.3 (0x400e4000)

You can find me as "Chocky" on IRC if you have questions/abuse.

Attachments (6)

105-begin.patch (841 bytes) - added by peter@… 7 years ago.
This addressed the _start issue referred to in the mailing list post above
glibc-2_13.patch (1.3 KB) - added by peter@… 7 years ago.
Add glibc 2.13
mysql.patch (1.0 KB) - added by peter@… 7 years ago.
Hackery for mysql - not a proper fix at all
udev.p (1.1 KB) - added by peter@… 7 years ago.
hotplug2/glibc patch
010-glibc.patch (465 bytes) - added by peter@… 7 years ago.
Hackery for uclibc++ build under glibc
glibc.patch (3.9 KB) - added by Peter Naulls <peter@…> 7 years ago.

Download all attachments as: .zip

Change History (24)

comment:1 Changed 7 years ago by anonymous

Can someone apply these please? I am prepared to maintain glibc support, since there's a lot of apathy towards it (for understandable reasons), but it's really what I need, and I know I'm not the only one with interest in this.

Changed 7 years ago by peter@…

This addressed the _start issue referred to in the mailing list post above

Changed 7 years ago by peter@…

Add glibc 2.13

comment:2 Changed 7 years ago by peter@…

I have attached a simple patch to use the most recent version of glibc with a ports version - 2.13. I don't believe any patches are required against this glibc, unlike 2.7.

This addresses #9201, #7133 and #9570. I have tried this on MIPS only.

Regard the library search paths, see r27216, which addresses the matter in eglibc.

The last issue to be resolved here is uclibc++/mysql. I believe there is work in progress to address this. uclibc may get pulled into by the build, but isn't wanted in any case. I had to comment out some of the string functions to have it build.

Changed 7 years ago by peter@…

Hackery for mysql - not a proper fix at all

Changed 7 years ago by peter@…

hotplug2/glibc patch

Changed 7 years ago by peter@…

Hackery for uclibc++ build under glibc

comment:3 Changed 7 years ago by peter@…

Also, and from *2 years* ago, the patch in #5692 is required.

comment:4 Changed 7 years ago by peter@…

With libiwifo:

lua -e 'require "iwinfo"'
lua: error loading module 'iwinfo' from file '/usr/lib/lua/iwinfo.so':

/usr/lib/lua/iwinfo.so: undefined symbol: stat

This appears to be related to some stripping/optimization in glibc related to the stat function (which is a bit complex, due to support of 32 vs 64). The work around is to build libiwinfo with -O3 instead of -Os.

comment:5 Changed 7 years ago by anonymous

And libudev.h needs extern "C" wrappers in its header.

comment:6 Changed 7 years ago by peter@…

The hotplug/udev patch is no longer required. This was fixed by addition of libbsd some time ago.

As for glibc versions, I would suggest just ditching 2.6/2.7 since they are so old. I have now tested 2.13 on 3 different systems without issue, and it does not need any patches.

Changed 7 years ago by Peter Naulls <peter@…>

comment:7 Changed 7 years ago by Peter Naulls <peter@…>

This most recent patch replaces the earlier one. It puts glibc(-ports)-2.13 as the only version supported of glibc (and the only one that builds at present). There is a single patch as per eglibc which ensures /usr/lib is in the search path.

comment:8 Changed 6 years ago by nico

  • Owner changed from developers to nico
  • Status changed from new to accepted

comment:9 Changed 6 years ago by zacherystoddard@…

please do something with glibc.

Either commit to getting it working again or just give up and remove it. I have an application where I need glibc, and I'd very much like to use openwrt. Hoverer, if it is not going to be supported going forward, then I can't use openwrt...

comment:10 Changed 6 years ago by adam2104 <openwrt@…>

I also would love to have working glibc support. Unfortunately I'm not savvy enough to contribute code to the effort. There are small, embedded x86 platforms (like the atom and alix) boards that would benefit from being able to run OpenWRT and not some larger, more bloated distro, like Vyatta or even Voyage linux.

comment:11 Changed 6 years ago by peter@…

There really isn't much to contribute. The patches need to be committed and/or tidied by the OpenWrt maintainers. The code has been tested *extensively* on many platforms for most of 2011.

comment:12 Changed 6 years ago by adam2104 <openwrt@…>

Maybe I'm not following the notes above correctly. Which patches are still required? I'm attempting to build an x86 trunk build today using glibc, I'm having difficulties getting the toolchain compiled. I've already applied the last glibc.patch. Are any others required?

Also, any thought on kicking it up to glibc 2.14.1?

comment:13 Changed 6 years ago by adam2104 <openwrt@…>

I should be more clear. The toolchain was failing with glibc 2.7. I have just recently applied your above patch for 2.13. I'm waiting for the toolchain to rebuild. Sorry for any confusion.

comment:14 Changed 6 years ago by nbd

  • Resolution set to fixed
  • Status changed from accepted to closed

glibc updated in r30478

comment:15 Changed 6 years ago by peter@…

  • Resolution fixed deleted
  • Status changed from closed to reopened

toolchain/glibc-ports/Makefile remains out of date.

comment:16 Changed 6 years ago by peter@…

There is also still a fix required in package/base-files/files/lib/upgrade/common.sh:

  • install_file /etc/resolv.conf /etc/functions.sh /lib/upgrade/*.sh $RAMFS_COPY_DATA

+ install_file /etc/resolv.conf /etc/functions.sh /lib/* /lib/upgrade/*.sh $RAMFS_COPY_DATA

Unless something else addresses this.

comment:17 Changed 6 years ago by nbd

  • Resolution set to wontfix
  • Status changed from reopened to closed

wontfix for glibc (removed from trunk), eglibc 2.15 is working, including sysupgrade support

comment:18 Changed 4 years ago by jow

  • Milestone changed from Attitude Adjustment 12.09 to Barrier Breaker 14.07

Milestone Attitude Adjustment 12.09 deleted

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.