I'll probably revise that script, add a couple of command line options etc., and add it to the FAQ page later this week. (Unless one of you beats me to it.)
I'd like to have $TARGET be configurable, for example...
using djgpp problem
Re:using djgpp problem
Every good solution is obvious once you've found it.
-
AR
Re:using djgpp problem
I can't get it to reupload (something about the upload folder being full but whatever).
Those are configurable; prefix, target and build/host can all be changed using command line parameters (./gcccross.sh --help).
Those are configurable; prefix, target and build/host can all be changed using command line parameters (./gcccross.sh --help).
Re:using djgpp problem
How about hosting it as an SF project? They have bandwidth left for people doing opensource projects, and I think I've seen a few people using SF just for binary distribution of some existing programs.
Not using the newest version, not a problem. If you want a version that doesn't exist on the site yet, make your own. The FAQ still exists. If you want a hosted environment, dito.
I think that 80-100% of the people here do use gcc for their OS, would like to use a compiler that was built for OS development and don't require anything fancy such as a standard library (hm... that sounds weird). So, a simple crosscompiler as generated by the script would suffice.
Oh and Brendan, when you can explain to me how to compile my 64-bit assembly with NASM I'll start using nasm again
.
Not using the newest version, not a problem. If you want a version that doesn't exist on the site yet, make your own. The FAQ still exists. If you want a hosted environment, dito.
I think that 80-100% of the people here do use gcc for their OS, would like to use a compiler that was built for OS development and don't require anything fancy such as a standard library (hm... that sounds weird). So, a simple crosscompiler as generated by the script would suffice.
Oh and Brendan, when you can explain to me how to compile my 64-bit assembly with NASM I'll start using nasm again
.Re:using djgpp problem
Not for me, thanks. I think the Cygwin people already do a terrific job with their setup.exe which I am not in a mind to duplicate.
If the relevant FAQ pages aren't enough to get someone to the starting line with a GCC cross-compiler, either the FAQ pages aren't good enough or the person in question doesn't qualify for OS-level development in the first line. IMHO.
If the relevant FAQ pages aren't enough to get someone to the starting line with a GCC cross-compiler, either the FAQ pages aren't good enough or the person in question doesn't qualify for OS-level development in the first line. IMHO.
Every good solution is obvious once you've found it.
-
Xardfir
Re:using djgpp problem
Hiya,
OK, OK. Why don't I switch on the -Wall option? The reason I don't is that I usually fill my header files with variables and do 'test compilations' to see if I've screwed up in typing (my fingers work faster than my brain). GCC spits the dummy complaining that "Such and such hasn't been used yet, so I won't bother compiling". I'll accept that my style of programming is probably 'not normal', but I doubt anyone can claim to be normal, specifically if there's a suggestion to using a common tool chain. Yes, undoubtably it would make everyone's job easier when asking and responding to questions, but to me the suggestion feels like the old Microsoft "One Version of Windows for All."
So after that a constructive suggestion:
Ask people to list of the different packages being used
ie: GCC 4, Binutils 9.11, Cygwin Version 999.
Then ask that people attach the above when asking a question, perhaps in their profile sidebar?.
This way regardless of *what* question a person asks, the person responding can immediately see what system they are dealing with without confusion, legacy or not.
This will also give everyone an idea of what packages are being used and allow more targeted advice to be given. Even if it is "upgrade to version x of utility y".
Would this be workable?
OK, OK. Why don't I switch on the -Wall option? The reason I don't is that I usually fill my header files with variables and do 'test compilations' to see if I've screwed up in typing (my fingers work faster than my brain). GCC spits the dummy complaining that "Such and such hasn't been used yet, so I won't bother compiling". I'll accept that my style of programming is probably 'not normal', but I doubt anyone can claim to be normal, specifically if there's a suggestion to using a common tool chain. Yes, undoubtably it would make everyone's job easier when asking and responding to questions, but to me the suggestion feels like the old Microsoft "One Version of Windows for All."
So after that a constructive suggestion:
Ask people to list of the different packages being used
ie: GCC 4, Binutils 9.11, Cygwin Version 999.
Then ask that people attach the above when asking a question, perhaps in their profile sidebar?.
This way regardless of *what* question a person asks, the person responding can immediately see what system they are dealing with without confusion, legacy or not.
This will also give everyone an idea of what packages are being used and allow more targeted advice to be given. Even if it is "upgrade to version x of utility y".
Would this be workable?
Re:using djgpp problem
I don't really got the concept, but how about using [tt]#ifndef NDEBUG[/tt] conditional compilation? That way, you get the "test compilation" when not specifying anything, and the "release compilation" when calling [tt]gcc -DNDEBUG[/tt]. Works nicely with [tt]<assert.h>[/tt], too, which uses the same preprocessor symbol to mask out assert()s.Xardfir wrote: OK, OK. Why don't I switch on the -Wall option? The reason I don't is that I usually fill my header files with variables and do 'test compilations' to see if I've screwed up in typing (my fingers work faster than my brain). GCC spits the dummy complaining that "Such and such hasn't been used yet, so I won't bother compiling".
If you have to disable -Wall for anything, rethink your approach. That's throwing the baby out with the bath water.
Whatever works for you. But running GCC without -Wall (and preferably several other error-checking options) is like driving blind with no seat-belt on. C is a very error-prone language, and you should accept any help you can get to catch errors at compile time instead of run time.I'll accept that my style of programming is probably 'not normal'...
That is what any serious software developer should do on his / her own when posting a support request anywhere. Unfortunately, the art of writing a bug report is even less common than the art of writing documentation: Most developers consider it beneath their state...Ask people to list of the different packages being used
ie: GCC 4, Binutils 9.11, Cygwin Version 999.
Then ask that people attach the above when asking a question, perhaps in their profile sidebar?.
This way regardless of *what* question a person asks, the person responding can immediately see what system they are dealing with without confusion, legacy or not.
Every good solution is obvious once you've found it.
-
Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:using djgpp problem
gcc -Wall -no-Wunused ?Xardfir wrote:
GCC spits the dummy complaining that "Such and such hasn't been used yet, so I won't bother compiling".
We had a similar project a year or two ago: OS IDcard ... we even had a cute database, but since newbies (those for which we wish to have more clues) don't bother to fill it, it proved to be of little use.So after that a constructive suggestion:
Ask people to list of the different packages being used
ie: GCC 4, Binutils 9.11, Cygwin Version 999.
Then ask that people attach the above when asking a question, perhaps in their profile sidebar?.
This way regardless of *what* question a person asks, the person responding can immediately see what system they are dealing with without confusion, legacy or not.
This will also give everyone an idea of what packages are being used and allow more targeted advice to be given. Even if it is "upgrade to version x of utility y".
Would this be workable?
-
Xardfir
Re:using djgpp problem
Hiya,
After much thought and looking and much humble word eating chez Xardfir, it appears that -Wall does work after all. The main complaint it makes is "implicit declaration of function x()".
I found that by declaring the function as an extern function in the C header file for the module, the complaint goes away as the function is no longer "implicit". Unfortunatley there are a lot of shall we say 'interweaving' of the object files and this is what causes all of the complaints.
The compile still works fine because, LD links everything correctly together and the kernel, drivers and interface start from GRUB, but as you can see, the source code could get messy keeping GCC happy.
-Wno-implicit-function-declaration eliminates the messages without disturbing anything else, but is there a neater way of doing so?
Thank you in advance for any enlightenment and your patience!
After much thought and looking and much humble word eating chez Xardfir, it appears that -Wall does work after all. The main complaint it makes is "implicit declaration of function x()".
I found that by declaring the function as an extern function in the C header file for the module, the complaint goes away as the function is no longer "implicit". Unfortunatley there are a lot of shall we say 'interweaving' of the object files and this is what causes all of the complaints.
The compile still works fine because, LD links everything correctly together and the kernel, drivers and interface start from GRUB, but as you can see, the source code could get messy keeping GCC happy.
-Wno-implicit-function-declaration eliminates the messages without disturbing anything else, but is there a neater way of doing so?
Thank you in advance for any enlightenment and your patience!
Re:using djgpp problem
Try declaring all functions for a given c file in the accompanying header file, not including header files in other header files (*) and including all relevant headers in a C file?Xardfir wrote: Hiya,
After much thought and looking and much humble word eating chez Xardfir, it appears that -Wall does work after all. The main complaint it makes is "implicit declaration of function x()".
I found that by declaring the function as an extern function in the C header file for the module, the complaint goes away as the function is no longer "implicit". Unfortunatley there are a lot of shall we say 'interweaving' of the object files and this is what causes all of the complaints.
The compile still works fine because, LD links everything correctly together and the kernel, drivers and interface start from GRUB, but as you can see, the source code could get messy keeping GCC happy.
-Wno-implicit-function-declaration eliminates the messages without disturbing anything else, but is there a neater way of doing so?
Thank you in advance for any enlightenment and your patience!
(*) -> You of couse must violate this rule for headers such as stdint.h, but they are of a different level. Prefer to include as few as reasonably possible, since it'll speed up your compiles.
-
Xardfir
Re:using djgpp problem
Hiya,
Hmmm, the header files are as simplified as possible with only one or two #includes at most per c file. I examined my copy of Harvey & Paul Deitels (C-how to program) and defining functions as 'extern' in the header files per C file is shown to be 'good programming practice'. I can understand the idea as I can then see from the header file which functions are used per C file.
Of course commenting 'where' that actual function externs to would then be necessary. Looks like I have some typing to do!
Thanks again.
<Edit>
I've just noticed a thread in the 'general programming forum' about functions and prototypes. Will continue there if there I experience any more wierdness as this is more of a general programming topic.
</edit>
Hmmm, the header files are as simplified as possible with only one or two #includes at most per c file. I examined my copy of Harvey & Paul Deitels (C-how to program) and defining functions as 'extern' in the header files per C file is shown to be 'good programming practice'. I can understand the idea as I can then see from the header file which functions are used per C file.
Of course commenting 'where' that actual function externs to would then be necessary. Looks like I have some typing to do!
Thanks again.
<Edit>
I've just noticed a thread in the 'general programming forum' about functions and prototypes. Will continue there if there I experience any more wierdness as this is more of a general programming topic.
</edit>
-
ohula
Re:using djgpp problem
I have downloaded cygwin and compiled a cross compiler. Now ready to use.
But do I have to use cygwin's shell or could I use my compiler from dos box?
But do I have to use cygwin's shell or could I use my compiler from dos box?
-
Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:using djgpp problem
as long as you use a dos box, dos' limitations about command line will hold, so you should certainly prefer cygwin's shell unless you have strong reasons to stick to a dos box ...ohula wrote: I have downloaded cygwin and compiled a cross compiler. Now ready to use.
But do I have to use cygwin's shell or could I use my compiler from dos box?
i mean reasons that cannot be supplanted by the use of
Code: Select all
alias dir = "ls -l"
-
AR
Re:using djgpp problem
command.com (DOS Command Prompt) has a 127 character limit. If the target program is DOS based then it has 127 character limit regardless of how it was launched. However, a 32bit build (Cygwin, MinGW, etc) launched using CMD.exe (Windows Command Prompt for NT) has a 32767 character limit.
The main problem with using the cross-compiler without the Cygwin shell is "DLL Hell", ie. the compiler executables will not be able to find the DLLs (Cygwin1.dll and something else that I can't remember), to get it to work you will have to add \Cygwin\bin to the PATH or at least copy the 2 DLLs into the cross-compiler's BIN folder.
The main problem with using the cross-compiler without the Cygwin shell is "DLL Hell", ie. the compiler executables will not be able to find the DLLs (Cygwin1.dll and something else that I can't remember), to get it to work you will have to add \Cygwin\bin to the PATH or at least copy the 2 DLLs into the cross-compiler's BIN folder.