Hi, On 17 Dec 2018, at 18:54, Joe Kozak <[email protected]> wrote:
> oh i used the fixfile and then a cd.. then a difffixfile > > ../packa...blabla/funtoy.patch the whole works! then went in the > src.xxxxxxxxxxxxxxx/directory/..... and found the unchanged file! :) > I'll figure it out soon.... probobly need sleep too.... sometime..... > maybe… in t2/trunk you do not need to redirect fixfilediff output, with a filename supplied fixfilediff will create the file directly in the package’s $confdir: fixfilediff hotfix.patch fixfilediff glibc-2.18.patch are common names. > I also have a sun 3/50... how workable a system do you think can be built? > I might have to tftp boot it, but i did it 20 years ago, i can figure it out > again! :) > > On Mon, Dec 17, 2018 at 11:48 AM René Rebe <[email protected]> wrote: > Hey, > > On 17 Dec 2018, at 18:39, Joe Kozak > <[email protected]> wrote: > >> On Mon, Dec 17, 2018 at 11:29 AM René Rebe <[email protected]> wrote: >> Hi, >> >> keeping the list cc’ed for other’s to learn, too. Hope that is ok, ... >> >> On 17 Dec 2018, at 18:23, Joe Kozak >> <[email protected]> wrote: >> >>> i am still learning this t2 setup, so i am sure that is much of it. >>> I have been trying the crosscompile on the x86 from the newest iso inside a >>> VM, it complained a lot about linux-headers missing PATH_MAX but I just >>> #define PATH_MAX 4096 wherever it complained. (maybe 3 places) inside the >>> source tar file >> >> This could be a latest glibc thing, I fixed a couple of those. Often they >> clean up things upstream and such regressions occur. >> >>> and recompressed it into the download directory. on native (not VM) svn >>> checkout build attemts, this is not the case, and >> >> Do you mean you edit the downloaded source tar balls? You should NEVER do >> this! patches go into packages/…/$pkg/*.patch, not editing the checksumed >> original tar balls. ever. >> >> OH I know! I was just playing, I tried patches too, but the patches didnt >> seem to work whereas the src tarball edit did. Mainly i was trying to >> figure out why the patches were overwritten (or the makesystem rewrote them) > > patches are automatically applied from the t2-src package/*/$pkg/*.patch > > no idea where you placed them ;-) > >> I am trying fresh install in vm now. >> yes, cc all! >> >>> linux-headers compiles fine. >>> >>> i think the buildchain is somehow not correct on the iso. Q: is >>> there a way to use mine to rebuild the toolchains ? >> >> When you build a whole new target, t2 bootstraps a new toolchain in the >> stage 0. >> Stage 0 is tooclchain, stage 1 is cross compile, then is 2 to re-build, >> sanity check tooclahin, and then mostly stage 5 compiling normally. >> >> If you want to rebuild your “toolchain”, you could -force Emerge gcc, >> binutils, … but that is really not that necessary. >> >> René >> >>> On Mon, Dec 17, 2018 at 9:38 AM René Rebe <[email protected]> wrote: >>> Hi, >>> >>> On 17 Dec 2018, at 16:01, Joe Kozak >>> <[email protected]> wrote: >>> >>>> building trunk i get this. tried fixfile on the offending code to just >>>> comment it out for fun, gets overwritten, must be dynamicly made after >>>> patches are applied. tried extra compiler options '-O3' to be sure, no >>>> effect. ALSO ./debug then cd into dir then eval $MAKE $makeopt fails >>>> >>>> will keep informed >>> >>> >>> sorry, I did not yet memorise your other emails, you want to only build for >>> sparc64, or do you try random things? >>> are you building on t2 already or some Debian / Ubuntu / other flavour? >>> >>> I ask because the last time I tried sparc64 built for me, on my t2 based >>> build server: >>> >>> https://www.youtube.com/watch?v=XYsKct4T2xk >>> https://www.youtube.com/watch?v=10q2OxHAzQ4 >>> >>> >>> I can re-try latest trunk just for the fun of it, but the last binary iso >>> tested in this videos is not yet that old: >>> >>> t2-minimal-sparc64-r46697.iso >>> >>> René >>> >>>> ============ >>>> ============ >>>> ============ >>>> ============ >>>> >>>> moo-PowerEdge-R710 >>>> src.glibc.default.20181217.085229.19023.moo-PowerEdge-R710 # ./debug.sh >>>> debug-glibc:[src.glibc.default.20181217.085229.19023.moo-PowerEdge-R710]# >>>> ls >>>> . ERROR-LOG badfiles.txt cmd_wrapper.log debug.hooks files.lst >>>> fl_wrapper.wlog flist.txt.new flist.txt.tmp install_wrapper.log >>>> olist.txt.old xsrcdir.txt >>>> .. archdir build.pid debug.buildenv debug.sh fl_wrapper.rlog >>>> flist.txt flist.txt.old glibc-2.28 olist.txt.new >>>> untar.txt >>>> debug-glibc:[src.glibc.default.20181217.085229.19023.moo-PowerEdge-R710]# >>>> cd glibc-2.28/ >>>> debug-glibc:[glibc-2.28]# eval $MAKE $makeopt >>>> Makeconfig:42: *** missing separator. Stop. >>>> >>>> >>>> ============ >>>> ============ >>>> ============ >>>> ============ >>>> >>>> In file included from <command-line>: >>>> ./../include/libc-symbols.h:75:3: error: #error "glibc cannot be compiled >>>> without optimization" >>>> # error "glibc cannot be compiled without optimization" >>>> ^~~~~ >>>> make[2]: *** [../Makerules:287: >>>> /home/moo/t2-trunk/src.glibc.default.20181217.085229.19023.moo-PowerEdge-R710/glibc-2.28/objdir/tcb-offsets.h] >>>> Error 1 >>>> make[2]: Leaving directory >>>> '/home/moo/t2-trunk/src.glibc.default.20181217.085229.19023.moo-PowerEdge-R710/glibc-2.28/csu' >>>> make[1]: *** [Makefile:258: csu/subdir_lib] Error 2 >>>> make[1]: Leaving directory >>>> '/home/moo/t2-trunk/src.glibc.default.20181217.085229.19023.moo-PowerEdge-R710/glibc-2.28' >>>> make: *** [Makefile:9: all] Error 2 >>>> Due to previous errors, no 1-glibc.log file! >>>> (Try enabling xtrace in the config to track an error inside the build >>>> system.) >>>> --- BUILD ERROR --- >>>> Install SysV Init script 'nscd' (19/81): rcX done. >>>> Creating file list and doing final adaptions ... >>>> Searching for orphaned files ... >>>> Found 11 files for this package. >>>> Found 1 orphaned files for this package. >>>> Clear (old) md5sums ... >>>> Creating md5sum files ... done. >>>> Creating package description ... >>>> Making post-install adaptions. >>>> == 12/17/18 08:52:39 =[1]=> Aborted building package glibc. >>>> -> Unmounting loop mounts ... >>> >>> -- >>> ExactCODE GmbH, Lietzenburger Str. 42, DE-10789 Berlin >>> http://exactcode.com | http://exactscan.com | http://ocrkit.com | >>> http://t2-project.org | http://rene.rebe.de >>> >> >> -- >> ExactCODE GmbH, Lietzenburger Str. 42, DE-10789 Berlin >> http://exactcode.com | http://exactscan.com | http://ocrkit.com | >> http://t2-project.org | http://rene.rebe.de >> > > -- > ExactCODE GmbH, Lietzenburger Str. 42, DE-10789 Berlin > http://exactcode.com | http://exactscan.com | http://ocrkit.com | > http://t2-project.org | http://rene.rebe.de > -- ExactCODE GmbH, Lietzenburger Str. 42, DE-10789 Berlin DE Legal: Amtsgericht Berlin (Charlottenburg) HRB 105123B, Tax-ID#: DE251602478 Managing Director: René Rebe http://exactcode.com | http://exactscan.com | http://ocrkit.com | http://t2-project.org | http://rene.rebe.de
----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [email protected] with a subject of: unsubscribe t2
