Unable to install from .iso or compile from source on Fedora 27

More
13 Mar 2018 04:32 - 13 Mar 2018 04:52 #107270 by owlbrudder
Total newbie here. I realise LinuxCNC is oriented toward Debian, but my platform is Fedora 27.

I have twice downloaded the disk image, but it appears not to be bootable. The device /dev/sr0 is bootable as I have just installed WinXP into a virtual machine for another purpose. (I know XP is a dog, but it is the Windows dog that I own and I don't feel like shelling out for a dubious upgrade.)

I have tried compiling from source and hit the expected number of snags, which I have overcome, but now I am stuck with the following compiler message:
Syntax checking python script halcompile
Copying python script halcompile
Preprocessing thermistor.comp
Traceback (most recent call last):
  File "../bin/halcompile", line 1419, in <module>
    main()
  File "../bin/halcompile", line 1414, in main
    os.unlink(outfile)
[color=red]OSError: [Errno 2] No such file or directory: 'objects/hal/user_comps/thermistor.c'[/color]
make: *** [hal/user_comps/Submakefile:82: objects/hal/user_comps/thermistor.c] Error 1
[root@womble src]#
I searched the source tree and also Googled for 'thermistor.c' without success. The nearest I have in the source tree is 'thermistor.comp'.

How do I proceed?
Last edit: 13 Mar 2018 04:52 by owlbrudder. Reason: typo
More
13 Mar 2018 08:30 #107271 by rodw
In some of the distros there are bugs with creating bootable USB drives according to my research on this. Not sure if that is what you are doing. My workaround was to download the .ISO on Windows, rename it to a .IMG file and use Win32 Diskimager to create the bootable USB drive. Worked every time!
More
13 Mar 2018 08:45 #107272 by owlbrudder
Thanks for replying rodw.

I burned the .iso to a DVD using the standard tool (Brasero), but it is not recognised as a bootable image. Have not tried burning to USB as I don't have any thumb drives I can blank.

The problem remains: why is the file 'thermistor.c' not present?
More
13 Mar 2018 09:08 #107273 by rodw
I've never had much luck booting from DVD and find CD's more reliable.
I'm not sure about the missing file. I've never had problems like that.
More
13 Mar 2018 22:07 #107306 by andypugh

owlbrudder wrote: TI searched the source tree and also Googled for 'thermistor.c' without success. The nearest I have in the source tree is 'thermistor.comp'.

How do I proceed?


Thermistor.comp is pre-processed to thermistor.c by halcompile.
Docs: linuxcnc.org/docs/2.7/html/hal/comp.html

It sounds like, possibly for distro reasons, the initial pre-processed output of halcompile is not going where halcompile expects to find it.
The following user(s) said Thank You: owlbrudder
More
13 Mar 2018 22:43 #107310 by owlbrudder
Thanks rodw. The .iso image is too big for a CD so it had to go onto a DVD. You may well have put your finger on the problem, as I don't know that I have booted from DVD on this machine. I will do some more work on it.
More
13 Mar 2018 22:50 #107311 by owlbrudder
Thanks for your reply andypugh. Now that you have told me what to look for I am sure I will be able to proceed. Thermistor.c is not in my home directory tree anywhere, which means halcompile may have failed. More investigation needed.

Differences between distros can be a royal pain!
More
13 Mar 2018 23:13 #107314 by owlbrudder
The light is starting to dawn - darkly. I ran halcompile across thermistor.comp and saw the following output:
[root@womble user_comps]# ../../../bin/halcompile thermistor.comp
Traceback (most recent call last):
  File "../../../bin/halcompile", line 1419, in <module>
    main()
  File "../../../bin/halcompile", line 1414, in main
    os.unlink(outfile)
[color=red]TypeError: coercing to Unicode: need string or buffer, NoneType found[/color]
It looks to me as though something in the .comp file is incompatible with my system - does that make sense? Clearly others are compiling without any such problem.
More
13 Mar 2018 23:43 - 13 Mar 2018 23:53 #107316 by owlbrudder
A Google of the error message threw up this from StackOverflow :
This error happens when you have a __unicode__ method that is a returning a field that is not entered. Any blank field is None and Python cannot convert None, so you get the error.

In your case, the problem most likely is with the PCE model's __unicode__ method, specifically the field its returning.

You can prevent this by returning a default value:

def __unicode__(self):
   return unicode(self.some_field) or u''
I could not find anything specific in the .comp which looks like a unicode call.

In the .comp file there are several references to include files. From the halcompile documentationdocumentation , I see this:
HEADERFILE - The name of a header file, either in double-quotes (include "myfile.h";) or in angle brackets (include <systemfile.h>;). The header file will be included (using C’s #include) at the top of the file, before pin and parameter declarations.
Yet in thermistor.comp I find include statements of the form "include <unistd.h>;" and elsewhere "#include <signal.h>". Could the different styles - one with '#' and one without - be causing the problem? If halcompile is getting confused about the includes, perhaps it is giving up. (Later: no - I tried getting rid of the # but halcompile still barfed with the same message).
Last edit: 13 Mar 2018 23:53 by owlbrudder. Reason: Additional information
More
13 Mar 2018 23:53 - 14 Mar 2018 00:10 #107317 by abu
Ooooppssss ...... new answers have been given while writing. I will post it anyway


I will try to be fun but precise.
I have never worked with Fedora, but I am going to risk a forensic analysis. I anticipate that I will fail, but some things will no longer be a mystery.


Basically the mechanism works in this way:
- The HAL components must be coded in C
- The halcompile utility simplifies the writing of code for HAL components.
- The component files (thermistor is a component) to be treated by halcompile have the .comp extension.
- halcompile translates the syntax .comp to syntax .c and adds the common repetitive elements of almost all the components. That is the part that saves work.
- If halcompile fails in its work, the .c file is not created. That's why you can not find thermistor.c

Now, the "usual serial killers"

I have a text file with all the work done by the make utility when the linuxcnc compile is ordered. It's huge. 668 pages. How to get that file is another story. For now, just trust me.

The very first time that the "make" utility refers to a python (.py) file is this:

"hal / utils / Submakefile: 101: Building objects / hal / utils / halcompile.py (from hal / utils / halcompile.g) (hal / utils / halcompile.g ../bin/yapps newer)"

wow .... the very first .py is ..... halcompile.py ... that comes from halcomplile.g .... and a strange thing ...... yapps.

In this case, the magnifying glass of Sherlock Holmes is called "man yapps". You know; in terminal.

The yapps man page says:
"yapps - create a Python module from a grammar file"

Magnificent. The python script halcompile.py comes from halcomplile.g when it has been processed by yapps.

Okay. We return to your output.

It seems that the python script halcompile.py is correct. At least, it does not give an error.

The error occurs when halcompile.py processes the first component. Oh wait. The first component in the list is precisely ........ thermistor.comp.

The second bread crumb is "os.unlink (outfile)".
But wait ... that's part of the standard python library. We look at halcompile script..............

And now, serial killers kill the coroner :blink: :blink: :blink:

Your output refers to line 1419. But halcompile (in linuxcnc version 2.8-pre) goes to line 1415. Sherlock Holmes is confused.:dry:

Anyway, halcompile defines a main () function and there are exceptions handling for os.unlink ()

To be continued .............. or resolved

pd. I suspect your python installation
Last edit: 14 Mar 2018 00:10 by abu.
The following user(s) said Thank You: owlbrudder
Time to create page: 0.080 seconds
Powered by Kunena Forum