Hi coco cry, can't really seem to build the library and test it out on my Mac. about leif

[cococry]

Hey there,

Thanks for the great word first of all :) Really appreciate it.

And you probably get the error because you first need to run ./install.sh and then ./build_run

Hope this helps. And also i will definitely include a readme that explains everything with building and so on

[divital-coder]

thats so sweet, will definitely check it out after running those commands, thanks for your assistance. Much appreciated.

[gruelingpine185]

I am also on mac. I had to change some code in a Makefile for me to build the test. There is a Makefile in ./test/ and I had to replace -lglfw with $(shell pkg-config --static --libs glfw3) so that the glfw functions can be found. I was able to go under .scripts/ and run ./install to build the Lief library and the test executable. However, upon running the test executable, it crashes with a segfault.

# ...
Process 63619 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = step over
    frame #0: 0x0000000100002352 test`main(argc=1, argv=0x00007ff7bfeff478) at test.c:55:21
   52       if(!gladLoadGLLoader((GLADloadproc)glfwGetProcAddress)) {
   53           printf("Failed to initialize Glad.\n");
   54       }
-> 55       LfTheme theme = lf_default_theme("../test/fonts/poppins.ttf", 64);
   56       lf_init_glfw(win_w, win_h, "../test/fonts/arial.ttf", &theme, window);   
   57       glfwSetFramebufferSizeCallback(window, resize_callback);
   58       float lastTime = 0.0f;
Target 0: (test) stopped.
(lldb) 
Process 63619 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
    frame #0: 0x0000000000000000
error: memory read failed for 0x0
Target 0: (test) stopped.

Upon further investigation (not too much because I am still learning how to debug) I found out that lf_default_theme() returns a local variable. From a quick google search I found this:

A function returns the address of a stack variable, which will cause unintended program behavior, typically in the form of a crash.

Exactly what occurs. I'm gonna try returning a heap allocated LfTheme and report my findings.

---

Some time later... I malloced LFTheme pointers and made a ton of conversions from dots to arrows, added dereferences where needed, and it still crashed. I also discovered that LfFont had the same issue. Upon repeating said process for LfFont, it still crashes. Thankfully at the same function: lf_default_theme(). Unfortunately, this problem seems like a massive undertaking and this is the extent of my efforts. I hope that a fix is found.

[ggcow]

uint8_t bitmap[tex_width * tex_height];
uint8_t bitmap_4bpp[tex_width * tex_height * 4];

These variable-length arrays can be quite large, it is safer to use malloc/free here. It might help solve the issue.

[cococry]

you're right. will change that, so that it allocates on the heap