> On 14. May 2019, at 08:54, Frits Letteboer <[email protected]> wrote: > > Thanks, Google, for marking this as spam. Much appreciated. </sarc> > >> On 07-05-19 19:15, René Rebe wrote: >> >> bdb atomics is probably only required for certain configs, can you >> conditionalize that arch m86k or so for now? >> +++ package/database/bdb/bdb-conf.in(working copy) >> @@ -52,7 +52,9 @@ >> +var_append confopt ' ' '--disable-atomicsupport’ > > Dammit. I thought I removed all the local hacks from the patch, but it was a > quick hack for this: > > --- > checking for atomic operations... configure: error: in > `/t2/src.bdb.motorola.20190514.144837.26112.graver-dev/db-6.2.23/build_unix': > configure: error: cannot run test program while cross compiling > --- > > I will get back to this, I need to check if m68k does support this.
Thanks, best resend what I overlooked or you find needed. >> Committed revision 48252. # options >> Committed revision 48253. # linux.conf >> Committed revision 48254. # strafe >> I find too many dots in filename slightly unintuitive, maybe in the future >> just fix-m68k.patch or >> add-… etc. > > I was under the impression .<arch>. had a special meaning. Duly noted. Yes, but only at the end. fix.patch.mips, also .cross for only during cross builds. Ideally patches should be clean and generic enough to always apply and go upstream. So the conditional applying with .patch.$arxh is mostly needed for “not as clean” quick hacks / workarounds. >> Committed revision 48255. # python2 >> that is for any build, e.g. not m68k specific? > > That was an issue with GCC 8.2.0 (or was it 8.3.0) while compiling on x86_64. > At least on my machine. It would segfault during compilation, this patch > would fix that. > >> package/scientific/gmp/zzz.m68k.patch >> is similarly likely only necessary if our gcc wrapper does not have it’s >> variables exported. >> We better 1) fix that and 2) remove -m68* generally off the compiler >> invocation, then we >> do not need to patch all packages like this. All the generic options are >> currently removed > > The problem with this package was that, during cross compilation, the CPU > gets misdetected, causing the GMP to fall back to 68000, which does not work > because. I found this was the only way to force it to select the codepath for > 68020+ (and actually compile without error. You could check if it just works now again, that the gcc wrapper is fixed with “current” bash versions. If not please resend ;-) > --- > errno.c:(.text+0x4): relocation truncated to fit: R_68K_GOT16 against symbol > `_GLOBAL_OFFSET_TABLE_' defined in .got.plt section in > /t2/build/motorola-9.0-svn-generic-m68k-68020-cross-linux/usr/lib/crti.o > ---
----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [email protected] with a subject of: unsubscribe t2
