using djgpp problem

[ohula]

I compile my kernel main function like this:

Code: Select all

gcc -g -Wall -c -fno-builtin main.c main.o

I got this error but have no such variable.

__dj_ctype_flags.

I got variable cytpe_flags. I use -fno-builtin parameter but I think it still uses djgpp definitions. What should I do??

[Pype.Clicker]

define the variable ?

honnestly, DJGPP is now a piece of legacy. Unless you're developping/porting tools to MS-DOS, you shouldn't use it. Consider using CYGWIN -- preferably a cross-compiler version -- instead: that will save you days of fighting between your "native" environment and YourOS environment.

[Xardfir]

Try adding -nodefaultlibs -nostdlib. The variable is in DJGPP's built in library file. Also get rid of the -Wall option, GCC whinges immensely when this is turned on for absolutley no reason.
I would also highly reccommend using the ELF-version of binutils http://membres.lycos.fr/placr/binutils.html.
Using this binutils will prevent you from writing 'application code' in DJGPP, but your not writing apps are you? and the apps written for your OS will probably not be linked to a standard library anyway if the OS isn't POSIX based.
The ELF file format will also facilitate linking with assembly code (some is necessary eventually!)

And for the record, I switch between Redhat Linux and Windows and Linux GCC nor DJGPP GCC have had any problems in the last 5 years.

[ohula]

Consider using CYGWIN -- preferably a cross-compiler version -- instead

I ll download the cygwin package from http://cygwin.com/. Does that package enough or do I have to download a different compiler - a cross-compiler? If so where can I download it from?

[Solar]

I ll download the cygwin package from http://cygwin.com/. Does that package enough or do I have to download a different compiler - a cross-compiler? If so where can I download it from?

Check the FAQ on Cygwin and the FAQ on GCC Cross-Compiler.

If you click through the setup without changing anything, you get a basic environment without GCC. That's OK; just start the setup again, and select "gcc" from the "devel" group.

Then follow the GCC Cross-Compiler instructions. They have been set up to avoid problems exactly like yours.

[Solar]

I would also highly reccommend using the ELF-version of binutils...

Unless any specific reasons speak against it, it would be helpful if all such questions regarding "esoteric" development environments are answered with the Cygwin / GCC Cross-Compiler combo I posted above. The idea is to have as many of the OS dev'ers on this board on the same development platform (the GCC Cross-Compiler hosted on either Linux or Cygwin) - this makes reproducing and hunting down bugs much, much easier.

[Candy]

I would also highly reccommend using the ELF-version of binutils...

Unless any specific reasons speak against it, it would be helpful if all such questions regarding "esoteric" development environments are answered with the Cygwin / GCC Cross-Compiler combo I posted above. The idea is to have as many of the OS dev'ers on this board on the same development platform (the GCC Cross-Compiler hosted on either Linux or Cygwin) - this makes reproducing and hunting down bugs much, much easier.

Would you like some default binary packages with that?

[Solar]

Would you like some default binary packages with that?

Huh?

[Candy]

Would you like some default binary packages with that?

Huh?

that was a pun on how mcdonalds people ask if you want mayonaise with your french fries. You proposed everybody to use the same crosscompiler. For newbies it's a lot easier if they can just download a binary package containing the relevant compilers and assemblers ready for use. Especially since some of our cross-compiler compile methods seem to fail but actually already have succeeded.

I think we'd help a lot of people if we built a complete tool chain ready for use and configured as crosscompiler. IE, making a default OS dever package to compile with.

[Brendan]

Hi,

I think we'd help a lot of people if we built a complete tool chain ready for use and configured as crosscompiler. IE, making a default OS dever package to compile with.

I think this would help lots of people.

I also think you'd need someone to port the binary packages to every OS, handle configuration/installation problems and maintain the binary packages.

Of course this adds up to a huge amount of work. For me, it'd make much more sense if everyone just used NASM. ;D


Cheers,

Brendan

[Pype.Clicker]

Also get rid of the -Wall option, GCC whinges immensely when this is turned on for absolutley no reason.

[tt]0_o[/tt] aargh. no! don't! ... -Wall is your friend, especially in OSDev...

"ptr could be used without being assigned a value first"
"reached end of from MyObjectConstructor without a _return_ statement"
"value assignment where condition expected. Use ((x=1)) if you didn't mean (x==1)"

These are all your friends. Honestly. They will make your coding easier.

[AR]

I've already written a shell script to automate building a cross compiler, it isn't high quality (I don't write complicated shell scripts very often) but it seems to work well enough, I'll post it if anyone is interested. (I haven't tested it on Linux but it doesn't use anything specific to Windows and stays in the GNU toolchain so should work on it as well)

[ohula]

Yeah, I aggree with most of you. It would be nice to prepare a binary package, also create a tools section on mega-tokyo and put os related documents, such as ready-to-use-cygwin pack, and babysteps..etc. Anyway, AR, Ill be glad if you send that script.

[Solar]

As for the distribution of binary packages... you'd have to bundle a package for Windows and one for Linux, both being several megabytes in size, generating quite some traffic in downloads. They would be outdated by newer versions of binutils and / or GCC every other month or so, generating yet more traffic. Some projects would prefer to stick to a previous compiler version, while other projects jump ahead to the latest beta of GCC. You'd get many support requests when something malfunctions with your bundle, which would very likely something broken upstream, not by your bundle. Someone would have to watch out for new versions of binutils / GCC every other day or so or people will cry bloody murder.

And, the cross-compiler page in the Wiki goes only to the point where you would compile your C library of choice to get your "finished" development environment. Since different people will chose different C libs, even those binary packages would only go part of the way.

Not to speak of Windows people perhaps wanting other tools from the Cygwin collection, too, and the hassle arising from mixing your (possibly outdated) Cygwin bundle with stuff installed by cygwin.com/setup.exe.

All in all, I think binary packages aren't worth the workload and hassle. Someone tinkering with OS development should be able to follow the instructions in the FAQ; in any way, you learn something about the innards of binutils and GCC, which I intend to elaborate on if I ever get back to the point of doing OS dev'ing...

[Pype.Clicker]

well, if we manage to get something like that (and man, that may be *huge* -- think of all those datasheets), we serve it with BitTorrent -- or poor df will see his bandwidth exploding ...