Date: Thu, 20 Aug 2015 12:21:55 +0200 From: Christian Lamparter <chunkeey@...glemail.com> To: musl@...ts.openwall.com Cc: Rich Felker <dalias@...c.org>, Bobby Bingham <koorogi@...rogi.info> Subject: Re: SuperH conflict of arch/sh/__set_thread_area vs thread/__set_thread_area On Wednesday, August 19, 2015 11:04:02 PM Rich Felker wrote: > On Thu, Aug 20, 2015 at 02:44:11AM +0200, Christian Lamparter wrote: > > Hello, > > > > I'm trying to add a port for a SH4-like ARCH to OpenWRT, which uses the latest > > musl-1.1.10 as the default libc. I'm having the following problem when building > > the toolchain: > > > > During the final linker-step, the symbol "__set_thread_area" declared twice. > > This is because the SH architecture provides a separate __set_thread_area , > > (other archs use the standard syscall wrapper from ). > > > > Obviously, I want this issue fixed. However I'm new to SuperH and musl, that's > > why I need advise :-D. For now, I defined the src/thread/__set_thread_area as > > a weak symbol. Now, that's just a crude hack, what would be better solution? > > (I can make and post the patch if necessary - But sadly, I can't test it on the > > hardware yet)? > > Bobby Bingham's reply explains what the issue is. Did you make a new > arch name rather than using the existing sh arch for your port? Initially, yes I did. I had the ARCH at "sh4". This was because OpenWRT already had infrastructure for some sh-(sub)targets (sh3, sh3eb, sh4, sh4eb) in place. But they seem to be unused and untested. The only target which has support for SuperH is UserModeLinux. However, it will probably run into the same issue. Now, I've changed ARCH to "sh" and set the CPU_TYPE to sh4 [toolchain dir changed to toolchain-sh_sh4_gcc-5.2.0_musl-1.1.10]. But still no luck, the original error code remains the same. src/thread/__set_thread_area.lo: In function `__set_thread_area': __set_thread_area.c:(.text+0x0): multiple definition of `__set_thread_area' arch/sh/src/__set_thread_area.lo:__set_thread_area.c:(.text+0x0): first defined here collect2: error: ld returned 1 exit status Makefile:142: recipe for target 'lib/libc.so' failed > If it's ABI-compatible, it would probably make more sense to use the > existing one and extend it to support your hardware. In case you want to know: Hardware is a 2013 Sat>IP set-top-box (idl4k platform) with a STx7108 (that's sh4, little endian, with mmu and with fpu). > I'm working on an sh-related project right now > (see http://0pf.org/j-core.html) and one of my goals is to get sh > more unified as a platform where it's possible to have binaries > for the baseline ISA that work on lots of different hardware models > (including nommu ones). The J4 arch is sadly 2 years ahead of time ;-) [EU4]. But I think I'll definitely need some help to figure out - Another issue seems to be that the arch string changed from sh*-linux to sh-*-linux between gcc-4.8 and gcc-5.2... So, what to do? Regards, Christian
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.