Thread: app rule not found despite being there

  1. #1
    Registered User awsdert's Avatar
    Join Date
    Jan 2015
    Posts
    1,733

    app rule not found despite being there

    I get this output:
    Code:
    make --no-print-directory rebuild
    MAKECMDGOALS=rebuild
    make -f main.mak rebuild
    rm -f *.o
    cc -Wall -Wextra -shared -fPIE -o alu_bit.o alu_bit.c
    cc -Wall -Wextra -shared -fPIE -o alu_math.o alu_math.c
    cc -Wall -Wextra -shared -fPIE -o alu_mem.o alu_mem.c
    cc -Wall -Wextra -shared -fPIE -o alu_vec.o alu_vec.c
    make[1]: *** No rule to make target 'alu.AppImage', needed by 'build'.  Stop.
    make: *** [1st.mak:6: rebuild] Error 2
    Compilation failed.
    When I go to build the binary that would test the code I made (or at least some of it, getting round to my idea soon)
    I know I stuck a rule for %.AppImage in main.mak (same file holding the 'rebuild' target) so I'm a little confused (every time I think I got the hang of the basics make goes and throws a wrench at that thought)
    Attached Files Attached Files

  2. #2
    Registered User awsdert's Avatar
    Join Date
    Jan 2015
    Posts
    1,733
    Just in case nobody bothered to download the zip of my project in it's current state (provided in case there was something else I didn't notice was wrong or style issues to be found), here's the snippet from main.mak involving both the target and the %.AppImage rule
    Code:
    build: objects $(PRJ_DST_BIN)
    
    objects: $(PRJ_OBJ_FILES)
    
    rebuild: clean build
    
    %.AppImage: test.o
    	$(CC) $(BIN_FLAGS) $(COP)o $@ $^

  3. #3
    Registered User awsdert's Avatar
    Join Date
    Jan 2015
    Posts
    1,733
    Seems the rule was ignored because I forgot to create a file it needed, now dealing with various errors

  4. #4
    Registered User awsdert's Avatar
    Join Date
    Jan 2015
    Posts
    1,733
    Got as far as this:
    Code:
    make --no-print-directory rebuild
    MAKECMDGOALS=rebuild
    make -f main.mak rebuild
    rm -f *.AppImage *.exe *.so *.dll *.o *.obj
    cc -fPIE -shared -Wall -Wextra -o alu_bit.o alu_bit.c
    cc -fPIE -shared -Wall -Wextra -o alu_main.o alu_main.c
    cc -fPIE -shared -Wall -Wextra -o alu_math.o alu_math.c
    cc -fPIE -shared -Wall -Wextra -o alu_mem.o alu_mem.c
    cc -fPIE -shared -Wall -Wextra -o alu_vec.o alu_vec.c
    cc -fPIE -shared -o libalu.so alu_bit.o alu_main.o alu_math.o alu_mem.o alu_vec.o
    cc -fPIE -shared -Wall -Wextra -o test.o test.c
    cc -fPIE -o alu.AppImage test.o
    /usr/bin/ld: test.o: undefined reference to `alu_vec_change'
    /usr/bin/ld: test.o: undefined reference to `alu_get_reg'
    /usr/bin/ld: test.o: undefined reference to `_alu_shl'
    collect2: error: ld returned 1 exit status
    make[1]: *** [main.mak:59: alu.AppImage] Error 1
    rm libalu.so test.o
    make: *** [1st.mak:6: rebuild] Error 2
    Compilation failed.
    I tried adding rpath but I must be doing something wrong because it never finds it, I tried looking for it myself and the library is not built for some reason despite showing just fine in the above output

    Here's a dump of main.mak (the other files are mostly irrelevant)
    Code:
    include dst_sys.mak
    include dst_cc.mak
    
    PRJ:=ALU
    ALL_GOALS:=info objects
    
    PRJ_SRC_DIR:=
    PRJ_INC_DIR:=
    PRJ_LIB_DIR:=/lib
    PRJ_BIN_DIR:=/bin
    
    RPATH_FLAG=-Wl,-rpath=./
    
    SRC_FLAGS:=-fPIE -shared -Wall -Wextra
    LIB_FLAGS:=-fPIE -shared
    BIN_FLAGS:=-fPIE
    
    PRJ_SRC_FILES:=$(wildcard $(PRJ_SRC_DIR)alu*.c)
    PRJ_INC_FILES:=$(wildcard $(PRJ_INC_DIR)alu*.h)
    PRJ_OBJ_FILES:=$(PRJ_SRC_FILES:%.c=%$(DST_OBJ_SFX))
    
    PRJ_BIN_OBJ_FILES:=test$(DST_OBJ_SFX)
    PRJ_LIB_OBJ_FILES:=$(filter-out $(PRJ_BIN_OBJ_FILES),$(PRJ_OBJ_FILES))
    
    PRJ_DST_BIN:=alu$(DST_BIN_SFX)
    PRJ_DST_LIB:=$(DST_LIB_PFX)alu$(DST_LIB_SFX)
    
    info: .FORCE
    	@echo CC=$(CC)
    	@echo CXX=$(CXX)
    	@echo COP=$(COP)
    	@echo PRJ=$(PRJ)
    	@echo PRJ_DST_BIN=$(PRJ_DST_BIN)
    	@echo PRJ_DST_LIB=$(PRJ_DST_LIB)
    	@echo PRJ_SRC_FILES=$(PRJ_SRC_FILES)
    	@echo PRJ_INC_FILES=$(PRJ_INC_FILES)
    	@echo PRJ_OBJ_FILES=$(PRJ_OBJ_FILES)
    	@echo PRJ_BIN_OBJ_FILES=$(PRJ_BIN_OBJ_FILES)
    	@echo PRJ_LIB_OBJ_FILES=$(PRJ_LIB_OBJ_FILES)
    	@echo Goals make can process for $(PROJECT):
    	@echo $(TAB_CHAR) all $(ALL_GOALS)
    
    all: $(ALL_GOALS)
    	@echo all
    
    clean:
    	rm -f *.AppImage *.exe *.so *.dll *.o *.obj
    
    run: build
    	./$(PRJ_DST_BIN)
    
    build: objects $(PRJ_DST_BIN)
    
    objects: $(PRJ_OBJ_FILES)
    
    rebuild: clean build
    
    %.AppImage: lib%.so test.o
    	$(CC) $(BIN_FLAGS) $(COP)o $@ test.o
    
    %.16.exe: %.16.dll test.16.obj
    	$(CC) $(BIN_FLAGS) $(COP)o $@ test.16.obj
    
    %.32.exe: %.32.dll test.32.obj
    	$(CC) $(BIN_FLAGS) $(COP)o $@ test.32.obj
    
    %.64.exe: %.64.dll test.64.obj
    	$(CC) $(BIN_FLAGS) $(COP)o $@ test.64.obj
    	
    lib%.so: $(filter-out test.o,$(wildcard *.o))
    	$(CC) $(LIB_FLAGS) $(COP)o $@ $^
    
    %.16.dll: $(filter-out test.16.obj,$(wildcard *.16.obj))
    	$(CC) $(LIB_FLAGS) $(COP)o $@ $^
    
    %.32.dll: $(filter-out test.32.obj,$(wildcard *.32.obj))
    	$(CC) $(LIB_FLAGS) $(COP)o $@ $^
    
    %.64.dll: $(filter-out test.64.obj,$(wildcard *.64.obj))
    	$(CC) $(LIB_FLAGS) $(COP)o $@ $^
    
    %.o: %.c
    	$(CC) $(SRC_FLAGS) $(COP)o $@ $<
    
    %.16.obj: %.c
    	$(CC) $(SRC_FLAGS) $(COP)o $@ $<
    
    %.32.obj: %.c
    	$(CC) $(SRC_FLAGS) $(COP)o $@ $<
    
    %.64.obj: %.c
    	$(CC) $(SRC_FLAGS) $(COP)o $@ $<
    	
    .PHONY: all
    
    .FORCE:
    Can anyone tell me where I'm going wrong? I attached a zip of my project just in case you need to look elsewhere to find what I'm doing wrong
    Attached Files Attached Files

  5. #5
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,659
    > cc -fPIE -shared -Wall -Wextra -o alu_bit.o alu_bit.c
    All your .c.o rules need to pass the -c command line option to cc.

    You compile (only) all the .c files into .o files in the first instance.

    Then you link all the objects and libraries to produce the executable.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  6. #6
    Registered User awsdert's Avatar
    Join Date
    Jan 2015
    Posts
    1,733
    Quote Originally Posted by Salem View Post
    > cc -fPIE -shared -Wall -Wextra -o alu_bit.o alu_bit.c
    All your .c.o rules need to pass the -c command line option to cc.

    You compile (only) all the .c files into .o files in the first instance.

    Then you link all the objects and libraries to produce the executable.
    Ah thank you That got me further (had to re-add the RPATH and finally remembered about adding the -L switch), just missing a function I hadn't realised I hadn't made yet but otherwise nearly able to test the base functions I need for it to be a usable library in mitsy before moving on to making and testing the speed of another function I thought of an optimised way to make (well more optimised than the previous version I made that mitsy currently includes)

  7. #7
    Registered User awsdert's Avatar
    Join Date
    Jan 2015
    Posts
    1,733
    I managed to get everything to compile, tried to run the app but for some reason the shared library was deleted by the time I tried to run it resulting in a fatal error of library not found, mind taking a look at the rules I'm using to identify where I'm going wrong:
    Code:
    include dst_sys.mak
    include dst_cc.mak
    
    PRJ:=ALU
    ALL_GOALS:=info objects
    
    PRJ_SRC_DIR:=
    PRJ_INC_DIR:=
    PRJ_LIB_DIR:=/lib
    PRJ_BIN_DIR:=/bin
    
    RPATH_FLAG=-Wl,-rpath=./
    
    SRC_FLAGS:=-fPIE -shared -Wall -Wextra
    LIB_FLAGS:=-fPIE -shared
    BIN_FLAGS:=-fPIE -L . -l alu
    
    PRJ_SRC_FILES:=$(wildcard $(PRJ_SRC_DIR)alu*.c)
    PRJ_INC_FILES:=$(wildcard $(PRJ_INC_DIR)alu*.h)
    PRJ_OBJ_FILES:=$(PRJ_SRC_FILES:%.c=%$(DST_OBJ_SFX))
    
    PRJ_BIN_OBJ_FILES:=test$(DST_OBJ_SFX)
    PRJ_LIB_OBJ_FILES:=$(filter-out $(PRJ_BIN_OBJ_FILES),$(PRJ_OBJ_FILES))
    
    PRJ_DST_BIN:=alu$(DST_BIN_SFX)
    PRJ_DST_LIB:=$(DST_LIB_PFX)alu$(DST_LIB_SFX)
    
    info: .FORCE
    	@echo CC=$(CC)
    	@echo CXX=$(CXX)
    	@echo COP=$(COP)
    	@echo PRJ=$(PRJ)
    	@echo PRJ_DST_BIN=$(PRJ_DST_BIN)
    	@echo PRJ_DST_LIB=$(PRJ_DST_LIB)
    	@echo PRJ_SRC_FILES=$(PRJ_SRC_FILES)
    	@echo PRJ_INC_FILES=$(PRJ_INC_FILES)
    	@echo PRJ_OBJ_FILES=$(PRJ_OBJ_FILES)
    	@echo PRJ_BIN_OBJ_FILES=$(PRJ_BIN_OBJ_FILES)
    	@echo PRJ_LIB_OBJ_FILES=$(PRJ_LIB_OBJ_FILES)
    	@echo Goals make can process for $(PROJECT):
    	@echo $(TAB_CHAR) all $(ALL_GOALS)
    
    all: $(ALL_GOALS)
    	@echo all
    
    clean:
    	rm -f *.AppImage *.exe *.so *.dll *.o *.obj
    
    run: build
    	./$(PRJ_DST_BIN)
    
    build: objects $(PRJ_DST_BIN)
    
    objects: $(PRJ_OBJ_FILES)
    
    rebuild: clean build
    
    %.AppImage: lib%.so test.o
    	$(CC) $(BIN_FLAGS) $(COP)o $@ test.o $(RPATH_FLAG)
    
    %.16.exe: %.16.dll test.16.obj
    	$(CC) $(BIN_FLAGS) $(COP)o $@ test.16.obj $(RPATH_FLAG)
    
    %.32.exe: %.32.dll test.32.obj
    	$(CC) $(BIN_FLAGS) $(COP)o $@ test.32.obj $(RPATH_FLAG)
    
    %.64.exe: %.64.dll test.64.obj
    	$(CC) $(BIN_FLAGS) $(COP)o $@ test.64.obj $(RPATH_FLAG)
    	
    lib%.so: $(filter-out test.o,$(PRJ_SRC_FILES:%.c=%.o))
    	$(CC) $(LIB_FLAGS) $(COP)o $@ $^
    
    %.16.dll: $(filter-out test.16.obj,$(PRJ_SRC_FILES:%.c=%.16.obj))
    	$(CC) $(LIB_FLAGS) $(COP)o $@ $^
    
    %.32.dll: $(filter-out test.32.obj,$(PRJ_SRC_FILES:%.c=%.32.obj))
    	$(CC) $(LIB_FLAGS) $(COP)o $@ $^
    
    %.64.dll: $(filter-out test.64.obj,$(PRJ_SRC_FILES:%.c=%.64.obj))
    	$(CC) $(LIB_FLAGS) $(COP)o $@ $^
    
    %.o: %.c
    	$(CC) $(SRC_FLAGS) $(COP)o $@ -c $<
    
    %.16.obj: %.c
    	$(CC) $(SRC_FLAGS) $(COP)o $@ $<
    
    %.32.obj: %.c
    	$(CC) $(SRC_FLAGS) $(COP)o $@ $<
    
    %.64.obj: %.c
    	$(CC) $(SRC_FLAGS) $(COP)o $@ $<
    	
    .PHONY: all
    
    .FORCE:

  8. #8
    Registered User awsdert's Avatar
    Join Date
    Jan 2015
    Posts
    1,733
    Oh and here's the compilation output:
    Code:
    make --no-print-directory run
    MAKECMDGOALS=run
    make -f main.mak run
    cc -fPIE -shared -Wall -Wextra -o alu_bit.o -c alu_bit.c
    cc -fPIE -shared -Wall -Wextra -o alu_main.o -c alu_main.c
    cc -fPIE -shared -Wall -Wextra -o alu_math.o -c alu_math.c
    cc -fPIE -shared -Wall -Wextra -o alu_mem.o -c alu_mem.c
    cc -fPIE -shared -Wall -Wextra -o alu_vec.o -c alu_vec.c
    cc -fPIE -shared -o libalu.so alu_bit.o alu_main.o alu_math.o alu_mem.o alu_vec.o
    cc -fPIE -shared -Wall -Wextra -o test.o -c test.c
    cc -fPIE -L . -l alu -o alu.AppImage test.o -Wl,-rpath=./
    ./alu.AppImage
    make[1]: *** [main.mak:50: run] Segmentation fault (core dumped)
    rm libalu.so test.o
    make: *** [1st.mak:6: run] Error 2
    Compilation failed.

  9. #9
    Registered User awsdert's Avatar
    Join Date
    Jan 2015
    Posts
    1,733
    Quote Originally Posted by awsdert View Post
    Oh and here's the compilation output:
    Code:
    make --no-print-directory run
    MAKECMDGOALS=run
    make -f main.mak run
    cc -fPIE -shared -Wall -Wextra -o alu_bit.o -c alu_bit.c
    cc -fPIE -shared -Wall -Wextra -o alu_main.o -c alu_main.c
    cc -fPIE -shared -Wall -Wextra -o alu_math.o -c alu_math.c
    cc -fPIE -shared -Wall -Wextra -o alu_mem.o -c alu_mem.c
    cc -fPIE -shared -Wall -Wextra -o alu_vec.o -c alu_vec.c
    cc -fPIE -shared -o libalu.so alu_bit.o alu_main.o alu_math.o alu_mem.o alu_vec.o
    cc -fPIE -shared -Wall -Wextra -o test.o -c test.c
    cc -fPIE -L . -l alu -o alu.AppImage test.o -Wl,-rpath=./
    ./alu.AppImage
    make[1]: *** [main.mak:50: run] Segmentation fault (core dumped)
    rm libalu.so test.o
    make: *** [1st.mak:6: run] Error 2
    Compilation failed.
    Seems editing the build target to this:
    Code:
    build: objects $(PRJ_DST_LIB) $(PRJ_DST_BIN)
    Stopped make from just removing the library after it's been built, don't understand why that makes a difference, it should not be removing it without being told anyways

  10. #10
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,659
    Maybe make clean also a phony target.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  11. #11
    Registered User awsdert's Avatar
    Join Date
    Jan 2015
    Posts
    1,733
    Quote Originally Posted by Salem View Post
    Maybe make clean also a phony target.
    Yep, that fixed it, thx. Still I don't understand the point of targets if make is just gonna execute all targets anyways.

  12. #12
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    28,413
    Targets allow you to name and hence to choose specific rules to run. By default, make would run the rule associated with the first target. So, running make does not necessarily invoke all the targets, but often the first target is written to cause most of the other targets to be invoked.

    All your non-file targets should be listed as phony targets.
    Quote Originally Posted by Bjarne Stroustrup (2000-10-14)
    I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  13. #13
    Registered User awsdert's Avatar
    Join Date
    Jan 2015
    Posts
    1,733
    Quote Originally Posted by laserlight View Post
    Targets allow you to name and hence to choose specific rules to run. By default, make would run the rule associated with the first target. So, running make does not necessarily invoke all the targets, but often the first target is written to cause most of the other targets to be invoked.

    All your non-file targets should be listed as phony targets.
    I agree that the 1st target is NORMALLY used for all other targets but I clearly used a non-building target as the 1st target and when I invoked make I clearly stated which target I wanted to run, that target's listed dependencies I would expect to be run but not unlisted targets that just happen to be in the same file, it is that unexpected behavior that make apparently does by default that render targets a pointless thing to make because that default behavior completely contradicts the purpose of stating a target in the 1st place

  14. #14
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    28,413
    Quote Originally Posted by awsdert
    I would expect to be run but not unlisted targets that just happen to be in the same file, it is that unexpected behavior that make apparently does by default that render targets a pointless thing to make because that default behavior completely contradicts the purpose of stating a target in the 1st place
    make shouldn't be running "unlisted targets that just happen to be in the same file" when you specify a particular target as the goal though, unless that target has such targets as (indirect) prerequisites or as recipes, but neither appear to be the case for your run target.

    (Sorry, I edited this as I realised that my earlier statement is wrong: I thought that you might be right to characterise file targets as always being invoked, but clearly this is not so as I have from time to time forgotten to list non-file targets as phony targets and they still didn't get invoked unintentionally... rather the issue it seems is one of possible conflicts with a file of the same name, as well as efficiency concerns, but neither are pertinent to your case.)
    Last edited by laserlight; 07-26-2020 at 07:28 PM.
    Quote Originally Posted by Bjarne Stroustrup (2000-10-14)
    I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  15. #15
    Registered User awsdert's Avatar
    Join Date
    Jan 2015
    Posts
    1,733
    Quote Originally Posted by laserlight View Post
    make shouldn't be running "unlisted targets that just happen to be in the same file" when you specify a particular target as the goal though, unless that target has such targets as (indirect) prerequisites or as recipes, but neither appear to be the case for your run target.

    (Sorry, I edited this as I realised that my earlier statement is wrong: I thought that you might be right to characterise file targets as always being invoked, but clearly this is not so as I have from time to time forgotten to list non-file targets as phony targets and they still didn't get invoked unintentionally... rather the issue it seems is one of possible conflicts with a file of the same name, as well as efficiency concerns, but neither are pertinent to your case.)
    Well I appreciate you trying to explain it anyways, guess this might just be a bug or quirk in make I didn't know about, more likely the latter and even if it were the former, in both cases I would have to assume unwanted behaviour and programme my makefile accordingly

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Simpson's Rule (not composite simpson's rule)
    By Solas99 in forum C Programming
    Replies: 10
    Last Post: 04-02-2013, 12:37 PM
  2. Simpson's rule and Trapezoidal rule from fixed array
    By timwonderer in forum C++ Programming
    Replies: 1
    Last Post: 12-02-2010, 03:14 PM
  3. Rule of 72
    By sonict in forum C++ Programming
    Replies: 12
    Last Post: 01-23-2003, 08:31 PM

Tags for this Thread