[LinuxCNC/linuxcnc Issue#228] Build version 2.7.8 on i586 failed

#2 – SebKuzminsky 于 2017-02-03

Neat, RPMs, that’s new.

We regularly build 2.7 for uspace on 32-bit x86, and I’ve never seen this problem. My guess is that it’s caused by some difference in our regular build environment and this RPM build environment you’re working with.

What version of GCC are you using?

What commands does your build system run to do all this? At least the configure steps look quite different than our regular build (described here: http://linuxcnc.org/docs/devel/html/code/building-linuxcnc.html). There are also some errors during configure, though I don’t know if they’re related to the fatal error later.

#3 – antohami 于 2017-02-03

>What version of GCC are you using?

Used gcc6. But the problem first came in August, when trying to build version 2.7.6. Used when gcc5. I try to collect a gcc5 version 2.7.5.

> What commands does your build system run to do all this?

link to the spec: http://git.altlinux.org/people/antohami/packages/?p=linuxcnc.git;a=summary

The main difference is that in the assembly, I instead use autogen.sh autoreconf -fisv

Update: fix link

#4 – SebKuzminsky 于 2017-02-03

I build LinuxCNC 2.7 with GCC 6 (on Debian Stretch) all the time without any trouble.

#5 – SebKuzminsky 于 2017-02-03

I get a 404 on the git.altlinux.org link in your comment.

#6 – jepler 于 2017-02-03

Whatever exactly is going on probably needs to be fixed near here: https://github.com/LinuxCNC/linuxcnc/blob/master/src/Makefile#L995

We play weird games with symbols in the linker to get semantics similar to kernel symbol exporting in userspace. There used to be a special case for getpxthunk symbols but we thought the current iteration was right without losing all possible thinks for all possible architectures. Apparently not.

#7 – SebKuzminsky 于 2017-02-03

I can reproduce this problem on Debian Stretch, 32-bit x86 installation, with GCC 6.3.0-5. The master branch builds fine but 2.7 fails with a similar error as what @midyukov-anton.

#8 – SebKuzminsky 于 2017-02-03

The diff from 2.7 (which fails) to master (which does not fail) in the area @jepler pointed to is this:

“
@@ -960,14 +988,13 @@ RTOBJS := $(sort $(foreach mod,$(obj-m),$(call TORTOBJS,$(mod))))

RTDEPS := $(sort $(RTOBJS:.o=.d))

-IS_POWERPC = test uname -m = ppc -o uname -m = ppc64
modules: $(patsubst %.o,../rtlib/%.so,$(obj-m))
../rtlib/%.so:
$(ECHO) Linking $@
$(Q)ld -d -r -o objects/$*.tmp $^
- @if ! $(ISPOWERPC); then objcopy -j .rtapiexport -O binary objects/$.tmp objects/$.exp; fi
- @if ! $(ISPOWERPC); then objcopy -G x86.getpcthunk.bx -G i686.getpc_thunk.bx xargs -r0n1 echo -G < objects/$.exp | grep -ve ‘^-G $$’ | sort -u objects/$.tmp; fi
- $(Q)$(CC) -shared -Bsymbolic $(LDFLAGS) -o $@ objects/$*.tmp -lm
+ $(Q)objcopy -j .rtapi_export -O binary objects/$.tmp objects/$.sym
+ $(Q)(echo '{ global : '; tr -s '\0' < objects/$.sym | xargs -r0 printf '%s;\n' | grep .; echo 'local : ; };') > objects/$*.ver
+ $(Q)$(CC) -shared -Bsymbolic $(LDFLAGS) -Wl,--version-script,objects/$*.ver -o $@ $^ -lm

RTFLAGS += -fno-strict-aliasing -fwrapv

“

The second objcopy is missing, which looks suspicious, but I don’t know this part of the code well enough to hazard a guess.

#9 – jepler 于 2017-02-03

@SebKuzminsky ah so it’s fixed in master branch? That’s great. Maybe we should just back port the change

#10 – SebKuzminsky 于 2017-02-04

I cherrypicked @jepler’s fix (f87c0244) from master to a new branch called 2.7-rtlibs-fix. That fix lets the compile succeed on my Stretch i386 machine.

It was not a straight-forward cherrypick, and I’d appreciate a sanity-check from @jepler. In the meanwhile, the buildbot is testing it on our current platforms here: http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/4739

@midyukov-anton, please give that branch a try.

#11 – antohami 于 2017-02-04

Yesterday I was able to gather here with the patch, just in my time zone was evening, and I went to sleep.
“
diff --git a/src/Makefile b/src/Makefile
index 2e903e4..9da3e10 100644
--- a/src/Makefile
+++ b/src/Makefile
@@ -966,7 +966,7 @@ modules: $(patsubst %.o,../rtlib/%.so,$(obj-m))
$(ECHO) Linking $@
$(Q)ld -d -r -o objects/$*.tmp $^
@if ! $(ISPOWERPC); then objcopy -j .rtapiexport -O binary objects/$.tmp objects/$.exp; fi
- @if ! $(ISPOWERPC); then objcopy -G x86.getpcthunk.bx -G i686.getpc_thunk.bx xargs -r0n1 echo -G < objects/$.exp | grep -ve ‘^-G $$’ | sort -u objects/$.tmp; fi
+ @if ! $(ISPOWERPC); then objcopy -G x86.getpcthunk.bx -G i686.getpcthunk.bx -G x86.getpc_thunk.dx xargs -r0n1 echo -G < objects/$.exp | grep -ve ‘^-G $$’ | sort -u objects/$.tmp; fi
$(Q)$(CC) -shared -Bsymbolic $(LDFLAGS) -o $@ objects/$*.tmp -lm

RTFLAGS += -fno-strict-aliasing -fwrapv
diff --git a/src/Makefile.modinc.in b/src/Makefile.modinc.in
index 5ee051c..c0ab54d 100644
--- a/src/Makefile.modinc.in
+++ b/src/Makefile.modinc.in
@@ -120,7 +120,7 @@ IS_POWERPC = test uname -m = ppc -o uname -m = ppc64
$(ECHO) Linking $@
$(Q)ld -d -r -o $*.tmp $^
$(Q)if ! $(ISPOWERPC); then objcopy -j .rtapiexport -O binary $.tmp $.exp; fi
- $(Q)if ! $(ISPOWERPC); then objcopy -G x86.getpcthunk.bx -G i686.getpc_thunk.bx xargs -r0n1 echo -G < $.exp | grep -ve ‘^-G $$’ | sort -u $.tmp; fi
+ $(Q)if ! $(ISPOWERPC); then objcopy -G x86.getpcthunk.bx -G i686.getpcthunk.bx -G x86.getpc_thunk.dx xargs -r0n1 echo -G < $.exp | grep -ve ‘^-G $$’ | sort -u $.tmp; fi
$(Q)$(CC) -shared -Bsymbolic $(LDFLAGS) -o $@ $*.tmp -lm
endif
“

Today, I check your patch
Yesterday found here is a discussion on the use of objcopy: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59842#c4

#12 – antohami 于 2017-02-04

2.7-rtlibs-fix building successful. Thanks!

#13 – jepler 于 2017-02-04

@SebKuzminsky I’d just take the whole text of that rule from master branch into 2.7 rather than trying to cherry-pick — it looks like it went through a couple of revisions due to the docker bug that an intermediate version was triggering. In particular, I’m surprised to see any checks of IS_POWERPC left in that Makefile rule.