OpenWrt Forum Archive

Topic: build 64bit support for openwrt 12.09

The content of this topic has been archived on 29 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

I want add 64bit support for openwrt 12.09,but I have some trouble on it.What can I do?

I search it on google,but I found nothing useful, I also find it on OpenWrt Wiki, Then I found followed links :
wiki.openwrt.org/doc/devel/add.new.platform
[wiki.openwrt.org/doc/devel/add.new.device

So I copied Chaos Calmer config files (target/linux/x86/64)  in to build folder,and It was very smooth at the beginning.
Then the erroe occoured,seems like using the wrong toolchain, How can I do next?

Here are the Error message

sed -n "s/^.*@@@name@@@\([^@]*\)@@@value@@@[^0-9Xxa-fA-F-]*\([0-9Xxa-fA-F-][0-9Xxa-fA-F-]*\).*@@@end@@@.*\$/#define \1 \2/p" libpthread/nptl/sysdeps/unix/sysv/linux/gen_unwindbuf.s > libpthread/nptl/sysdeps/unix/sysv/linux/unwindbuf.h
awk -f ./extra/scripts/gen-as-const.awk libpthread/nptl/sysdeps/x86_64/tcb-offsets.sym > libpthread/nptl/sysdeps/x86_64/gen_tcb-offsets.c
i486-openwrt-linux-uclibc-gcc -c libpthread/nptl/sysdeps/x86_64/gen_tcb-offsets.c -o libpthread/nptl/sysdeps/x86_64/gen_tcb-offsets.s -include ./include/libc-symbols.h -Wall -Wstrict-prototypes -Wstrict-aliasing -O2 -pipe -march=athlon64 -fno-caller-saves -fhonour-copts -Wno-error=unused-but-set-variable -fno-stack-protector -nostdinc -I./include -I./include -I. -I./libc/sysdeps/linux -I./libc/sysdeps/linux/x86_64  -Os -funit-at-a-time -fmerge-all-constants -fstrict-aliasing -fno-tree-loop-optimize -fno-tree-dominator-opts -fno-strength-reduce -I./libpthread/nptl -I./libpthread/nptl -I./libpthread/nptl/sysdeps/unix/sysv/linux/x86_64/ -I./libpthread/nptl/sysdeps/unix/sysv/linux/x86_64 -I./libpthread/nptl/sysdeps/x86_64 -I./libpthread/nptl/sysdeps/x86_64 -I./libpthread/nptl/sysdeps/unix/sysv/linux -I./libpthread/nptl/sysdeps/unix/sysv/linux -I./libpthread/nptl/sysdeps/pthread -I./libpthread/nptl/sysdeps/pthread/bits -I./libpthread/nptl/sysdeps/generic -I./ldso/ldso/x86_64 -I./ldso/include -I./libc/sysdeps/linux/common -I/home/user/openwrt/build_dir/toolchain-i386_gcc-4.6-linaro_uClibc-0.9.33.2/linux-dev/include/ -isystem /home/user/openwrt/staging_dir/toolchain-i386_gcc-4.6-linaro_uClibc-0.9.33.2/lib/gcc/i486-openwrt-linux-uclibc/4.6.3/include-fixed -isystem /home/user/openwrt/staging_dir/toolchain-i386_gcc-4.6-linaro_uClibc-0.9.33.2/lib/gcc/i486-openwrt-linux-uclibc/4.6.3/include -DNDEBUG -D__USE_STDIO_FUTEXES__    -S  -MT libpthread/nptl/sysdeps/x86_64/gen_tcb-offsets.s -MD -MP -MF libpthread/nptl/sysdeps/x86_64/.gen_tcb-offsets.s.dep
libpthread/nptl/sysdeps/x86_64/gen_tcb-offsets.c: In function 'dummy':
libpthread/nptl/sysdeps/x86_64/gen_tcb-offsets.c:19:79: error: 'tcbhead_t' has no member named 'rtld_savespace_sse'
make[4]: *** [libpthread/nptl/sysdeps/x86_64/gen_tcb-offsets.s] Error 1
make[4]: Leaving directory `/home/user/openwrt/build_dir/toolchain-i386_gcc-4.6-linaro_uClibc-0.9.33.2/uClibc-0.9.33.2'
make[3]: *** [/home/user/openwrt/staging_dir/toolchain-i386_gcc-4.6-linaro_uClibc-0.9.33.2/stamp/.uclibc_headers_installed] Error 2
make[3]: Leaving directory `/home/user/openwrt/toolchain/uClibc/headers'
make[2]: *** [toolchain/uClibc/headers/install] Error 2
make[2]: Leaving directory `/home/user/openwrt'
make[1]: *** [/home/user/openwrt/staging_dir/toolchain-i386_gcc-4.6-linaro_uClibc-0.9.33.2/stamp/.toolchain_install] Error 2
make[1]: Leaving directory `/home/user/openwrt'
make: *** [prepare] Error 2

Hope experts come out pointing,and I'd very appreciate that.

(Last edited by jbccjb on 18 Feb 2017, 22:08)

Why bother compiling 64 bit for an older version?

Why not use the newer version?

mys5droid wrote:

Why bother compiling 64 bit for an older version?

Why not use the newer version?

Yeah,I want use newer version too,but a lot packages,patch and source code do not support the new linux kernel,I have to fix and recompile them,that a lot job,and new version is not stable enough in production environment.

Ok, let's see if we can't solve this...

Please let me know, are you running a 64-Bit OS to compile on? I believe you require a 64-Bit OS to compile 64-Bit applications.

Regardless, I believe the following lines hint us to the solution:

make[3]: *** [/home/user/openwrt/staging_dir/toolchain-i386_gcc-4.6-linaro_uClibc-0.9.33.2/stamp/.uclibc_headers_installed] Error 2

and

make[1]: *** [/home/user/openwrt/staging_dir/toolchain-i386_gcc-4.6-linaro_uClibc-0.9.33.2/stamp/.toolchain_install] Error 2

I think you are right, you're using the wrong toolchain... It says you are using i386 when you mentioned you were compiling for 64-Bit.

I suspect you need to add the 64-Bit toolchain.

Please refer to https://wiki.openwrt.org/doc/howto/build - specifically these steps:

run make menuconfig and set "Target System", "Subtarget", "Target Profile";
run make defconfig;
run make menuconfig and modify set of package;
run scripts/diffconfig.sh >mydiffconfig (save your changes in the text file mydiffconfig);
run make V=s (build OpenWRT with console logging, you will look where build failed.).

So you start with #1. Set your target system using menuconfig. Run make menuconfig and set  "Target System", "Subtarget", "Target Profile" - Choose the 64-Bit target.

If you did this already, then you must have hardcoded the ToolChain into your ~/.bashrc - All you have to do is change it to the 64-Bit version.

Let me know if this helps any...

(Last edited by mys5droid on 22 Feb 2017, 04:55)

Thank you,That helps a lot,But what I want to say is:

First, I run a 64-Bit Ubuntu 12.04 to compile,What puzzles me is the 32bit os can compile the 64bit Openwrt 15.05 well.
Second, The openwrt 12.09 do not support 64bit target,and nothing to choice. So I have to change the source code, Makefile or compile config.

Now the question is how to edit config or makefile to build the right Toolchain.

mys5droid wrote:

Why bother compiling 64 bit for an older version?

Why not use the newer version?

I' m looking forward your reply.

Why do you insist on using 12.09/ Barrier Breaker? There has been a major release since that version and a second would be well overdue. Accordingly there is no support for 12.09 anymore  (and more than a handful of known security issues) - that has shifted towards 15.05/ Chaos Calmer or trunk/ Designated Driver instead.

I could understand, but personally not accept (due to the security aspect), sticking to an old version on really old routers with very limited ressources or platforms that have been dropped in the meantime, but neither of these arguments are valid for any x86_64 (nor 32 bit x86) system. Even the most embedded x86 solution has way more than 8 MB main storage and way more than 32 MB RAM. Thanks to the standardization (BIOS/ UEFI, ACPI) and millions of devices testing recent kernels on x86, there also isn't really a risk for platform regressions (which could very well be a problem for abandoned non-x86 targets) - and if there are, they'd need to (and actually can-) be fixed in current code, rather than sticking to EOLed stuff. On the contrary, it is quite questionable if modern x86_64 devices would even boot with Barrier Breaker's 3.3.8 kernel, nor if its main devices (network cards in particular) were already supported in that kernel.

This means, at least to a casual reader like me, you're trying to do something 'stupid' - using code branches no one sane has touched in at least 4 years, for which no one even knows if it's still buildable (without significant changes) at all (changed download URLs for upstream code, changes required by current host compilers, binutils, etc.). Even less considering that there apparently wasn't even a 64 bit release for barrier breaker at all, which means the whole platform support was either missing, or at least not in a state ready for releasing. Sure, it should be possible to add the missing bits and pieces, but the usual opensource mantra applies (even more so for historic/ EOLed releases), "if you break it, you get to keep the pieces".

(Last edited by slh on 23 Feb 2017, 23:11)

slh wrote:

Why do you insist on using 12.09/ Barrier Breaker? There has been a major release since that version and a second would be well overdue. Accordingly there is no support for 12.09 anymore  (and more than a handful of known security issues) - that has shifted towards 15.05/ Chaos Calmer or trunk/ Designated Driver instead.

I could understand, but personally not accept (due to the security aspect), sticking to an old version on really old routers with very limited ressources or platforms that have been dropped in the meantime, but neither of these arguments are valid for any x86_64 (nor 32 bit x86) system. Even the most embedded x86 solution has way more than 8 MB main storage and way more than 32 MB RAM. Thanks to the standardization (BIOS/ UEFI, ACPI) and millions of devices testing recent kernels on x86, there also isn't really a risk for platform regressions (which could very well be a problem for abandoned non-x86 targets) - and if there are, they'd need to (and actually can-) be fixed in current code, rather than sticking to EOLed stuff. On the contrary, it is quite questionable if modern x86_64 devices would even boot with Barrier Breaker's 3.3.8 kernel, nor if its main devices (network cards in particular) were already supported in that kernel.

This means, at least to a casual reader like me, you're trying to do something 'stupid' - using code branches no one sane has touched in at least 4 years, for which no one even knows if it's still buildable (without significant changes) at all (changed download URLs for upstream code, changes required by current host compilers, binutils, etc.). Even less considering that there apparently wasn't even a 64 bit release for barrier breaker at all, which means the whole platform support was either missing, or at least not in a state ready for releasing. Sure, it should be possible to add the missing bits and pieces, but the usual opensource mantra applies (even more so for historic/ EOLed releases), "if you break it, you get to keep the pieces".

Thank you for your attention,You're right about this,but I just want fix this problem,and I don't want to Spend a lot of time doing migration, If I need to upgrade,I' ll abandon these code and do not touch forever to building new
architecture. but now I don‘t have time to do this, Now I just want to solve the problem.

jbccjb wrote:

Thank you for your attention,You're right about this,but I just want fix this problem,and I don't want to Spend a lot of time doing migration, If I need to upgrade,I' ll abandon these code and do not touch forever to building new
architecture. but now I don‘t have time to do this, Now I just want to solve the problem.

Good to know it did compile 64 bit on 32 bit system. I am not a C programmer so I have no clue smile Good to learn new things!

So I agree with slh it is pretty stupid to use a build that hasn't been touched in years...

But I hate when you ask a question and no one tells you the answer because they think its "insecure". I believe they should be answering anyways, and making the OP aware of the security threats.

Like allowing root login, no one would answer because it's "insecure". And it is, but I don't care. My network is secured enough.

What I would suggest then:

cd into the main directory for the sdk
grep -r -i "toolchain-i386_gcc-4.6-linaro_uClibc-0.9.33.2" /

That should search all the files for the text "toolchain-i386_gcc-4.6-linaro_uClibc-0.9.33.2" and tell you which file it found it in. Idea being, it should find the lines in the makefile and the files location for you...

Then you just download the 64 bit toolchain or copy it from wherever to the same location, and change the occurances of "toolchain-i386_gcc-4.6-linaro_uClibc-0.9.33.2" to the name of the 64 bit toolchain.

I can only speculate what to try, as I have not and will not need to compile any version of OpenWRT.

Let me know if that helps you in any way...

(Last edited by mys5droid on 25 Feb 2017, 03:25)

mys5droid, in contrast to your example of bad security practices (which is entails changing one single line in a configfile[1]), however adding a new architecture/ platform to OpenWrt isn't done in 1-2-3 steps, but rather entails changes in many places (wiggling the buildsystem around, adding kernel patches and coming up with a suitable kernel config, adding defconfigs for all required targets, dealing with all the fallout with packages expecting all x86 to be 32 bit only). Even for someone who knows what he/ she is doing, this will be hard work for roundabout a weekend[2], at least - work that has already been done, just not for barrier breaker, but later releases instead (chaos calmer and later in particular). Even those who did add x86_64 platform support somewhere between 2012 and 2015 won't get a backport to barrier breaker done much faster than that, because the project as a whole and the way things are hooked up into the buildsystem has evolved since then, so forgetting the current/ modern ways and re-learning the old ways is both frustrating ("damned, it could be done so much easier today") but also time consuming.

Now you need to put all this effort into perspective with the "advantages" doing all this work for the userbase at large (which would be anyone beyond just one person, consisting of merely jbccjb):
- any device capable to run x86_64 can run chaos calmer or trunk/ designated driver with ease, so there is no hard technical need why the current code (both stable and devel) won't work on the target device in question.
- OpenWrt for 32 bit/ x86, which was already present in barrier breaker, will also work on any x86_64 device, which allows testing for potential regressions between barrier breaker and chaos calmer. This might not be the optimal solution, but it does work - yes, i386 might not run on some of the most recent UEFI-only x86_64, but kernel 3.3 won't run on those either - so barrier breaker isn't an option for those systems anyways.
- development on the barrier breaker branch has stopped years ago (roughly around the time chaos calmer was released, but it probably stalled way before that already), the branch is closed for development. This means even if someone would actually do all the work to prepare all the patches to add x86_64 support for barrier breaker, no one would even bother to commit it to the barrier breaker branch[3] - making this a rather involved "contract work" for a single person[4], but not the public at large

Requesting help for simple things is easy, you usually get some responses easily or at least some pointers to potential documentation, but the topic in questions isn't easy at all. Walking someone with no experience[5] through this in many small steps going back and forth would take even longer (if it succeeds at all) than just doing it yourself, but that isn't anything one could do in a spare minute while being bored[6], on the contrary. So expecting help of the detailed kind requested here, is quite bold and rather unlikely to happen, considering the effort required and the fact that it has already been done for the subsequent stable release. There is a reason why development for larger new features is done on the development code base, rarely backported to the last/ current stable branch and basically never to long obsoleted, EOLed, past release branches, because spending significant amounts of effort twice or more is frustrating and needs quite some reasonable justification.

[1] which one however depends on the display manager you're using - so the explanations "just" explodes to the syntax for the five major options (there are more display manager around, but lightdm, gdm2, gdm3, kdm and sddm are the most common ones).
[2] and this needs to be all completed and done in the dry, before you can even do a first test.
[3] which also takes quite some effort on the part of the committer, to review said changes at least superficially <-- this is the only place where the security aspect actually matters, because adding completely new features (and new platform support is a pretty large new feature) doesn't make the slightest sense for an EOLed branch abandoned years ago, which hasn't seen even the most trivial security support since that time.
[4] who hasn't provided the slightest reason why barrier breaker is needed, rather than just taking the current code.
[5] otherwise the question wouldn't be as generic like this one, but much more specific - ESR's essay about smart questions comes to mind.
[6] I do indeed consider two man-days (more than 16 hours) to be a reasonable estimate for someone who knows what he/ she is doing, this is not a pointless exaggeration - yes, x86_64 in general isn't much of a problem on the major general purpose desktop distributions since 2004/ 2005, but that doesn't mean it wouldn't be difficult to add a new architecture to a make-world based buildsystem like OpenWrt (don't forget the cross-compiler aspect).

