I can fix the directory permissions in the next release, but pax will fix the problem for all past releases as well (and for future releases if the the same problem occurs again). Of course, so would using tar as root, but I can see Heater's point that some Linux users might object to that.
Pax just cures a mistake that should not have happened.
Just build/package future releases as non-root.
Then this wil not happen again without being noticed.
Catalina's tarball does not contain files owned by different users and no setuid/setgid executables. So I assume building and packaging Catalina as unprivilleged user will be possible.
Pax just cures a mistake that should not have happened.
Just build/package future releases as non-root.
Then this wil not happen again without being noticed.
Catalina's tarball does not contain files owned by different users and no setuid/setgid executables. So I assume building and packaging Catalina as unprivilleged user will be possible.
I will recommend the use of pax in future, but I am aware that most Linux people when faced with a tarball will probably not read the instructions anyway and continue to use tar. That's fine - those are probably the same linux users would know what to do if they get the "Permission denied" error that Heater reported.
And yes, you can build Catalina as an unprivileged user if the file permissions are ok - which they will be if you use pax. **
Ross.
** edit: Just tried this, and if you are not building as root you first have to execute chmod -R a+x * even after unpacking with pax,
What I find amazing is that I have been installing hundreds of programs from tarballs over the last two decades. Often building the code from sources.
How come I have never heard of pax before? Is RossH it's only user?
A little research reveals that pax is not very much used and not installed by default on any Linux distribution.
Seems it is used by the Mac installer. Which is obviously where the origin of our problem lies.
I don't know where you've been since the turn of the century but pax is a posix standard utility, designed to solve the problems that plague both tar and cpio. I believe it has been around since 1999, and it was made part of the posix standard in 2001. It is required to be supported on Linux, but (like many other packages, including gcc for that matter) is not usually installed by default.
Yes, it is most popular on OSX. So while I am definitely not it's only user, I do agree there would not be as many pax users as there are tar users. That's because most people (including me, BTW!) tend to solve the same problem that pax solves by using sudo tar - which is what I originally suggested.
So I have offered you two solutions to your problem. If you don't want to use either one, then I'm running out of suggestions. Perhaps you could install Windows or OSX instead of Linux?
Let's say a visit my local gun dealer and ask him if I can try out a nice hand gun, that I have had my eye on for a long time, on the firing range.
"Certainly Sir" he says. On the range he says "I think you find it's a very fine weapon Sir, Now, to get the feel of it first I want you to look down the barrel and pull the trigger".
Being stupid, or exceptionally trusting, that's exactly what I do. BOOM!
Amazingly I'm not dead. What actually occurred is that the gun exploded spraying bullets and shrapnel in all directions killing some of my friends who were standing by watching.
Needless to say this is a no sale situation.
"But Sir" says the gun dealer "You were holding it wrong".
The End.
This is what the Catalina package is like:
a) Look down the barrel and pull the trigger by unpacking it as root.
b) It kills all my friends by spraying files all over whatever directory I am working in.
c) I was obviously holding it wrong, didn't read the instructions.
...designed to solve the problems that plague both tar and cpio.
So I have read. What problems? All the world over has been using tar without complaint. cpio has been obsoleted for years so nobody cares.
It is required to be supported on Linux,
There is no such governing body that can "require" any such thing. The Linux Standard Base has included it in their standard. Nobody cares much about LSB. Tar does have some support for PAX anyway.
...most people (including me, BTW!) tend to solve the same problem that pax solves by using sudo tar
Shocking. That is inviting us to look down the barrel of that gun. It's also passing an error in the packaging onto the user to deal with. The problem should be fixed at source.
Of course this is not actually a problem for me personally. I'm the kind of guy who will struggle with such issues until I'm blue in the face if need be. There are plenty of programs orders of magnitude harder to install and configure than Catalina.
I do have solutions though:
a) Assume the package is broken, which it is, and drop the whole idea.
b) Suggest the author fix the problem and wait for the next release.
c) Use propgcc which does not behave so unsocially.
d) Or, just pull the trigger
P.S. That pax thing is a pile of chicken entrails no wonder no one uses it. I pulled the trigger, look what happened:
Strangely enough I now recall that recently a colleague of mine came to me with a problem about file permissions on his Linux machine.
The exact same symptoms.
We put this down to the fact that his files had been fetched from a network share also use by his Windows and Mac machines. We never bothered to track down who the guilty party was.
Perhaps this has also happened with you whilst working on Catalina on various machines?
Strangely enough I now recall that recently a colleague of mine came to me with a problem about file permissions on his Linux machine.
The exact same symptoms.
We put this down to the fact that his files had been fetched from a network share also use by his Windows and Mac machines. We never bothered to track down who the guilty party was.
Perhaps this has also happened with you whilst working on Catalina on various machines?
Actually, that is exactly what I do. I use a shared drive to move stuff between Windows and Linux. The funny thing is that everything works fine for me under both Windows and Linux, whether I am logged in as root (or administrator) or not.
But you may have spotted the problem - I guess network shared drives may mess up the permissions somewhow.
I downloaded catalina_3.12_Linux32 gain, to a different 64 bit Debian machine.
After unpacking with pax things are in the same state I reported above.
After the chmod everything is accessible as we might expect.
Of course we now have execute permissions on everything!
Better to fix it with something like:
find -type d -name "*" -exec chmod a+x "{}" \;
Yes, this was just a workaround to get you up and running without having to log in as root or use sudo.
In the next release I'll just make everything readable in the tar file, and update the "Set_Linux_Permissions" script to do all the necessary permission modifications.
So, I downloaded and installed Catalina C, but I was not able to find a manual that explains how to implement or use the six points that you highlighted in the other thread. The CodeBlocks QuickStart file was very helpful in how to get your first project started, but how do you start to use the features of the Propeller are still lacking, or at least I do not know where to find the information. Maybe when I get my hands on the Catalina C manual, then everything will become so much clearer as to why I should be using Catalina C.
I did get a blinker program coded and working, but that was strictly from guess work and experience that I got from using the other C learning system. I will hold back with thoughts about Catalina C until I have experimented with all the features that are supposed to make my experience with the Propeller so much better, using this C learning system.
So, I downloaded and installed Catalina C, but I was not able to find a manual that explains how to implement or use the six points that you highlighted in the other thread. The CodeBlocks QuickStart file was very helpful in how to get your first project started, but how do you start to use the features of the Propeller are still lacking, or at least I do not know where to find the information. Maybe when I get my hands on the Catalina C manual, then everything will become so much clearer as to why I should be using Catalina C.
I did get a blinker program coded and working, but that was strictly from guess work and experience that I got from using the other C learning system. I will hold back with thoughts about Catalina C until I have experimented with all the features that are supposed to make my experience with the Propeller so much better, using this C learning system.
Ray
Hi Ray,
I think I've answered some of your questions over on the other thread. I'm currently busy packaging up a Linux release of Catalina 3.13, but if you still have any questions after that, by all means let me know.
Linux distributions for Catalina 3.13 now available - see the links in the first post of this thread.
I have made significant improvements in the way you build and install under Linux. Here is an extract from the README.Linux file:
A NOTE ON BUILDING CATALINA UNDER LINUX
=======================================
Catalina can now be build under linux with a just a few commands, provided
all the required packages have been installed (at least gcc-G++, flex, bison,
libtool and unzip).
Also, Catalina can now be built anywhere, without requiring root permission.
Also, Catalina can now be installed anywhere (but installing it to its default
location of /usr/local/lib/catalina probably still requires root permission).
However, currrently Code::Blocks will only work correctly if Catalina is
installed in the default location (/usr/local/lib/catalina). This will be
fixed in a subseqent release.
To build Catalina, unpack the tar file using tar or pax, and then do the
following:
cd Catalina_3.13
LCCDIR=$PWD
export LCCDIR
source use_catalina
cd source
./build_all
To use Catalina, set the LCCDIR environment variable to wherever you have
installed Catalina - this can be done in your profile - and then execute
the following command in any command shell:
source $LCCDIR/use_catalina
Now you are ready to use Catalina!
I will make similar improvements in building the Windows version from source in the next release - this is not so critical for Windows, since the Windows installer already allows you to install and run Catalina from an arbitrary location.
Also I was surprised to find I need to install a 100MB of boost C++ library. Never needed that before. Do we really need C++ to build a C only compiler?
Edit: Oh wait. It did build a catalina executable in catalina/catalina. It just can't find it.
Edit: Oh wait. It did build a catalina executable in catalina/catalina. It just can't find it.
Your error message indicates you are starting to build the library, but catalina and lcc have not yet been built correctly. Or the path to the catalina executables has not been set up correctly. The instructions I gave may be specific to the bash shell. If you are using something else, you may need to adjust the command used to set the LCCDIR environment variable, or to execute the use_catalina script. All that script does is set the PATH environment variable, which you can do manually if you need.
If you open a new command shell to build in, make sure LCCDIR and the PATH are set correctly (or that you have executed source use_catalina). Then try building the components one by one:
cd source/catalina
./build_all
cd ../lcc
./build_all
cd ../openspin
./build_all
cd ../lib
./build_all
I believe the boost libraries are required only for the srecord utilities. I don't believe anyone except me ever uses those, so you can skip that if you want. I should make it clear that this part is optional.
Something I forgot to include in the notes for the latest Linux release was that I found some issues with the example Code::Blocks workspaces and projects that are provided to build the various demo programs.
Workspaces that just build C programs are identical under both Windows and Linux, but those that also build Spin programs (using spinc orspinnaker) need different versions for Linux (e.g. to use / rather than \ as a path separator).
There are two workspaces affected (proxy_demos and spinc_demos). In both cases I have added a "_linux" version, which contain modified projects appropriate for linux.
So Windows users should continue to use the proxy_demos and spinc_demos workspaces in Code::Blocks.
Linux users should instead use the proxy_demos_linux and spinc_demos_linux workspaces.
I now seem to have the Linux and OSX build procedures cleaned up and sorted out, but I am having problems doing the same with Windows. Unlike Unix-based systems, Windows allows spaces in path names, and this really confounds the Unix make utility. Currently, I have to get around this by using short path names, but I can't find a way to automate this process of generating the short path names.
So I have a question whether any Windows Catalina users really ever build Catalina from source?
If so, is it a problem that this currently requires you to edit some of the build scripts and make files to insert the correct short path names?
I'm just wondering whether I'm wasting my time trying to automate the process.
I now seem to have the Linux and OSX build procedures cleaned up and sorted out, but I am having problems doing the same with Windows. Unlike Unix-based systems, Windows allows spaces in path names, and this really confounds the Unix make utility. Currently, I have to get around this by using short path names, but I can't find a way to automate this process of generating the short path names.
So I have a question whether any Windows Catalina users really ever build Catalina from source?
If so, is it a problem that this currently requires you to edit some of the build scripts and make files to insert the correct short path names?
I'm just wondering whether I'm wasting my time trying to automate the process.
Anyone?
Ross.
I thought I had built Catalina under Windows but it was a long time ago. Also, Linux does allow spaces in filenames. You have to put double quotes around the filenames when you use them on a command line. It is awkward to use paths with spaces though. That is certainly true.
By the way, I'm looking forward to building Catalina for the Mac!
...
Currently, I have to get around this by using short path names, but I can't find a way to automate this process of generating the short path names.
D'oh! Who was it who said you always find the answer just after you post the question? I spent hours on this last night, and 1 minute after posting here, I found the answer - which I am posting in case others have the same problem.
The solution is to use a batch file and do the following:
@echo off
if not "%2" == "" goto set_path
echo.
echo usage: set_short_path var_name long_path
echo.
goto done
:set_path
@echo %~fs2
SET %1=%~fs2
:done
I'll incorporate this into the Windows build_all batch files, and that should solve the "make" problem.
Catalina can now be recompiled with a single command under both Windows, Linux and OSX, with no need to edit any scripts, batch files or make files. Also, it can be compiled anywhere and installed anywhere without requiring any special permissions.
I don't believe anyone is crying out for this - I did it because it makes my life easier when I am building releases.
The new build scripts will be included in the next release.
Catalina can now be recompiled with a single command under both Windows, Linux and OSX, with no need to edit any scripts, batch files or make files. Also, it can be compiled anywhere and installed anywhere without requiring any special permissions.
I don't believe anyone is crying out for this - I did it because it makes my life easier when I am building releases.
The new build scripts will be included in the next release.
Ross.
Very nice! I'm looking forward to building it for the Mac.
Very nice! I'm looking forward to building it for the Mac.
Hi David,
I thought I'd better actually test this under OSX before I replied ... now done!
The current Catalina 3.13 Linux releases already have all the necessary updates for OSX, and will compile successfully on the Mac (I just did this on Mountain Lion).
If you do not have the Boost C++ libraries installed and compiled, then the srecord utilities will not compile - but they are optional, so if you don't actually use them this won't matter.
Note that the new build_all script is designed to work under the bash shell, and before you execute it, you need to set your LCCDIR environment variable. For example, here are the commands I used (after unpacking the tgz file on the desktop):
cd Catalina_3.13
LCCDIR=/Users/rossh/Desktop/Catalina_3.13
export LCCDIR
source use_catalina
cd source
./build_all
If you use a shell other than bash, you may need to adjust the above commands appropriately.
Note that if you are using the clang compiler, both lcc and openspin will generate some warning messages - but they compile ok. I don't really want to modify these programs (potentially introducing new errors) just to satisfy clang's pathological obsession about what constitutes good C style.
I downloaded the 64 bit Linux version of Catalina 3.13 and followed your instructions and it built fine. I have Catalina running on my Mac now!!
I was particularly impressed that your build process tests for the existence of the Boost C++ library and fails gracefully if it is missing. Nice job!
This is a real beginners question but how do I determine at compile time whether I'm using the Catalina C compiler? I'd like to add some #ifdefs to my program allow it to compile with Catalina but didn't find in a quick search through the docs if there is any preprocessor symbol defined automatically by the Catalina compiler. Is there something like _CATALINA_ or something like that that I can check for to conditionally include Catalina-specific code?
Edit: I figured this out myself. The symbol is called __CATALINA__.
Comments
Just build/package future releases as non-root.
Then this wil not happen again without being noticed.
Catalina's tarball does not contain files owned by different users and no setuid/setgid executables. So I assume building and packaging Catalina as unprivilleged user will be possible.
I will recommend the use of pax in future, but I am aware that most Linux people when faced with a tarball will probably not read the instructions anyway and continue to use tar. That's fine - those are probably the same linux users would know what to do if they get the "Permission denied" error that Heater reported.
And yes, you can build Catalina as an unprivileged user if the file permissions are ok - which they will be if you use pax. **
Ross.
** edit: Just tried this, and if you are not building as root you first have to execute chmod -R a+x * even after unpacking with pax,
How come I have never heard of pax before? Is RossH it's only user?
A little research reveals that pax is not very much used and not installed by default on any Linux distribution.
Seems it is used by the Mac installer. Which is obviously where the origin of our problem lies.
I don't know where you've been since the turn of the century
Yes, it is most popular on OSX. So while I am definitely not it's only user, I do agree there would not be as many pax users as there are tar users. That's because most people (including me, BTW!) tend to solve the same problem that pax solves by using sudo tar - which is what I originally suggested.
So I have offered you two solutions to your problem. If you don't want to use either one, then I'm running out of suggestions. Perhaps you could install Windows or OSX instead of Linux?
Ross.
I think it's time for an analogy:
Let's say a visit my local gun dealer and ask him if I can try out a nice hand gun, that I have had my eye on for a long time, on the firing range.
"Certainly Sir" he says. On the range he says "I think you find it's a very fine weapon Sir, Now, to get the feel of it first I want you to look down the barrel and pull the trigger".
Being stupid, or exceptionally trusting, that's exactly what I do. BOOM!
Amazingly I'm not dead. What actually occurred is that the gun exploded spraying bullets and shrapnel in all directions killing some of my friends who were standing by watching.
Needless to say this is a no sale situation.
"But Sir" says the gun dealer "You were holding it wrong".
The End.
This is what the Catalina package is like:
a) Look down the barrel and pull the trigger by unpacking it as root.
b) It kills all my friends by spraying files all over whatever directory I am working in.
c) I was obviously holding it wrong, didn't read the instructions. So I have read. What problems? All the world over has been using tar without complaint. cpio has been obsoleted for years so nobody cares. There is no such governing body that can "require" any such thing. The Linux Standard Base has included it in their standard. Nobody cares much about LSB. Tar does have some support for PAX anyway. Shocking. That is inviting us to look down the barrel of that gun. It's also passing an error in the packaging onto the user to deal with. The problem should be fixed at source.
Of course this is not actually a problem for me personally. I'm the kind of guy who will struggle with such issues until I'm blue in the face if need be. There are plenty of programs orders of magnitude harder to install and configure than Catalina.
I do have solutions though:
a) Assume the package is broken, which it is, and drop the whole idea.
b) Suggest the author fix the problem and wait for the next release.
c) Use propgcc which does not behave so unsocially.
d) Or, just pull the trigger
P.S. That pax thing is a pile of chicken entrails no wonder no one uses it. I pulled the trigger, look what happened:
WTF!?
pax is brain damaged. At least tar stops with an error when encountering a corrupt archive.
Amusing analogy. I lose more customers that way ...
However, pax works for me. So does sudo tar. If neither one is working for you, then I think you may actually have a corrupt copy of the archive.
I just downloaded it from sourceforge again to check it, and it appears to be ok there. Can you try downloading it again?
Then, in the directory you just saved the tgz file, do the following (you don't need to be root):
I am not at a Linux machine at the moment, but if anyone else who is could try this and report the results, I'd appreciate it.
Ross.
After unpacking with pax things are in the same state I reported above.
After the chmod everything is accessible as we might expect.
Of course we now have execute permissions on everything!
Better to fix it with something like:
find -type d -name "*" -exec chmod a+x "{}" \;The exact same symptoms.
We put this down to the fact that his files had been fetched from a network share also use by his Windows and Mac machines. We never bothered to track down who the guilty party was.
Perhaps this has also happened with you whilst working on Catalina on various machines?
Actually, that is exactly what I do. I use a shared drive to move stuff between Windows and Linux. The funny thing is that everything works fine for me under both Windows and Linux, whether I am logged in as root (or administrator) or not.
But you may have spotted the problem - I guess network shared drives may mess up the permissions somewhow.
Thanks,
Ross.
Yes, this was just a workaround to get you up and running without having to log in as root or use sudo.
In the next release I'll just make everything readable in the tar file, and update the "Set_Linux_Permissions" script to do all the necessary permission modifications.
Ross.
I did get a blinker program coded and working, but that was strictly from guess work and experience that I got from using the other C learning system. I will hold back with thoughts about Catalina C until I have experimented with all the features that are supposed to make my experience with the Propeller so much better, using this C learning system.
Ray
Hi Ray,
I think I've answered some of your questions over on the other thread. I'm currently busy packaging up a Linux release of Catalina 3.13, but if you still have any questions after that, by all means let me know.
Ross.
Linux distributions for Catalina 3.13 now available - see the links in the first post of this thread.
I have made significant improvements in the way you build and install under Linux. Here is an extract from the README.Linux file:
A NOTE ON BUILDING CATALINA UNDER LINUX ======================================= Catalina can now be build under linux with a just a few commands, provided all the required packages have been installed (at least gcc-G++, flex, bison, libtool and unzip). Also, Catalina can now be built anywhere, without requiring root permission. Also, Catalina can now be installed anywhere (but installing it to its default location of /usr/local/lib/catalina probably still requires root permission). However, currrently Code::Blocks will only work correctly if Catalina is installed in the default location (/usr/local/lib/catalina). This will be fixed in a subseqent release. To build Catalina, unpack the tar file using tar or pax, and then do the following: cd Catalina_3.13 LCCDIR=$PWD export LCCDIR source use_catalina cd source ./build_all To use Catalina, set the LCCDIR environment variable to wherever you have installed Catalina - this can be done in your profile - and then execute the following command in any command shell: source $LCCDIR/use_catalina Now you are ready to use Catalina!I will make similar improvements in building the Windows version from source in the next release - this is not so critical for Windows, since the Windows installer already allows you to install and run Catalina from an arbitrary location.
Ross.
It does not build on my Debian amd64 box, Seems I need catalina in order to build catalina!
Also I was surprised to find I need to install a 100MB of boost C++ library. Never needed that before. Do we really need C++ to build a C only compiler?
Edit: Oh wait. It did build a catalina executable in catalina/catalina. It just can't find it.
Your error message indicates you are starting to build the library, but catalina and lcc have not yet been built correctly. Or the path to the catalina executables has not been set up correctly. The instructions I gave may be specific to the bash shell. If you are using something else, you may need to adjust the command used to set the LCCDIR environment variable, or to execute the use_catalina script. All that script does is set the PATH environment variable, which you can do manually if you need.
If you open a new command shell to build in, make sure LCCDIR and the PATH are set correctly (or that you have executed source use_catalina). Then try building the components one by one:
I believe the boost libraries are required only for the srecord utilities. I don't believe anyone except me ever uses those, so you can skip that if you want. I should make it clear that this part is optional.
Ross.
Something I forgot to include in the notes for the latest Linux release was that I found some issues with the example Code::Blocks workspaces and projects that are provided to build the various demo programs.
Workspaces that just build C programs are identical under both Windows and Linux, but those that also build Spin programs (using spinc or spinnaker) need different versions for Linux (e.g. to use / rather than \ as a path separator).
There are two workspaces affected (proxy_demos and spinc_demos). In both cases I have added a "_linux" version, which contain modified projects appropriate for linux.
So Windows users should continue to use the proxy_demos and spinc_demos workspaces in Code::Blocks.
Linux users should instead use the proxy_demos_linux and spinc_demos_linux workspaces.
Ross.
I now seem to have the Linux and OSX build procedures cleaned up and sorted out, but I am having problems doing the same with Windows. Unlike Unix-based systems, Windows allows spaces in path names, and this really confounds the Unix make utility. Currently, I have to get around this by using short path names, but I can't find a way to automate this process of generating the short path names.
So I have a question whether any Windows Catalina users really ever build Catalina from source?
If so, is it a problem that this currently requires you to edit some of the build scripts and make files to insert the correct short path names?
I'm just wondering whether I'm wasting my time trying to automate the process.
Anyone?
Ross.
By the way, I'm looking forward to building Catalina for the Mac!
D'oh! Who was it who said you always find the answer just after you post the question? I spent hours on this last night, and 1 minute after posting here, I found the answer - which I am posting in case others have the same problem.
The solution is to use a batch file and do the following:
I'll incorporate this into the Windows build_all batch files, and that should solve the "make" problem.
Ross.
Just use the Linux sources and instructions. Let me know if you have any problems.
Ross.
You are quite correct. It is MinGW that doesn't handle spaces in filenames correctly, not Linux.
Ross.
That would be fine for me, but not for others who want to build it under Windows. Anyway, the problem is solved now (I hope!).
Ross.
Catalina can now be recompiled with a single command under both Windows, Linux and OSX, with no need to edit any scripts, batch files or make files. Also, it can be compiled anywhere and installed anywhere without requiring any special permissions.
I don't believe anyone is crying out for this - I did it because it makes my life easier when I am building releases.
The new build scripts will be included in the next release.
Ross.
Hi David,
I thought I'd better actually test this under OSX before I replied ... now done!
The current Catalina 3.13 Linux releases already have all the necessary updates for OSX, and will compile successfully on the Mac (I just did this on Mountain Lion).
If you do not have the Boost C++ libraries installed and compiled, then the srecord utilities will not compile - but they are optional, so if you don't actually use them this won't matter.
Note that the new build_all script is designed to work under the bash shell, and before you execute it, you need to set your LCCDIR environment variable. For example, here are the commands I used (after unpacking the tgz file on the desktop):
If you use a shell other than bash, you may need to adjust the above commands appropriately.
Note that if you are using the clang compiler, both lcc and openspin will generate some warning messages - but they compile ok. I don't really want to modify these programs (potentially introducing new errors) just to satisfy clang's pathological obsession about what constitutes good C style.
Ross.
I was particularly impressed that your build process tests for the existence of the Boost C++ library and fails gracefully if it is missing. Nice job!
Much as I'd love to take credit for it, all I do is call the standard srecord build process.
Ross.
I have just uploaded Catalina 3.13.2 to SourceForge.
This release provides major improvements to the Code::Blocks graphical development environment.
See the first post in this thread for more details and links (Windows only version for the moment - Linux versions will follow sone).
Edit: I figured this out myself. The symbol is called __CATALINA__.