Build issues

[paololucente]

Dears,

Maybe good material to go through for our meeting later today. I would have happily submitted a Pull Request but apparently in can't fork the code (understand!) so let's do via an Issue. Bulk of the issue is that on a "blank" system just doing make does not work for getting all compiled. These changes in Makefile do allow that:

• Most of the issues i believe come from the fact doing clean does not remove libunyte.so ( it's cheating! :-D ):

 clean:
-       rm $(ODIR)/*.o $(SAMPLES_ODIR)/*.o $(TDIR)/*.o $(BINS)
+       rm $(ODIR)/*.o $(SAMPLES_ODIR)/*.o $(TDIR)/*.o $(BINS) libunyte.so

• First build the library via the build target then build the binaries:

-all: $(BINS)
+all: build $(BINS)

• You can't use pkg-config for yourself, it's a chicken and egg matter. That is purely for 3rd parties, ie. pmacct:

 $(SAMPLES_ODIR)/%.o: $(SAMPLES_DIR)/%.c 
-       $(CC) -c -o $@ $< $(CFLAGS) $(shell pkg-config --cflags --libs unyte)
+       $(CC) -c -o $@ $< $(CFLAGS)
 
 client_sample: $(SAMPLES_ODIR)/client_sample.o
-       $(CC) -pthread -o $@ $^ $(LDFLAGS) $(shell pkg-config --cflags --libs unyte)
+       $(CC) -pthread -o $@ $^ $(LDFLAGS)

• As a direct consequence of the above, i am sure it was like that originally, you need a hint in LDFLAGS:

-LDFLAGS=-g
+LDFLAGS=-g -L./ -lunyte

• Finally, there is this inclusion in samples/client_sample.c done differently than the rest of the files that does not make it compile for me:

diff --git a/samples/client_sample.c b/samples/client_sample.c
index 78df320..da14529 100644
--- a/samples/client_sample.c
+++ b/samples/client_sample.c
@@ -6,15 +6,11 @@
 #include <signal.h>
 #include <unistd.h>
 
-#include <unyte/unyte_collector.h>
-#include <unyte/unyte_utils.h>
-#include <unyte/queue.h>
-
 // #include <hexdump.h>
 // #include "../src/hexdump.h"
-// #include "../src/unyte_collector.h"
-// #include "../src/unyte_utils.h"
-// #include "../src/queue.h"
+#include "../src/unyte_collector.h"
+#include "../src/unyte_utils.h"
+#include "../src/queue.h"
 
 #define PORT 8081
 #define ADDR "192.168.0.17"

Paolo

[ahuangfeng]

The client_sample using the external lib, that's me testing that all was working fine as thirs party lib. I'll remove all that.
So, for you (me profiting of your C expertise :) ) in the makefile, on our clients, we should first compile the src as a lib, and then use it as such ?

-LDFLAGS=-g
+LDFLAGS=-g -L./ -lunyte

if we do the code above, the dependency of $(OBJS) in the is not necessary anymore right ?
I think the dependency is necessary cause we are using the includes as "../src/x.h"

[paololucente]

in the makefile, on our clients, we should first compile the src as a lib, and then use it as such ?

Yes, correct.

if we do the code above, the dependency of $(OBJS) in the is not necessary anymore right ?

That dependency is not entirely correct. In fact if you try to do make sender_performance, for example, it will complain that it can't link libunyte. Because $(OBJS) only compiles the components of the library but does not build the library itself. So one further proposal may be to rewrite the targets as:

client_performance: build $(SAMPLES_ODIR)/client_performance.o
        $(CC) -pthread -o $@ $(SAMPLES_ODIR)/client_performance.o $(LDFLAGS)

make is "smart enough" that when you do make all, which requires build to complete, when it goes through the client_performance target (which has also build specified) it does not do it twice.

[ahuangfeng]

Yes, I see, but I tried and the problem is that my C is not detecting the headers file on compilation then...
I tried to include the headers on compilation (and changing the #include to make it work) but then the error is on runtime, it does not detect the lib then... It is like my PC is always trying to find the library on global installs libs instead of my current directory

[paololucente]

That -L./ in LDFLAGS should do precisely that trick - mmm, doesn't it do it for you?

[ahuangfeng]

Yeah, I thought the same but no, it crash on runtime (lib not found). I changed the include to directly "unyte/hexdump.h", if I let it as relative path, it does not even compile...

[paololucente]

Thank you for your time today to go through this. Confirmed working in pmacct with pmacct/pmacct@5a55388