(Last edited by slh on 25 Feb 2017, 04:41)

slh wrote:

mys5droid...

[1] which one however depends on the display manager you're using - so the explanations "just" explodes to the syntax for the five major options (there are more display manager around, but lightdm, gdm2, gdm3, kdm and sddm are the most common ones).
[2] and this needs to be all completed and done in the dry, before you can even do a first test.
[3] which also takes quite some effort on the part of the committer, to review said changes at least superficially <-- this is the only place where the security aspect actually matters, because adding completely new features (and new platform support is a pretty large new feature) doesn't make the slightest sense for an EOLed branch abandoned years ago, which hasn't seen even the most trivial security support since that time.
[4] who hasn't provided the slightest reason why barrier breaker is needed, rather than just taking the current code.
[5] otherwise the question wouldn't be as generic like this one, but much more specific - ESR's essay about smart questions comes to mind.
[6] I do indeed consider two man-days (more than 16 hours) to be a reasonable estimate for someone who knows what he/ she is doing, this is not a pointless exaggeration - yes, x86_64 in general isn't much of a problem on the major general purpose desktop distributions since 2004/ 2005, but that doesn't mean it wouldn't be difficult to add a new architecture to a make-world based buildsystem like OpenWrt (don't forget the cross-compiler aspect).

LOL you a lawyer or something? Haha.

I was giving an example, take it easy...

As for what provoked that little bit of assiness, I have no clue. But I still agree with you so I see no reason for fight. You obviously know about C / OpenWRT build/code so I defer to you. Also as I previously mentioned I have no C knowledge at all.

OP, listen to slh because there is no way you alone without the knowledge will be able to hack it to include 64 bit. It apparently involves a load of recoding, not simply switching the toolkit.

I appreciate the extra verbosity smile

Good day smile

(Last edited by mys5droid on 25 Feb 2017, 04:52)

Thank you very much @mys5droid @slh,especially @slh,very thank your patience,I am sorry about several days did not online, Now I know the difficulty about this practice, but I don't want to give up,at least not now.Someone is succeed to migrate on arm,and I see that my question will not be difficult than it. I'll still search something that useful, If you find some new information ,please contact with jbccjb@163.com.

Why You say 64 bit for an older version?

thisisnasrin wrote:

Why You say 64 bit for an older version?

I have looked at all your 6 posts (as of this writing) and they are meaningless to any discussion threads you posted to, except they all contained your signature which pointed to an ad driven website. For that reason, I have removed the link from your signature that violates OpenWRT' ToS. Just a friendly reminder.

The discussion might have continued from here.