Buster compile failure

[mung kie]

As the Raspbian Buster  image was released (we use as ARM benchmark test distro) there was a few SOC test compiles made overnight and the scripts failed with errors due to omission of libatomic in the git sources.

Seems line 367 and 33 of Submakefile in rtapi and hal/utils needs the addition.

Not sure how the machinekit autoconfig handles this.

Linuxcnc 2.9 seems compile direct without errors from their git repo.

[Timothy March]

You may want to look at post from RPI gipo help and try LinuxCnc with hal_gipo.so by KL Chin

“Quote
Hi ,

I still testing both.

1) LinuxCNC had already 2.8 but MachineKit still based on 2.6.
2) The StepConf was so slow with MachineKit.
3) The Gui sample works on LinuxCNC

BTW. I had attached the hal_gpio.so for LinuxCNC, may be you can try it.
Just copy to LinuxCNC rtlib folder. I just change few lines of the hal_gpio.c.

Regards,
KL Chin

On Tuesday, 28 August 2018 03:42:31 UTC+8, Timothy March wrote:
KL Chin why are you using LinuxCnc instead of Machinekit? The hal_gipo only works with Machinekit there is no gipo driver for LinuxCnc.
Tim

Attachments (1)

hal_gpio.so
26 KB Download”

[Timothy March]

Are you thinking Rpi 4 buster ?

[mung kie]

I think I may not, it would probably be a large waste of time.

[mung kie]

No, I think the idea was to inform machinekit users of a possible problem with the autoconf settings and details of the changes required to get machinekit to build from the git repo.

Raspbian is a testbench for compiling ARM code for a number of test SOC and SBC.

I probably should not have mentioned it especially after the Iran/China fiasco.

[schoo...@gmail.com]

If you explain properly what you are talking about, something might get done.

Machinekit builds fine with Buster and sid, so you are in some sort of corner case build,
for specific hardware, on a distro we do not support.

--
website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit
---
You received this message because you are subscribed to the Google Groups "Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to machinekit+...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/83d783ca-5077-4c24-81d2-a460e908fed4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[mung kie]

Sorry to be vapid and brief Schooner, but you get what you pay for with open sores.

You are probably right as this stuff often gets pain ted into a corner case, and ARM without any RT. Basically this was from the initial build before any RT kernels are investigated.

We cannot use git as there is some sort of problem with secure projects and Federal Acquisitions Regulations Technology and I just added what I was allowed.

I have checked the log and am worried I could end up like chelsea manning if I put too much here.

I have attached logs but hacked/edited out some of the logs as I think they reference secure stuff, and also the relevant part of the compile script.

The relevant error is 

Linking rtapi_msgd

/usr/bin/ld: objects/rtapi/rtapi_msgd.o: undefined reference to symbol '__atomic_fetch_add_8@@LIBATOMIC_1.0'

/usr/bin/ld: //usr/lib/arm-linux-gnueabihf/libatomic.so.1: error adding symbols: DSO missing from command line

collect2: error: ld returned 1 exit status

make: *** [rtapi/Submakefile:381: ../libexec/rtapi_msgd] Error 1

Adding -libatomic to lines of submakefiles as originally stated fixes the build, but not sure how one would add that to autoconf.

On Thursday, June 27, 2019 at 5:53:22 PM UTC+1, Schooner wrote:

If you explain properly what you are talking about, something might get done.

Machinekit builds fine with Buster and sid, so you are in some sort of corner case build,
for specific hardware, on a distro we do not support.

On 27/06/19 17:11, mung kie wrote:

No, I think the idea was to inform machinekit users of a possible problem with the autoconf settings and details of the changes required to get machinekit to build from the git repo.

Raspbian is a testbench for compiling ARM code for a number of test SOC and SBC.

I probably should not have mentioned it especially after the Iran/China fiasco.

On Thursday, June 27, 2019 at 7:01:44 AM UTC+1, Timothy March wrote:

Are you thinking Rpi 4 buster ?

 

--
website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit
---
You received this message because you are subscribed to the Google Groups "Machinekit" group.

To unsubscribe from this group and stop receiving emails from it, send an email to machi...@googlegroups.com.

[schoo...@gmail.com]

Ah, so it is a DSO error, not that the lib is missing.

I have found various DSO errors using the latest gcc tools, not this one thus far.

It has something to do with the order of compilation and linkage, I had to add a specific -lzmq AFAIR to a submakefile

which functioned exactly as intended with an earlier version of gcc.

What version of gcc is in the Raspian distro?  I will try doing some tests to replicate.

To unsubscribe from this group and stop receiving emails from it, send an email to machinekit+...@googlegroups.com.

Visit this group at https://groups.google.com/group/machinekit.

To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/f749f9ed-20ff-4153-9ac4-4e457bc4a15f%40googlegroups.com.

[schoo...@gmail.com]

Looking at this again, the error does arise due to the order of linkage, but that is symptomatic.

The base problem is that later gcc linkers employ a far stricter criteria as to when symbols are available.
The 'DSO missing from the command line' message will be displayed when the linker does not find the
required symbol with it's normal search, but the symbol is available in one of the dependencies of a directly specified dynamic library.
ie.
There is an implicit linkage to a 3rd library but the makefile line does not have an explicit linkage to it specified.

In the past the linker considered symbols in dependencies of specified languages to be available, so this worked fine.

Try building by exporting backwardly compatible linker switches such as:

export LDFLAGS="-Wl,--copy-dt-needed-entries" ./configure && make -j$(nproc)

and it should work.

I will look at adding explicit linkage to libatomic in due course, when I can manage to replicate this error.

[schoo...@gmail.com]

After some investigation, looks like there is not need for configure.ac to test for libatomic.

It is such a basic potential requirement for any binary compiled at C11 or C++11 or above,
that libatomic.so.1 is installed even on a basic default install, with no build tools at all.

I will add it to RTAPI_MSGD_CFLAGS to cure your problem.

It does not however occur in amd64, i386 or armhf builds, even using gcc 8.3.0-7 in sid.
Would not be the first time that raspian has done something differently however :)