Hey is there anybody who works with SDCC to make projects for 8051 microcontroller series on Macbook. If yes then can you please post the working make file, specially the part which loads the program in the device. I am confused what to write specifically with the program tag in the Makefile.
It is not necessarily the case that a makefile include loading the code to the part, so just any old example will not help. Makefiles are very simple in essence; you have a target, and its dependencies - if the target does not exist, or any dependency is newer than the target, the target is rebuilt by executing the commands.
In your case you need a phony target (one that never exists), that is dependent on the binary image or hex-file (or whatever format you load file is), the the command to execute would be to launch whatever flash-programming or bootloader tool your toolchain uses to load the image:
.PHONY loadimage
loadimage : myprogram.hex
loader.exe myprogram.hex
Related
Does anyone have an example of how to set up a custom build rule in Xcode that takes a file in a source directory and produces an output in the same folder? I am confused about the three separate areas, one is clearly the command line instruction, but I'm unclear on the rest of the setup. Apple's documentation is... ummm, "limited". I think this would be easy if you could simply see what their internal rule does, but these rules do not display the same screen so it's not easy to figure out what goes where.
The specific problem I'm trying to solve is building a yacc source file. When you build one, yacc (or in this case, the largely compatible bison) produces a .h with defines that you then #include into your C code. Modern dialects will normally build a file into the same directory with the same name as the input - in my case, the parse.y produces a parse.h.
Unfortunately, Apple has defined $(YACC) to include the -Y flag, so instead of building parse.h in the source folder it builds y.tab.h in the DerivedSources folder. I'm trying to override this behaviour without having to change $(YACC).
I'm working on the software that is being built on the RHEL using Makefile's. The build system is producing both .a (static libraries) and .so (dynamic libraries). Those libraries are independent pieces of the huge program.
If I change a source code of the binary and run the build I will rebuild the binary and everything will be good. But if I change the source code inside the .a library (one of the files that produce the library) and try to build, the build system will regenerate the library only. It will not relink the binary the .a file is linking to.
Is there any special flag I can use to force the make command to relink the binary that needs to be re-linked?
TIA!
make is just a tool that executes a makefile. The actual build rules are part of the makefile, and it is up to the makefile author to write correct rules. In your case, it seems that the makefile author neglected to list the static library as a prerequisite (dependency) in the rule that builds the binary. This means that make will not automatically relink the binary if the static library changes.
Depending on the complexity of your build system, this could be quite difficult to fix, or it could just be a matter of adding libfoo.a to the list of dependencies of the main binary.
Userspace package built for and along with root file system image of some embedded Linux-based system here (using Yocto project) apparently uses autotools - one can see Makefile.am's and configure.ac in package's sources. pkg-config or its successor seems to be used too (.pc.in is present), however out-of scope here.
Package in focus here does it this way (by involving autotools) as in the beginning of its development it was apparently the line of lowest resistance to copy and adopt build scripts from similar but already-existing package.
Actually autotools seem to be dispensable when building with Yocto, as Yocto build system meta data do specify target precisely enough for every target. For good reason standard build flow in Yocto is download, unpack, patch, configure, build,... with scan-and-detect-target-environment not included in this chain.
Now I wonder if it was good to streamline package's build process by removing autotools stage. I'm going to conduct it by proceeding in sequence of few steps starting with replacing .am file with real makefile. Question is if it will be sufficient enough to find env. variables defined and used in .am and .ac then transfer them to makefile? Remaining target-device specification should actually come from Yocto build system meta data. Possibly it will work this straightforward if to build package in scope of root file system image build. But how to ensure build environment provides complete target device specification when building only this package bitbake package-name?
Replacing autotools with a bare makefile isn't a trivial operation, as https://nibblestew.blogspot.co.uk/2017/12/a-simple-makefile-is-unicorn.html demonstrates nicely.
If you don't want to use autotools in your packages then alternatives such as Meson are generally faster.
I am trying to dynamically link to a custom dynamic library in an OSX application. For various reasons, I don't want to have specify environment variables after the build. I want my build environment to provide everything needed to run the application.
I am compiling the application with gcc using a makefile (actually, I a script that makes calls to qmake and does some automated editing.). On linux I would just do:
-Wl,-rpath,<path/to/dynamic/library>
but for whatever reason OSX doesn't abide by these rules. I keep getting
#rpath/mylib.dylib Library not loaded
when I try to run the app.
I hope this is clear. I want the app itself to know where to look for mylib.dylib. I know how to do this in Xcode with LLVM, but it would be nice if I could do it with a makefile and gcc as well. I don't want to have to setup a whole Xcode project for simple little apps like this (of which I need to make many that link to my library). Qmake etc. is far more convenient.
I'm new in writing Linux device driver, and I'm wondering how the kernel Makefile magically knows what to compile. To illustrate what I don't understand, consider the following case:
I did a #include <linux/irq.h> in my driver code and I'm able to find the header file irq.h in the kernel directory KDIR/include/linux. However, this is only the header file, so I thought the irq.c source code must be out there somewhere. Hence, I looked into the KDIR/arch/arm searching for irq.c (since I'm using the ARM architecture). My confusion begins here when I found really many irq.c inside KDIR/arch/arm. To simply list a few, I got:
KDIR/arch/arm/mach-at91/irq.c
KDIR/arch/arm/mach-davinci/irq.c
KDIR/arch/arm/mach-omap1/irq.c
KDIR/arch/arm/mach-orion5x/irq.c
many more...
In my Makefile, I have a line like this:
$(MAKE) -C $(KDIR) M=$(PWD) CROSS_COMPILE=arm-none-linux-gnueabi- ARCH=arm modules
So I understand that the kernel Makefile knows that I'm using the ARM architecture, but under KDIR/arch/arm/, there are so many irq.c with the same name. I'm guessing that the mach-davinci/irq.c is compiled since davinci is the cpu name I'm using. But then, how can the kernel Makefile knows this is the one to compile? Or if I would like to have a look for the irq.c that I'm actually using, which one should I refer to?
I believe there must be a way to know this besides reading the long kernel Makefile. Thanks for any help!
Beyond the ARCH variable, you can also choose the system type (mach) from the configuration menu (there is actually a sub-menu called "System type" when you type make menuconfig for instance). This selection will include and compile all files under linux2.6/arch/$ARCH/mach-$MACH, and in your case this is how only one irq.c gets compiled.
That aside, it is interesting to understand how the kernel chooses which files to compile. The mechanism behind this is called Kconfig, and it is what allows you to precisely configure your kernel using make menuconfig and others, to compile a module from the outside like you are doing, and to select the right files to compile from simple Makefiles. While it is simple to use, its internals are rather complex - but this article, although rather old, explains it rather well:
http://www.linuxjournal.com/article/6568
To make a very long story short, there's a target make config, which you can trace. That one generates .config, that is your main guideline to making dependencies and controlling what will be compiled, what not, what as module and what will be compiled into the kernel.
This guide should give you a basic understanding of building a kernel module (and I assume that's where you want to start with your driver).