I'm starting to learn how to write network device driver from:
http://tldp.org/LDP/LGNET/issue93/bhaskaran.html
In the article, the author compiles his example with:
cc -I/usr/src/linux-2.4/include/ -Wall -c rtl8139.c
My problem is that I'm using 2.6.35.23-generic and I don't have "config.h" in "/usr/src/linux_headers-2.6.35-23-generic/linux/".
Is this file replaced by another file? Is there any site that gives you information for such changes?
Thanks,
Pete.
The article http://tldp.org/LDP/LGNET/issue93/bhaskaran.html in your question is from 2003. I'm afraid the C code of Linux kernel changes too quickly, so the C code snippets and compilation instructions in that article most probably don't apply anymore.
Please also note that the article provides information about the 2.4.x Linux kernel versions, but you're trying to compile its code with a 2.6.x kernel. The 2.4 and 2.6 series are very different both in terms of C code and compilation instructions. My advice: try to find a more recent article (preferably from 2010 or 2009) and example code about the 2.6 series.
Related
In this documentation HP Fortran doc, the OPEN statement accept SHARED and READONLY options.
In this documentation Standard Fortran 2008 doc, the OPEN statement dosn't accept SHARED or READONLY options.
Since I'm using gfortran comes with gcc 4.4.7 to compile a Fortran source file on Linux,I used a ruse to get around half the problem. I used
OPEN(...,ACTION=READ,...) instead of READONLY.
But can't find an other ruse (:)) to replace SHARED Option. (Like Something=Shared).
Anyone have a ruse to get arround that?
Those IO extensions (SHARED, READONLY, etc) as well as other extensions, as would be available with DEC based Fortran should be available in GCC/gFortran via the "-fdec" and related compiler switches.
However, I found some confusion in the online GCC docs. Apparently, some older versions of gFortran (and in particular g77) may require the compiler to have been built with the libf2c element, and there may be differences on Unix (c.f. Win etc).
It is not clear exactly which versions of gFortran accept this. For example, under Windows, with GCC/gFortran 6.x, it would not recognise the "-fdec" switch.
Apparently, GCC/gFortran v7.x have all that working, but v7 is still in "development mode" ... are you feeling lucky :-) ?
Also, some references give dire warnings about reliance on "extensions".
Here are some pages of interest:
https://gcc.gnu.org/wiki/GFortran/News
https://gcc.gnu.org/onlinedocs/gfortran/Extended-I_002fO-specifiers.html
https://gcc.gnu.org/onlinedocs/gfortran/Option-Summary.html
https://gcc.gnu.org/onlinedocs/gfortran/Fortran-Dialect-Options.html
The last link seems particularly "dire" on the subject.
I am asking here because I have no idea where to find any information about this problem. If you could recommend me a book or an article about it, I would be pleased.
Where can I find any information about correlation between Linux kernel and GLIBC's version? I know that, the kernel itself contains implementation of libc's functions, but I do not know, how they are delivered to it.
For example:
Recently I had to build the kernel for an old PowerPC processor. It came with libc's dynamic library files in version 2.3.6 out-of-the-box. In /lib/ path there are files with names like librt.so-2.3.6.
What is the simplest way to update this lib to a newer version?
Is it possible to configure kernel's build system to make it generating uImage file with a newer GLIBC version or an alternative one (ex. EGLIBC)?
There is little correlation, the same kernel should work with a wide range of glibc versions, and viceversa. The library finds out what the kernel handles, and uses that. For the gory details of what has changed in glibc (this is what you interact with, including support for new kernel features), you should look at the upstream changelog. For new features in the Linux kernel, perhaps the best source are the periodical "What's new in..." articles the kernel section of LWN
I have a website teaching C for beginners.
I'm trying to have a C compiler online version so that a user could easily compile their code online itself.
Are there any compilers available? If available, which is the best one?
I have found some compilers, but they have got no capability of taking input from the user, but they have the capability of just displaying the output.
There is no package that can just be added to a blog so people can try C online and see the results.
You could provide a link to gcc or another compiler so your readers can try it themselves.
If you were really serious, a CGI script could be created on the server side which:
Runs in a sandbox (this is critical to get right and is potentially dangerous if done incorrectly)
Compiles the source code
Runs the compiled code
Returns the results
Sorry that I can't give you an easy answer, but there it is.
I am a complete newbie to the ARM world. I need to be able to write C code, compile it, and then download into an ARM emulator, and execute. I need to use the GCC 4.1.2 compiler for the C code compilation.
Can anybody point me in the correct directions for the following issues?
What tool chain to use?
What emulator to use?
Are there tutorials or guides on setting up the tool chain?
building a gcc cross compiler yourself is pretty easy. the gcc library and the C library and other things not so much, an embedded library and such a little harder. Depends on how embedded you want to get. I have little use for gcclib or a c library so roll your own works great for me.
After many years of doing this, perhaps it is an age thing, I now just go get the code sourcery tools. the lite version works great. yagarto, devkitarm, winarm or something like that (the site with a zillion examples) all work fine. emdebian also has a good pre-built toolchain. a number of these places if not all have info on how they built their toolchains from gnu sources.
You asked about gcc, but bear in mind that llvm is a strong competitor, and as far as cross compiling goes, since it always cross compiles, it is a far easier cross compiler to download and build and get working than gcc. the recent version is now producing code (for arm) that competes with gcc for performance. gcc is in no way a leader in performance, other compilers I have used run circles around it, but it has been improving with each release (well the 3.x versions sometimes produce better code than the 4.x versions, but you need 4.x for the newer cores and thumb2). even if you go with gcc, try the stable release of llvm from time to time.
qemu is a good emulator, depending on what you are doing the gba emulator virtual gameboy advance is good. There are a couple of nds emulators too. GDB and other places have what appear to be ARMs own armulator. I found it hard to extract and use, so I wrote my own, but being lazy only implemented the thumb instruction set, I called mine the thumbulator. easy to use. Far easier than qemu and armulator to add peripherals to and watch and debug your code. ymmv.
Hmmm I posted a similar answer for someone recently. Google: arm verilog and at umich you will find a file isc.tgz in which is an arm10 behavioural (as in you cannot make a chip from it therefore you can find verilog on the net) model. Which for someone wanting to learn an instruction set, watching your code execute at the gate level is about as good as it gets. Be careful, like a drug, you can get addicted then have a hard time when you go back to silicon where you have relatively zero visibility into your code while it is executing. Somewhere in stackoverflow I posted the steps involved to get that arm10 model and another file or two to turn it into an arm emulator using icarus verilog. gtkwave is a good and free tool for examining the wave (vcd) files.
Above all else you will need the ARM ARM. (The ARM Architectural Reference Manual). Just google it and find it on ARM's web site. There is pseudo code for each instruction teaching you what they do. Use the thumbulator or armulator or others if you need to understand more (mame has an arm core in it too). I make no guarantees that the thumbulator is 100% debugged or accurate, I took some common programs and compared their output to silicon both arm and non-arm to debug the core.
Toolchain you can use Yagarto http://www.yagarto.de/
Emulator you can use Proteus ISIS http://www.labcenter.com/index.cfm
(There is a demo version)
and tutorials, well, google them =)
Good luck!
We've made a number of changes to gcc 3.3.2 (for MIPS) to support the vagaries of an embedded system we're working on. gcc 3.4 and later appear to have substantially improved the MIPS code generation, so I'm planning to port our changes forward. The question is which gcc version should I target: 3.4.4 or straight to 4.3.2? Its a substantial amount of work to port the changes, I don't want to do it twice and pick the better result.
The Linux-MIPS project still recommends gcc 3.4.4, and MIPS Technologies maintains a modified SDE toolchain based on gcc 3.4.4. Though my embedded system is not running Linux, I respect their expertise.
From what I've read the MIPS backend does not benefit from the higher level optimizations in 4.x, and actually produces slower code than 3.4.4. Can anyone confirm or deny this?
I haven't used MIPS since the classroom so I can't directly answer your question.
I would suggest sending an e-mail to someone on the Linux-MIPS project, and ask when they plan to upgrade. Assuming it is not soon. It looks like 3.4.4 is a worthy upgrade.