I am changing the question as I could get over the initial issue.
I am having the following define in my package//Makefile
PKG_BUILD_DIR:=$(KERNEL_BUILD_DIR)/$(PKG_NAME)-$(PKG_VERSION)
define Build/Compile
$(MAKE) -s -C $(PKG_BUILD_DIR)
endef
$(eval $(call BuildPackage,<Module-name>))
I am trying to get a custom kernel module to compile with OpenWRT.
I am building using the command make package/"Module_name"/compile ;
Make never succeeds and it comes out saying :
make[2]: Nothing to be done for `compile'.
Why is make coming out doing nothing eventhough rule exists ? Any suggestion to get over this error would be helpful.
Please first run
make menuconfig
and check if the module your are trying to compile is selected in the OpenWRT configuration.
If the module is selected then it will be built as you are trying to do.
Related
I'm trying to build an Alpine Docker image for the FIPS-enabled version of Go. To do this, I am trying to build Go from source using the dev.boringcrypto branch of the golang/go repository.
Upon running ./all.bash, I get the following errors:
Step 4/4 : RUN cd go/src && ./all.bash
---> Running in 00db552598f7
Building Go cmd/dist using /usr/lib/go.
# _/go/src/cmd/dist
loadinternal: cannot find runtime/cgo
/usr/lib/go/pkg/tool/linux_amd64/link: running gcc failed: exit status 1
/usr/lib/gcc/x86_64-alpine-linux-musl/6.4.0/../../../../x86_64-
alpine-linux-musl/bin/ld: cannot find Scrt1.o: No such file or directory
/usr/lib/gcc/x86_64-alpine-linux-musl/6.4.0/../../../../x86_64-
alpine-linux-musl/bin/ld: cannot find crti.o: No such file or directory
/usr/lib/gcc/x86_64-alpine-linux-musl/6.4.0/../../../../x86_64-alpine-linux-musl/bin/ld: cannot find -lssp_nonshared
collect2: error: ld returned 1 exit status
The command '/bin/bash -c cd go/src && ./all.bash' returned a non-zero code: 2
Which causes the installation tests to fail and kicks me out of the Docker image build.
I have the gcc installed on the image, and tried setting the environment variable CGO_ENABLED=0 as suggested in other questions, but neither of these things seem to alleviate the problem.
I'm at my wits end with this problem. Has anybody else run into similar issues in the past? I don't understand why this is happening, as the build runs fine in an Ubuntu container.
Thanks!
I had the same error messages, although I was compiling a different project.
It turns out that alpine needs to have the musl-dev package installed for this to work, so I think you need to make sure that is included in your Dockerfile, or manually install it by running apk add --no-cache musl-dev.
Either go isn't correctly installed on the image or the GOROOT is wrong
Put go tool dist banner and go tool dist env in your all.bash for clues
What is the correct way to specify x11 dependency in a homebrew formula?
The default superenv removes /opt/X11/lib from its arguments.
I am writing a formula for a package that I can build outside of homebrew with the usual configure, make install.
So I have this install function:
def install
ENV["PKG_CONFIG_PATH"] = "/usr/local/opt/qt/lib/pkgconfig"
# ENV["PATH"] = "/usr/local/bin:/usr/bin:/bin" <--- work around
Dir.chdir("codebase")
system "./configure", "--disable-dependency-tracking", "--prefix=#{prefix}"
system "make install"
end
The link phase that gets echoed shows
/bin/sh ../../../../libtool --tag=CXX --mode=link clang++ .... -I /opt/X11/include ..... -L/opt/X11/lib ...
But the link fails with
ld: library not found for -lX11
If I add this to the top of the class definition, the build is successful
env :std
Alternatively, I can set PATH inside the build function and the build succeeds.
This makes sense since within the context of brew install, /usr/local/Homebrew/Library/Homebrew/shims/super appears at the start of the PATH, and that directory has a clang++ which among other things strips /opt/X11 components out.
I assume there is a good reason for this behavior, and am curious what is the best way to specify that X11 library.
The easiest way to know how to do something in writing Hombrew formulas is to look at existing formulas. For your case you can look at MuPDF a lightweight PDF and XPS viewer depending on X11. In its formula you will find the solution:
depends_on :x11
Some background: I have a project based on ESP-IDF which has a complex builtin building system which you plug into with your own makefile (their documentation on using it).
This works fine (apart from occasional horrendous build times), but now I wanted to add a build target for unit tests for a component, which requires building this component against another project (the unit-test-app).
So, I need another build target that calls another make with another makefile and directory. Something like this works fine:
make -C $(path to unit-test-app) \
EXTRA_COMPONENT_DIRS=$(my component directory) \
TEST_COMPONENTS=$(my component name) \
ESPPORT=$(my serial port) \
-j clean app-flash monitor
But only if I execute it from bash. If I try to execute it from another makefile, it breaks either not finding some header files (the include path is different between the main and unit test project) or ignores the change of project (-C argument) and executes the main project build.
What I tried:
using $(MAKE), $(shell which $(MAKE)) and make in the custom target
using env -i $(shell which $(MAKE) ) -C ... with forwarding required environment arguments to the child make
using bash -l make -C ... and bash -c make -C ...
What works but is a dirty hack: using echo $(MAKE) -C ... in the make target and then running $(make tests) from the command line.
As far as I know, this is an issue of the parent makefile setting something up in the environment that I did not separate the child makefile from. What else can I do to separate these two?
UPDATE: I have created an example project that shows the issue more clearly, please look at the top Makefile of https://github.com/chanibal/esp-idf-template-with-unit-tests
I reproduced your situation as you are describing it and everything works fine, both if I call the inner make from bash or from the outer make.
So there is something you are not telling us that is causing the failure.
On the other hand, I feel there are several irrelevant details in your description.
So, I suggest you try to further isolate the problem, removing irrelevant stuff, and reproducing the problem only from the description in your question, and then when you are doing it you will probably find out what is breaking. If not, then post here the minimal setup with all the other details that are needed for the failure to occur.
By the way, what you are doing is not good practice, so maybe just avoiding it would solve your problems.
What I mean is, there is one case and one case only, where recursive make is good practice: make -C ${directory}
where in directory you have a completely self-contained build, not using anything from the outside.
It seems this is not the case for you, because you seem to be passing some outside location variables. This kind of recursive make is bad practice and should be avoided.
I have been trying to include OpenCV extra modules by following the link OpenCV Contrib. After solving several errors obtained during the cmake command, when I did make -j5, it stopped giving error
[ 27%] Built target IlmImf
Makefile:149: recipe for target 'all' failed
make: *** [all] Error 2
When I ran simple make command, it started compiling and making the targets what happens when we make OpenCV in the build directory.
I again then tried make -j5 but this time I received some other error while make again compiled.
I wanted to know what's the differnce between make and make -j5 !!
Thanks in advance for the reply !!
-j [jobs], --jobs[=jobs] Specifies the number of jobs (commands) to run simultaneously. If there is more than one -j option, the last one is effective. If the -j option is given without an argument, make will not limit the number of jobs that can run simultaneously.
This is from man make. Errors are the same, but compilation process can encounter them in different order
I found exp5438 and z1 motes, which have TI MSP430x as a MCU, in the Contiki code tree, and we know that TI MSP430 is the TelosB mote's microcontroller.
I would like to know if TelosB motes are compatible with Contiki ?
The telosB mote is compatible with Contiki OS, in fact I am using them with Contiki. To program them, in case you are using Instant Contiki, you will need to install the GCC for the MSP430 micro controller. You can use the next command:
sudo apt-get install gcc-msp430
On the other hand, I think to solve the problem of your answer I think you just need to be root. So try the next:
sudo -s
make TARGET=sky hello-world.upload
I hope that help you out.
Cheers!
currently I am using telosb to run contiki applications. I followed the official site tutorial and apparently if u do make TARGET=sky it compiles the source files. However, doing make TARGET=sky hello-world.upload does not work. Shows
make sky-reset sky-upload
make[1]: Entering directory `/home/user/contiki-2.6/examples/hello-world'
make -k -j 1 sky-reset-sequence
make[2]: Entering directory `/home/user/contiki-2.6/examples/hello-world'
Done
make[2]: Leaving directory `/home/user/contiki-2.6/examples/hello-world'
make -j 1 sky-upload-sequence
make[2]: Entering directory `/home/user/contiki-2.6/examples/hello-world'
Done
make[2]: Leaving directory `/home/user/contiki-2.6/examples/hello-world'
make[1]: Leaving directory `/home/user/contiki-2.6/examples/hello-world'
rm hello-world.ihex
which according to the official site tutorial means that the board is not connected. I am very certain it is connected. Also, make login never shows anything for me since the previous command didnt work.
Eventually, a friend of mine discovered a way to flash contiki applications into telosb. However, you need TinyOS development environment in your Instant Contiki. You can find information on setting up TinyOS environment in Ubuntu on www.eetutorials.com.
This doesn't seem like a proper way of doing it but well so far it works for me when running simple applications
Step 1:
Compile your applications by doing:
make TARGET=sky application-name
Step 2:
msp430-objcopy application-name.sky -O ihex application-name.ihex
sudo tos-bsl --telosb -c /dev/ttyUSB0 -r -e -I -p application-name.ihex
However, make login still doesn't show anything hence I have been seeing my printf outputs
via Serial Port Terminal application which need to be installed. My guess is that contiki supports sky but not really for telosb? I am no expert and I can't tell the difference between the 2 boards. However, hope this information help and hope a contiki expert can further clarify on this.
Cheers
telosb mote is the same as a tmote sky or sky. The name is all the same platform.
I dont know from which vendor you have the board, but they have to work.
I am also using sky motes with contiki and i had no complications from the beginning.
Try to use the code in the following site: Unreadable output results when typing "make login"
This will print a message every second.
PS: Try to update your question if you found more information, dont add an answer since it confuses people.