Either Bero or pcpa over last years showed 0% interest in uclibc, which imo is good :) uClibc idea is yours, and only you is trying to maintain it.
i586 build is still broken, please fix it ASAP. 2015-06-23 19:18 GMT+02:00 Per Øyvind Karlsen <[email protected]>: > Well, as I told you earlier, only component of mine from systemd that I'm > actually currently using is udevd, so if in a rush without me avaliable to > help, just disable the particular feature causing issues and blocking your > work. > > I can always have a look at later, consider whether missing functionality > in uClibc should/needs to be implemented, be it feasible and worthwhile.. > Often it's just a matter of adding new definitions like. ie. new flags for > ie. mounting, for which the functionality in question has already been > implemented in the kernel, with the flag definitions there just to make > them available for user space tools to use and similar.. > If I do make sure the functioality to be implemented and available i > uClibc, I'll reenable whatever feature you had to disable to make it build > (just be sure to disable only what you need to build, not just the uClibc > build entirely. > Judging by the functio name, I guess I most likely would find it of > relevace and sufficiently worthwhile to take care oif it though. :) > > So in general, anything missing can most often be easily added by simply > looking at glibc or other libcs, and sync their headers etc., and some > occations you end up just "borrowing" it as-is from other libc projects, > ie. something most people should actively contributing should be equipped > with the competence & reasoning skills to idependently & figure out how to > solve >75% of these things themself. > > For this matter however, most wouldn't, it was a false regression in gcc > internals with recent gcc it relied on the behaviour of, as early as during > _start() in the dynamic linker, so not really possible to make anything > dynamically linked working then... ;) > > But keep in mind that we have two (at least one) greater toolchains > talents with better competence and expertize than mine, both bero & pcpa, > which you probably should be able turning to for assistane. And if that > still fails, and without me available, there's always the quite common and > heavily relied on resort we've always been dependent on and would make it > impossible for us to carry around all our software packages without perfect > knowledge and understanding of all the huge amount of packages we maintain > (together), namely upstream.. ;) * > > I got home from the office around 13:00 after having been there working > all night, and I don't just currently have any linux systems that's not in > parts and already ready and running for me to attend to this right away, > nor do I really feel like assembling any equipment to do, I was quite happy > leaving the office today.. ;) > > * By using list more, I'll be better able to help (not just) yourself > (same goes for and will benefit contributors in general, not just on the > technical issues at stake, but at properly communicate through the right > channels again) with such matters not just myself personally and directly, > but help give advice and on where to point to for help when I'm not able to > or unavailable for much more than communication on list. > It'll be easier for me to help you getting help and communicate with > upstream, assist you in diagnosing issues and better equipped with insight > and understanding built and provided while we try do initial diagnosing > together, to make it as efficient and less of a hazzle to make upstream > both fully understand and be able to help you out fixing the issue faster. > > I intend andd expect to be more actively avilable and involved again now > as my prescriptions has finally been sorted out again and I have an office > to work at, so for the immediate future, I'm basically available and > willing to work full time on cooker again, and if it were to be beginning > to bear fruits and going a more succesful and motivation direction again, > I'm likely too dumb and tenacious to avoid the not most healthy at times > level of participation and involvedment as before. :) > > I hope to continue from where I left of with announcing last weeks > strategy of mine, serving hopefully as advice/suggestion for others to join > behind.. > And I hope to get better as such again on a more frequent basis as well, > incidents when I was actively involved/leading the project back then, where > online politics and what not in public were found to be wastly more tiring > & harder to deal with than all other tasks combined, and made me extremely > reluctant from writing much nor or say much in open on publi lists etc. > since, hence explaining my perceived absence by most. > > Only from list though, still have been doing a lot of work on distro for > periods that I intend to prepare for inclusion direclty into cooker over > the next couple of weeks or so..:) > > > > 2015-06-23 12:46 GMT+02:00 Tomasz Gajc <[email protected]>: > >> Per your new uclibc still does not work on i586 error is the same as in >> previous message. >> https://abf.io/build_lists/2512965 >> >> Second uclibc is missing syncfs from glibc: >> >> /builddir/build/BUILD/systemd-221/src/shared/machine-pool.c:281:16: error: >> implicit declaration of function 'syncfs' >> [-Werror=implicit-function-declaration] >> (void) syncfs(fd); >> >> https://abf.io/build_lists/2512967 >> >> >> >> 2015-05-31 2:29 GMT+02:00 Tomasz Paweł Gajc <[email protected]>: >> >>> Dnia wtorek, 26 maja 2015 09:03:41 Per Øyvind Karlsen pisze: >>> > I'll try get around to attend to this later today (no promises though, >>> > which many of you might already guess from my rather sporadic activity >>> and >>> > all over the last months). >>> > >>> >>> Per can you please take a look on attached config.log for i586 build on >>> ABF? >>> >>> configure:3541: uclibc-gcc -V >&5 >>> gcc: error: unrecognized command line option '-V' >>> gcc: fatal error: no input files >>> compilation terminated. >>> configure:3552: $? = 1 >>> configure:3541: uclibc-gcc -qversion >&5 >>> gcc: error: unrecognized command line option '-qversion' >>> gcc: fatal error: no input files >>> compilation terminated. >>> configure:3552: $? = 1 >>> configure:3572: checking whether the C compiler works >>> configure:3594: uclibc-gcc -Oz -Wa,--compress-debug-sections -gdwarf-4 - >>> Wstrict-aliasing=2 -pipe -Wformat -Werror=format-security >>> -D_FORTIFY_SOURCE=2 >>> -fstack-protector --param=ssp-buffer-size=4 -fomit-frame-pointer >>> -mtune=atom >>> -march=i586 -fasynchronous-unwind-tables -fno-stack-protector -Oz >>> -Wl,--no- >>> undefined conftest.c >&5 >>> /usr/bin/ld: warning: /usr/uclibc/usr/lib/crt1.o: missing .note.GNU-stack >>> section implies executable stack >>> /usr/bin/ld: warning: /usr/uclibc/usr/lib/crti.o: missing .note.GNU-stack >>> section implies executable stack >>> /usr/bin/ld: warning: /usr/uclibc/usr/lib/crtn.o: missing .note.GNU-stack >>> section implies executable stack >>> configure:3598: $? = 0 >>> configure:3646: result: yes >>> configure:3649: checking for C compiler default output file name >>> configure:3651: result: a.out >>> configure:3657: checking for suffix of executables >>> configure:3664: uclibc-gcc -o conftest -Oz -Wa,--compress-debug-sections >>> - >>> gdwarf-4 -Wstrict-aliasing=2 -pipe -Wformat -Werror=format-security - >>> D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 >>> -fomit-frame- >>> pointer -mtune=atom -march=i586 -fasynchronous-unwind-tables -fno-stack- >>> protector -Oz -Wl,--no-undefined conftest.c >&5 >>> /usr/bin/ld: warning: /usr/uclibc/usr/lib/crt1.o: missing .note.GNU-stack >>> section implies executable stack >>> /usr/bin/ld: warning: /usr/uclibc/usr/lib/crti.o: missing .note.GNU-stack >>> section implies executable stack >>> /usr/bin/ld: warning: /usr/uclibc/usr/lib/crtn.o: missing .note.GNU-stack >>> section implies executable stack >>> configure:3668: $? = 0 >>> configure:3690: result: >>> configure:3712: checking whether we are cross compiling >>> configure:3720: uclibc-gcc -o conftest -Oz -Wa,--compress-debug-sections >>> - >>> gdwarf-4 -Wstrict-aliasing=2 -pipe -Wformat -Werror=format-security - >>> D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 >>> -fomit-frame- >>> pointer -mtune=atom -march=i586 -fasynchronous-unwind-tables -fno-stack- >>> protector -Oz -Wl,--no-undefined conftest.c >&5 >>> /usr/bin/ld: warning: /usr/uclibc/usr/lib/crt1.o: missing .note.GNU-stack >>> section implies executable stack >>> /usr/bin/ld: warning: /usr/uclibc/usr/lib/crti.o: missing .note.GNU-stack >>> section implies executable stack >>> /usr/bin/ld: warning: /usr/uclibc/usr/lib/crtn.o: missing .note.GNU-stack >>> section implies executable stack >>> configure:3724: $? = 0 >>> configure:3731: ./conftest >>> /builddir/build/BUILD/systemd-220/configure: line 3733: 30759 >>> Segmentation >>> fault ./conftest$ac_cv_exeext >>> configure:3735: $? = 139 >>> configure:3742: error: in `/builddir/build/BUILD/systemd-220/uclibc': >>> configure:3744: error: cannot run C compiled programs. >>> If you meant to cross compile, use `--host'. >>> >>> >>> -- >>> Cheers >>> TPG >> >> >> >
_______________________________________________ OM-Cooker mailing list [email protected] http://ml.openmandriva.org/listinfo.cgi/om-cooker-openmandriva.org
