Installing Catalina on Linux to /opt
RalfSt
Posts: 19
in Propeller 1
Hello,
I just ordered a Propeller 1 board and would like to develop software for it using the C-Language.
Since the GCC-Port is totally outdated and cannot be compiled with modern GCCs, I found the alternative Catalina.
Sadly the current state of documentation is focusing on "just get it to work with Code::Blocks".
I do a lot of embedded systems hacking and therefore I use lots of different architecture. To keep my system clean I install all cross compilers and platform related tools to /opt/$ARCH/.
The installation process of Catalina seems to be a bit unusual. Beside the fact that it needs $PATH pointing to precompiled versions of the binaries that should be compiled, I cannot figure out how to set the destination directory.
I also found some worrying lines in the makefiles I looked at. There the -m32 option is used. Do I have to edit something to get 64bit binaries? I use a "modern" 64bit Linux which of cause cannot run old 32bit binaries.
So, my question is: How can I build a 64Bit catalina and install it to /opt/propeller/.?
Maybe I also ask the wrong questions. Is this the right C compiler at all? or is there a third, better alternative?
I just ordered a Propeller 1 board and would like to develop software for it using the C-Language.
Since the GCC-Port is totally outdated and cannot be compiled with modern GCCs, I found the alternative Catalina.
Sadly the current state of documentation is focusing on "just get it to work with Code::Blocks".
I do a lot of embedded systems hacking and therefore I use lots of different architecture. To keep my system clean I install all cross compilers and platform related tools to /opt/$ARCH/.
The installation process of Catalina seems to be a bit unusual. Beside the fact that it needs $PATH pointing to precompiled versions of the binaries that should be compiled, I cannot figure out how to set the destination directory.
I also found some worrying lines in the makefiles I looked at. There the -m32 option is used. Do I have to edit something to get 64bit binaries? I use a "modern" 64bit Linux which of cause cannot run old 32bit binaries.
So, my question is: How can I build a 64Bit catalina and install it to /opt/propeller/.?
Maybe I also ask the wrong questions. Is this the right C compiler at all? or is there a third, better alternative?
Comments
Once installed (e.g. to /usr/local/lib/catalina), execute "source /usr/local/lib/catalina/use_catalina" and you should be good to go!
Ross.
Difficult one to answer. At this point, I think it is your best option - but I am a little biased!
I used to compile and release both 32 and 64 bit versions, but now I don't bother. However, Catalina has certainly been tested on both.
Ross.
I will try this as soon as I have some time (maybe tomorrow).
I'll post the steps I went/tried
What about a pre-compiled package ?
http://david.zemon.name:8111/project.html?projectId=PropGCC&tab=projectOverview
And as far as I know, it can be compiled without problems with at least Ubuntu 16.04 LTS, not sure with later releases.
What OS are you using ?
I just moved my current installation to /opt and it works ok (as I mentioned, you have to manually set LCCDIR).
Also, you will have to manually reset the compiler toolchain executable directory in Code::Blocks (see Settings->Compiler->Toolchain Executables").
I will try building it in /opt in the next few days and make sure there are no script dependencies on the build location.
Ross.
P.S. - the current release was compiled and run it a 64-bit Ubuntu machine.
This should work with the latest version of Xcode:
Any chance you want to copy the change over?
I will make this the default location in the next release.
Preparation as root:
Preparation as user:
failed:
Why does build_all expect an already build and installed Catalina?
I let it just point to the bin-directory in the zip archive where only windows executables and 32 Bit Linux executables that I cannot run on my Machine.
Then I repeat the build process with updated LCCDIR
Then the build process seems to succeed - It does not exit with an error message.
But I don't know where the binaries are.
In the catalina/bin directory are still 32bit executables.
In the last three lines of the build-process-output I saw "cp script/test_prelude bin/test_prelude".
So I just searched for this file:
So the obviously build_all just builds the sources and there is a further step necessary to install the binary and script files.
I did not find any notes about this in the README.linux.
Yes, sorry about that. This is of course always true on my machine. I'll fix that poor bit of bootstrapping in the full release.
In the meantime, just create a file - any file, even just an empty text file - called "catalina" in the /opt/pxc/bin directory. The scripts check that to make sure that LCCDIR points to something that exists, but I shouldn't be assuming that the catalina binary itself exists!
Then everything should work as expected.
My current process:
Preparation as root:
Preparation as user:
As you see in the last command line, I have to explicitly set the executable-flag for catalina.
This is because touch crates a file without exec-permissions, and during the installation only the file-content gets updated, not the whole file.
But this should change when the touch-workaround is not necessary anymore.
My installation directory now looks like this: (/opt/pxc)
. └── bin ├── bindump ├── blackbox ├── catalina ├── catbind ├── catdbgfilegen ├── p2asm ├── payload ├── spinc ├── srec_cat ├── srec_cmp └── srec_info 1 directory, 11 filesWhen I execute catalina I get the following error:
I just run build_all from the lcc-directory and got the following error:
The overall-build_all script does not check if the called build_all-scripts succeeded.
You could add something like this:
cd ../lcc ./build_all if [ $? -ne 0 ] ; then echo -e "\e[1;31mBuilding lcc failed!\e[0m" exit 1 fi # ...The problem with stubs-32.h is, that is only available in 32bit versions of the libc says the GCC FAQ.
Of cause a 64bit System does not provide this if you not explicitly install the multilib-version which then comes with a complete 32bit subsystem.
I tried to remove the "-m32" flags from the lccs makefile, but now I get the following error:
I also found a warning:
1.: It indicated the directory the binaries installation directory.
2.: It points to the root directory of the source code in that the temporary object files will be created.
These are the changes I applied to the lcc/makefile (line 11, 12, 20):
7 ifeq ($(OS),Darwin) 8 CFLAGS=-g -m32 9 LDFLAGS=-g 10 else 11 CFLAGS=-g -static 12 LDFLAGS=-g -static-libgcc 13 endif 14 15 ifeq ("$(LCCDIR)", "") 16 BINDIR=/usr/local/lib/catalina/bin 17 BUILDDIR=/usr/local/lib/catalina/source/lcc/build 18 else 19 BINDIR=$(LCCDIR)/bin 20 BUILDDIR=./build 21 endifNow lcc builds.
Next problem:
There are some hard-coded pathes…
Yes, I can see that a whole bunch of files - not just the lcc files - are missing from your "bin" directory.
It appears you are unzipping Catalina in your downloads directory but then setting the LCCDIR to where you want the output of the build to go. That will not work. The build needs to be done in the catalina subdirectory you just unzipped. One reason is that there is a whole bunch of support files that you need, not just the binaries.
Go to where you unzipped the distribution - your download directory is fine - then set the LCCDIR environment variable to the catalina subdirectory, and build it there. You can later copy (or move) the entire contents of the catalina subdirectory to /opt/pxc if you like, and then set your LCCDIR environment variable to that directory.
Also, one thing that you will find in the bin directory of the distribution is a "Set_Linux_Permissions" script that should help you with some file permission problems.
Here is what I mean:
I think this will solve your problem. Even simpler might be to unzip the distribution to /opt in the first place, rename catalina to pxc and build it "in situ".
Let me know how you go!
EDIT: I just realized you shouldn't need the "touch" and "chmod" commands.
The problem is, that etc/catalina_linux.c seems not to be informed that LCCDIR ist defined and so the #ifndef statement gets true and LCCDIR gets overwritten with the default value.
I did a further modification of the makefile:
The problem of your proposed approach is, that the permissions are all set to executable when unzipping the zip file. (This can be solved by using tar as archive format).
As I see in the Set_Linux_Permissions script, there also for all files, everyone has not only execution-permission but even worse, everyone get write permission. (a+wx).
This is an administrative and a security nightmare.
I'd prefer a clean and tidy installation where only programs have execution-permissions and nobody except me has write access
Next problem solved:
missing build_all call in the overall build_all scripts: lib/build_all -- EDIT: Sorry, is called in the script, but it seems not to be executed for some reason…
Is it correct that only directories with "_p2" suffix (Propeller V2?) were created?
Further big problem:
The build process of srecord is completely broken.
There the LCCDIR variable gets not applied inside the configure and make process.
This won't matter if you set the LCCDIR environment variable. That overrides any hard-coded path.
You shouldn't need to do any source or script modifications if you follow the instructions I posted above.
And yes, I should release a tar package instead of a zip file. I do that for the "official" releases (the last one was 3.13.2), but am not spending a lot of time on packaging in this current stream of P2 releases. There's too much other stuff to do.
There is a script to add the catalina directory to your path:
The permission are also all a+wx, but at least the binaries are 64bit.
I'll try to install it properly tomorrow and will post the steps in this thread.
Many thanks so far.
I have a script in /etc/profile.d where all my cross compilers were added to the PATH-variable. I also added the path to /opt/pxc/bin there
That's probably a good idea, although the binaries in the 3.15.4 release were also built and tested on a 64 bit system, so if they didn't work for you then you may still have to recompile.
If you do have to do so, please follow the build instructions (similar to the ones I wrote above) in README.Linux file.
You should not have to modify any sources or scripts.
Ross.
The first modification of the makefile was mandatory to remove the flags that makes GCC build a 32bit version.
The second one was necessary to propagate the shell environment variable LCCDIR to the C preprocessor.
The old 3.13.4 version also contains only a 32 bit version of lcc. So these binaries also don't work.
In fact getting Catalina to work is too time consuming and the current software state is a bit too "wild" and experimental.
I will stop trying it at this point and go a different direction. A C-Compiler would have bin nice, but for my purpose the assembler and programmer will be enough.
Nevertheless I'll follow the progress of Catalina and give it a chance with the next releases.
Thank you very much for your support.
You seem to be confusing "32 bit versions" with "built to run on a 32 bit version of Linux". I no longer even have a 32 bit version of Linux - the current binaries (13.5.4) were compiled on a 64 bit version of Linux using a 64 bit version of GCC, and will run correctly on a 64 bit version of Linux, whether or not they are 32 or 64 bit applications. Ditto for the 64 bit distributions of the earlier versions.
At present, I run Ubuntu 16.04 (64 bit) and nothing else. If the binaries in the distributions do not run on your installation, it is most likely because they were compiled for a different flavour of Linux, and not because they were compiled as 32 bit or 64 bit. All you need to do is recompile them.
If you follow the simple instructions I have provided, you can get Catalina working on your version of Linux. It is not necessary to change any source files or scripts. LCC is not really a 64 bit application in any case, and so trying to modify the scripts to compile it as 64 bit application is neither necessary nor particularly desirable.
Ross.
I run Arch Linux that (by default) does not support executing 32 bit applications at all. Which is quiet common for non-debian-bases distributions.
So you want to compile programs for a 32 bit microcontroller, but you don't want to enable 32 bit support on Arch Linux?
I suggest you wait until Parallax releases a 64 bit version of the Propeller
I also write programs for 8bit architectures on my 64 bit Linux.
My laptop has a 64 bit CPU and I see no reason why I should use a deprecated instruction set from the 90th for it.
Exactly.