Compilation under not that recent Ubuntu versions (e.g. 16.04 LTS Xenial) could lead to AutoMoc problems

[mosagepa]

Hello.

Actually when compiling pulseview from GitHub sources in my Ubuntu 16.04 LTS (but updated with several including e.g. Python 3.8 etc.) gives duplication of moc_view.cpp that is two includes (repeated include) when dealing with pulseview_automoc.cpp.

I think a safeguard for excluding this according to AutoMoc way of doing this (a particular exclude rule) should be added.

By any means contact me if you think I can have a quick workaround to make it fully compile on my system.

Kind regards
Mosagepa

[mosagepa]

Actually I tried to rename the view.cpp under corresponding folder but it doesn't help to mitigate this, since AutoMoc creates the duplicate include for moc_view.cpp inside pulseview_automoc.cpp every single time.

I can post other issues that can happen on recent machines when trying to compile e.g. libsigrockdecode, but this I digress since it's not pulseview's issue.

But it makes me think how can one give out a github node without properly dealing with compilation errors as simple as these.

Not to criticize but it made me spend a whole two evenings trying to find the source of the errors.

[mosagepa]

Update information for all those affected:

The reported problem caused by Automoc is also appearing in some other software builds out there:
https://gitlab.kitware.com/cmake/cmake/issues/14489

Admitedly this is a case-by-case lottery, somehow I guess it would not apply or surface for those with newer kernels or people just trying out PulseView on their brand-new, recently-installed, all-up-to-date Ubuntu or mainline Linux machines.

I noticed by renaming both view.cpp & view.hpp in subfolders pv/views/decoder_binary and pv/views/tabular_decoder, as binview.* and tabview.*, respectively, cured the problem because it seems to be, that there are allogether 3 source files names views.cpp along the full sourcetarball/distribution for PulseView.

Remember to create apropriate symbolic links with the old names for the make/AutoMoc toolchain to properly find them.
[edit: actually not needed-- you can have a go if you replace the affected names with the newly created names inside the CMakeLists.txt]

But in any case, this leads us not very far for a workaround, since I noticed that eventually the linking phase fails but in my case this is due to GLIBC being 2.23 and the libpython3.6 shared libraries to which the linker, well, links, :) expect GLIBC to be 2.25 or further, because the source Python/random.c contains a reference to getrandom() which is a mere system call wrapper needed to patch some unefective PRNGs (pseudorandom number generators) which until Kernel 3-17+ resorted to reading /dev/(u)random which could be faulty or not very "random" in some circumstances). This reference keeps undefined if your GLIB is not 2.25 or later.

See details here: https://lwn.net/Articles/711013/

But I digress. I've managed to guess that GLIB 2.25 is in fact mentioned as a requirement to installing libpython3.6 (>=3.6.5 also) from DEB / Ubuntu packages, JUST BECAUSE there is this getrandom() symbol/function referenced. You can grep the objdump -T to check this.

Last resort I'm trying is to (temporarily) fake the Python3.6 libraries into declaring all the symbols towards GLIBC 2.23. WIth an asm inline into a short header .h declared as CFLAGS additional when (re)compiling Python3.6. Of course after I have PulseView compiled I'll recompile the Python as normal, I don't want any side effects.

The problem is that when configuring Python3.6 libraries from sources, the configure script tries to guess whether the system supports the dreaded getrandom() , but does this just by looking if the kernel is 3.17++. Which is my case (and probably host of other user's case, if they've not obligued to the dreaded programmed obsolescence of all things Linux), EVEN IF the installed GLIBC is less than 2.25 and so it DOES NOT INDEED impements what the modern kernel expects.

All around this is a nightmare, but I'm motivated to finally get this beast compiled. I think my "report" can shed some light, even if just for Documentation sake or warnings alongsuch in the case of PulseView.

Thanks for reading, any comment will be helpful...

[abraxa]

I wonder what's special about your setup as I've never heard of such issues nor seen them myself.

[abraxa]

That said, I suggest opening issues under the original repos: https://github.com/sigrokproject

[mosagepa]

I wonder what's special about your setup as I've never heard of such issues nor seen them myself.

Not that unusual, really. Just Ubuntu 16.04 LTS but this has the GLIBC 2.23 which conflicts with Python3.6 libs which in turns doesn't let me compile properly PulseView. Not to mention that AutoMoc makes this "cute" thing inserting double includes into a .cpp.

To make things short (this is from a recompile, so it doesn't include all the previous steps prior to linking, those were all OK):
[ 1%] Automatic moc for target pulseview
[ 1%] Built target pulseview_automoc
[ 2%] Linking CXX executable pulseview
libpython3.6m.so.1.0: undefined reference to `getrandom@GLIBC_2.25'
collect2: error: ld returned 1 exit status
CMakeFiles/pulseview.dir/build.make:2630: recipe for target 'pulseview' failed
make[2]: *** [pulseview] Error 1
CMakeFiles/Makefile2:67: recipe for target 'CMakeFiles/pulseview.dir/all' failed
make[1]: *** [CMakeFiles/pulseview.dir/all] Error 2
Makefile:149: recipe for target 'all' failed
make: *** [all] Error 2

[mosagepa]

That said, I suggest opening issues under the original repos: https://github.com/sigrokproject

I'll try to do that as soon as I properly identify the issues I'm having, because I'm still fighting :) (and as soon as I am able to properly summarize not to clog up that site).

Until then, maybe I could try with an older repo of PulseView or of the full Sigrok stuff to begin with. It could be the right way for my (not so cutting edge) hard & soft & Ubuntu version.

Can you give me a link of previous releases in source format?

Thanks in advance and sorry for the inconveniences.

[mosagepa]

Please note that the previous compile partial log I've given up there, it is AFTER tweaking the *view.cpp and *view.hpp source filenames so as to get AutoMoc NOT to generate redundant include declarations in the main cpp when Cmaking.

I think this Automoc issue could surface for some other users. But then most people out there who want or would like to use SIGROK are going to just install their prebuilt .DEBS on their cutting edge machines. Even with that I can't conceive it's just ME with this 16.04 LTS box. It has nothing out of normal. I've compiled tons of packages without a glitch. Surely PulseView makers could recognise this AutoMoc potential problem or at least try to embed a workaround into the source for it not to surface just in case...

[abraxa]

Old versions are here: https://sigrok.org/download/source/

Seriously though, I've never encountered the AutoMOC issue before, so that really surprises me.

[mosagepa]

Old versions are here: https://sigrok.org/download/source/

Seriously though, I've never encountered the AutoMOC issue before, so that really surprises me.

I'm not making this up :) If you have access to a 16.04 LTS box (you could try downloading a Live version onto an USB) and try to install sigrok components, you will face it.

As I mentioned there are other software out there which also enters somehow this "race condition" with Automoc. And the workaround was to explicitly declare the affected source files not to be processed by Automoc. So yeah it seems that no one has come out yet with an explanation about why this is the case for some scenarios and not for others...

[mosagepa]

If you git clone the most recent PulseView onto a fresh 16.04 LTS box you will get the Automoc redundant includes when you try to compile it. Just give it a try, I know it's maybe not worth your time since it seems I am yet the only user facing this... No one out there is compiling Pulseview from source with a Xenial Ubuntu box?

[mosagepa]

Then it could be a glitch with CMake itself but I've yet to see an explanation or report about this... I only know of another software's user which faced same issue. Not really sure Automoc developers are fully aware of this.