Code Monkey home page Code Monkey logo

codam-coding-college / mlx42 Goto Github PK

View Code? Open in Web Editor NEW
335.0 0.0 57.0 5.73 MB

Codam's own fixed, functioning and open source alternative of the miniLibX. MLX42 is a simple cross-platform graphics library running on GLFW and OpenGL.

Home Page: https://portfolio.w2wizard.dev

License: GNU General Public License v2.0

C 88.75% GLSL 0.16% Python 1.52% C++ 8.56% Batchfile 0.12% Shell 0.11% CMake 0.78%
minilibx cross-platform linux opengl windows macos 42 42born2code 42school glfw

mlx42's Introduction


42MLX_Logo
Written by W2.Wizard for Codam

License GPL2.0 Build Forks

MLX42 is a performant, easy to use, cross-platform, minimal windowing graphics library to create graphical applications without having to work directly with the native windowing framework of the given operating system.

It provides primitive tools to draw textures onto the window as well as modifying them at runtime as they get displayed on the window.

Features โœจ

MLX42 comes with a plethora of features that make using it actually a joy instead of a chore.

Cross-Platform ๐Ÿ–ฅ๏ธ

Run it on your grandma's WindowsXP, on your uncle's debian or on a hipster's MacOS! No matter what the platform, if MLX42 can build on it, it will run on its native windowing system.

This allows you to work on your project no matter which machine it is on.

Documented ๐Ÿ“š

MLX42 cares about good documentation, every function, usage and even some internal workings are documented! No more guessing and searching how something functions or is supposed to work.

Performance ๐Ÿš€

It is built on OpenGL and uses batched rendering to speed up the rendering process compared to other libraries.

Open source && Community driven ๐ŸŒ

This project is being actively maintained by Codam as well as students from the 42 Network. This gives students the direct opportunity to learn more about the library itself as well as fix any potential bugs instead of merely accepting them.


Installation ๐Ÿ—๏ธ

General compilation

Overall the building of this project is as follows for ALL systems. As long as CMake can make sense of it.

  1. Download and build MLX42

In case your system doesn't have glfw installed cmake will detect this and download it for you. You can then run sudo make install in the _deps directory of glfw. If you're using a 42 Computer (MacOS, Linux), ask your favourite sysadmin to install it. Same goes for CMake or any other dependencies you might need for your system.

However if you can't do either CMake will still be able to fetch GLFW and build it. You can then statically link it from the _deps folder.

Note

For Codam, GLFW is already installed on the Macs.

Note

During the linking stage, the flag to link GLFW can either be: -lglfw3 or -lglfw depending on your system.

  1. Compile your program with the library:

  2. Profit!

Installing to the system

To fully build the library and install it to your system run the following command:

cmake -B build && cmake --build build --parallel --config (Debug|Release|RelWithDebInfo|MinSizeRel) --target install

By default windows will place the installed lib into: C:\Program Files (x86)\mlx42 and for MacOS / Linux it will be placed into /usr/local/lib and /usr/local/include respectively.

Unit tests

MLX42 comes with some unit tests to ensure the integrity of the library, to build them run the following command:

cmake -DBUILD_TESTS=ON -B build && cmake --build build --parallel

Then simply run them with:

ctest --output-on-failure --test-dir build

Download and build - MLX42

git clone https://github.com/codam-coding-college/MLX42.git
cd MLX42
cmake -B build # build here refers to the outputfolder.
cmake --build build -j4 # or do make -C build -j4

The output library file is called libmlx42.a and is located in the build folder that you specified.

Available Options

You can pass build options to cmake, e.g: cmake -DDEBUG=1 -DGLFW_FETCH=0.... These will for instance let you build it in DEBUG mode or alter any sort of behaviour at build-time.

You can find an example makefile in the documentation here.


For MacOS:

Installing the dependencies

If your system has neither GLFW nor CMake its highly recommended you use brew to install those missing dependencies.

For 42 Campuses you can use: 42Homebrew

Otherwise with homebrew:

brew install glfw
brew install cmake

If you are using Apple Silicon (M1 chip or later), note that the Homebrew install path is different. You may want to update your shell configuration file. For Zsh users (default shell on newer macOS versions):

nano ~/.zshrc
export LIBRARY_PATH=/opt/homebrew/lib

Restart your shell session or restart your terminal for the changes to take effect.

For MacOS you need to use the following flags to compile your program with the library in order to link the program with the correct frameworks:

-framework Cocoa -framework OpenGL -framework IOKit

Normally if you simply installed / built glfw from source or already have it installed the compilation should be:

gcc main.c ... libmlx42.a -Iinclude -lglfw
# Homebrew
gcc main.c ... libmlx42.a -Iinclude -lglfw -L"/opt/homebrew/Cellar/glfw/3.3.8/lib/"

# 42Homebrew
gcc main.c ... libmlx42.a -Iinclude -lglfw -L"/Users/$(USER)/.brew/opt/glfw/lib/"

MacOS Security:

When running your program in MacOS it may complain, because with Macs you just gotta think differently. In case of any security warnings or MacOS telling you it can't verify the author/developer, go to Settings > Security & Privacy.

There will be a pop-up at the bottom telling you that an application tried to run, click the option to let it run.


For Linux:

  1. Install the necessary packages:

For Debian like (Ubuntu, Mint, Pop OS...):

sudo apt update
sudo apt install build-essential libx11-dev libglfw3-dev libglfw3 xorg-dev

For Arch-linux (Manjaro, Endeavor, Garuda):

sudo pacman -S glfw-x11

OR (if you use sway/wlroots compositor or other wayland compositor)

sudo pacman -S glfw-wayland
  1. Download and build MLX42

  2. Compile your program with the library:

gcc main.c ... libmlx42.a -Iinclude -ldl -lglfw -pthread -lm
  1. Profit!

For Windows (with Windows Subsystem for Linux 2 (WSL2))

Important

Before starting with all these steps, read this

  1. Set these variables in your .zshrc or .bashrc:
export DISPLAY=$(ip route list default | awk '{print $3}'):0
export LIBGL_ALWAYS_INDIRECT=0

(If the DISPLAY export command is failing, see this StackOverflow post for alternatives)

  1. Download and install an XServer application with extended configuration (XMing does not qualify) VcXsrv works: https://sourceforge.net/projects/vcxsrv/

  2. Open Windows Defender Firewall, and follow these steps:

  • Go to 'Allow an app or feature through Windows Defender Firewall'
  • Change Settings
  • Find the installed XServer, for VcXsrv that's 'VcXsrv windows server'
  • Enable communication over Private and Public network Optionally you might be able to provide these settings on first launch of the XServer application, and they might not even show up in the list until the first time you start the app.
  1. Start the XLaunch application (for VcXsrv) and provide these configuration settings:
  • Leave Display number on auto
  • Start no client
  • UNTICK Native opengl option
  • TICK Disable access control
  • Finish starting the server
  1. Probably all the other steps for Linux apply, just clone, build and run.

For Windows Native:

Important

Be aware that Visual Studio (2022) is required for this. Developing on Windows can be somewhat frustrating.

We highly recommend you simply use WSL2 to make this as painless as possible. However if you insist on building for windows natively then all you need in terms of dependencies is:

Once you have all the dependencies correctly installed CMake will generate the visual studio project files. Simply build it and once you have a .lib file move them to your actual project and install them as you would with any other library.

Just in case here's a video showing you how this can be done. Conveniently this video also covers how you can link glfw.

Of course it's up to you to make sure that the code you write is portable. Things that exist on Unix don't necessarily exist on Win32.

Example

MLX42

// -----------------------------------------------------------------------------
// Codam Coding College, Amsterdam @ 2022-2023 by W2Wizard.
// See README in the root project for more information.
// -----------------------------------------------------------------------------

#include <stdio.h>
#include <stdlib.h>
#include <stdbool.h>
#include <MLX42/MLX42.h>

#define WIDTH 512
#define HEIGHT 512

static mlx_image_t* image;

// -----------------------------------------------------------------------------

int32_t ft_pixel(int32_t r, int32_t g, int32_t b, int32_t a)
{
    return (r << 24 | g << 16 | b << 8 | a);
}

void ft_randomize(void* param)
{
	(void)param;
	for (uint32_t i = 0; i < image->width; ++i)
	{
		for (uint32_t y = 0; y < image->height; ++y)
		{
			uint32_t color = ft_pixel(
				rand() % 0xFF, // R
				rand() % 0xFF, // G
				rand() % 0xFF, // B
				rand() % 0xFF  // A
			);
			mlx_put_pixel(image, i, y, color);
		}
	}
}

void ft_hook(void* param)
{
	mlx_t* mlx = param;

	if (mlx_is_key_down(mlx, MLX_KEY_ESCAPE))
		mlx_close_window(mlx);
	if (mlx_is_key_down(mlx, MLX_KEY_UP))
		image->instances[0].y -= 5;
	if (mlx_is_key_down(mlx, MLX_KEY_DOWN))
		image->instances[0].y += 5;
	if (mlx_is_key_down(mlx, MLX_KEY_LEFT))
		image->instances[0].x -= 5;
	if (mlx_is_key_down(mlx, MLX_KEY_RIGHT))
		image->instances[0].x += 5;
}

// -----------------------------------------------------------------------------

int32_t main(void)
{
	mlx_t* mlx;

	// Gotta error check this stuff
	if (!(mlx = mlx_init(WIDTH, HEIGHT, "MLX42", true)))
	{
		puts(mlx_strerror(mlx_errno));
		return(EXIT_FAILURE);
	}
	if (!(image = mlx_new_image(mlx, 128, 128)))
	{
		mlx_close_window(mlx);
		puts(mlx_strerror(mlx_errno));
		return(EXIT_FAILURE);
	}
	if (mlx_image_to_window(mlx, image, 0, 0) == -1)
	{
		mlx_close_window(mlx);
		puts(mlx_strerror(mlx_errno));
		return(EXIT_FAILURE);
	}
	
	mlx_loop_hook(mlx, ft_randomize, mlx);
	mlx_loop_hook(mlx, ft_hook, mlx);

	mlx_loop(mlx);
	mlx_terminate(mlx);
	return (EXIT_SUCCESS);
}

mlx42's People

Contributors

42ajakob avatar 552020 avatar andreasmaucher avatar atuuuu avatar bcheronn avatar eathox avatar freekbes avatar icarojam avatar jellevankraaij avatar jeroenvh99 avatar joppiesaus avatar lacusch avatar lanik2000 avatar lkabuci avatar lodeme avatar makseem77 avatar multitudes avatar mynameistrez avatar nda-cunh avatar pulgamecanica avatar raspurrin avatar senolem avatar swennehacks avatar techdaan avatar tishj avatar ugoi avatar vnncc avatar w2wizard avatar xannyxs avatar xedgit avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

mlx42's Issues

[REQUEST] Document "don't care" option for mlx_set_window_limit

Is your feature request related to a problem? Please describe.
I want to limit the minimum size of the window in my so_long, but not the maximum size

Describe the solution you'd like
I want mlx_set_window_limit have documented special values for limits I don't care about

Describe alternatives you've considered
At the moment I do

mlx_set_window_limit(mlx, min_w, min_h, -1, -1);

It works because -1 is the value of GLFW_DONT_CARE and mlx_set_window_limit just passes it to glfwSetWindowSizeLimits.

Additional context
I think that explicit MLX_DONT_CARE constant would be better than passing reverse-engineered -1.

[BUG] Leaks

System: macOS Catalina, Version 10.15.7 (19H2)

Describe the bug
There seem to be leaks in this library that can be shown with Valgrind when using the example code:

// -----------------------------------------------------------------------------
// Codam Coding College, Amsterdam @ 2022-2023 by W2Wizard.
// See README in the root project for more information.
// -----------------------------------------------------------------------------

#include <stdio.h>
#include <stdlib.h>
#include <memory.h>
#include "MLX42/MLX42.h"
#define WIDTH 512
#define HEIGHT 512

static mlx_image_t* img;

void hook(void* param)
{
	mlx_t* mlx = param;

	if (mlx_is_key_down(mlx, MLX_KEY_ESCAPE))
		mlx_close_window(mlx);
	if (mlx_is_key_down(mlx, MLX_KEY_UP))
		img->instances[0].y -= 5;
	if (mlx_is_key_down(mlx, MLX_KEY_DOWN))
		img->instances[0].y += 5;
	if (mlx_is_key_down(mlx, MLX_KEY_LEFT))
		img->instances[0].x -= 5;
	if (mlx_is_key_down(mlx, MLX_KEY_RIGHT))
		img->instances[0].x += 5;
}

int32_t	main(void)
{
	mlx_t* mlx;

	if (!(mlx = mlx_init(WIDTH, HEIGHT, "MLX42", true)))
		return(EXIT_FAILURE);

	img = mlx_new_image(mlx, 128, 128);
	memset(img->pixels, 255, img->width * img->height * sizeof(int));
	mlx_image_to_window(mlx, img, 0, 0);

	mlx_loop_hook(mlx, &hook, mlx);
	mlx_loop(mlx);

	mlx_terminate(mlx);
	return (EXIT_SUCCESS);
}

The output of valgrind:

==57071== Memcheck, a memory error detector
==57071== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==57071== Using Valgrind-3.21.0.GIT-lbmacos and LibVEX; rerun with -h for copyright info
==57071== Command: ./a.out
==57071== Parent PID: 49904
==57071== 
--57071-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option
--57071-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 2 times)
--57071-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 4 times)
--57071-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 8 times)
UNKNOWN workq_ops option 1024
==57071== Thread 2:
==57071== Invalid read of size 4
==57071==    at 0x10842BC10: _pthread_wqthread_setup (in /usr/lib/system/libsystem_pthread.dylib)
==57071==    by 0x10842B942: _pthread_wqthread (in /usr/lib/system/libsystem_pthread.dylib)
==57071==    by 0x10842AB76: start_wqthread (in /usr/lib/system/libsystem_pthread.dylib)
==57071==  Address 0x18 is not stack'd, malloc'd or (recently) free'd
==57071== 
==57071== 
==57071== Process terminating with default action of signal 11 (SIGSEGV)
==57071==  Access not within mapped region at address 0x18
==57071==    at 0x10842BC10: _pthread_wqthread_setup (in /usr/lib/system/libsystem_pthread.dylib)
==57071==    by 0x10842B942: _pthread_wqthread (in /usr/lib/system/libsystem_pthread.dylib)
==57071==    by 0x10842AB76: start_wqthread (in /usr/lib/system/libsystem_pthread.dylib)
==57071==  If you believe this happened as a result of a stack
==57071==  overflow in your program's main thread (unlikely but
==57071==  possible), you can try to increase the size of the
==57071==  main thread stack using the --main-stacksize= flag.
==57071==  The main thread stack size used in this run was 8388608.
==57071== 
==57071== HEAP SUMMARY:
==57071==     in use at exit: 1,461,775 bytes in 1,015 blocks
==57071==   total heap usage: 1,346 allocs, 331 frees, 2,737,228 bytes allocated
==57071== 
==57071== LEAK SUMMARY:
==57071==    definitely lost: 11,030 bytes in 196 blocks
==57071==    indirectly lost: 4,872 bytes in 106 blocks
==57071==      possibly lost: 5,370 bytes in 92 blocks
==57071==    still reachable: 61,748 bytes in 185 blocks
==57071==                       of which reachable via heuristic:
==57071==                         newarray           : 56 bytes in 1 blocks
==57071==         suppressed: 1,378,755 bytes in 436 blocks
==57071== Rerun with --leak-check=full to see details of leaked memory
==57071== 
==57071== For lists of detected and suppressed errors, rerun with: -s
==57071== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 53 from 4)

Note: I am using macos_valgrind which segfaults in this example, but still the leaks happen to be in Linux too.

To Reproduce
Steps to reproduce the behavior:

  1. On macOS Catalina, Version 10.15.7 (19H2), install this valgrind.
  2. Install MLX42.
  3. Write a main.c containing the example code above.
  4. Compile the code to output a.out.
  5. Do valgrind ./a.out

Desktop (please complete the following information):

  • OS: macOS Catalina
  • Version: 10.15.7 (19H2)

[REQUEST] Update README example

Hello Good day!

It bothers me that the example given on the README doesn't compiles straight away with -Wall -Werror & -Wextra
Even more because the recommended Makefile does indeed include this flags, so my proposal would be to fix it.

The issues are as follows:
Screenshot from 2024-01-23 13-34-09

  1. srcs/main.c:25:31: error: comparison of integer expressions of different signedness: โ€˜int32_tโ€™ {aka โ€˜intโ€™} and โ€˜uint32_tโ€™ {aka โ€˜unsigned intโ€™} [-Werror=sign-compare] (for both the loops)
  2. srcs/main.c:23:25: error: unused parameter โ€˜paramโ€™ [-Werror=unused-parameter]
  3. srcs/main.c:58:22: error: unused parameter โ€˜argcโ€™ [-Werror=unused-parameter]
  4. srcs/main.c:58:40: error: unused parameter โ€˜argvโ€™ [-Werror=unused-parameter]

Solutions:

  1. use uint32_t instead of int32_t
  2. (void) param;
  3. & 4. int main(void) {

If you allow me, I can submit a PR with this changes :D

Cheers, and keep it up, this library is Gold! ๐Ÿ†

[BUG] dependent find variable under Linux

while trying to build your library the makefile for Linux
was trying to execute find with an absolute path:
https://github.com/W2Codam/MLX42/blob/5b5140f9c8b29381b9bcc84a185bad9e2f072aeb/Makefile_Unix.mk#L26
while this work for cygwin certain linux distribution could have there executable
somewhere else
like Nixos in my case ; this can cause a "file not found"
i made a possible solution to this:

DETECTED_OS := $(shell uname -s)

ifeq ($(DETECTED_OS),Linux)

FIND=find

else

FIND=/usr/bin/find

endif

SHDR	=	src/mlx_vert.c src/mlx_frag.c

SHDRSRC=	shaders/default.frag shaders/default.vert

LIBS	=	$(shell $(FIND) ./lib -iname "*.c")

SRCS	=	$(shell $(FIND) ./src -iname "*.c") $(SHDR) $(LIBS)

why:
i was about to package your library in a nix package so it can be deployed easly with certain version

[BUG] mlx_update_matrix ignores passed width and height

Describe the bug
The function mlx_update_matrix ignores its arguments

To Reproduce
Steps to reproduce the behavior:

  1. Call mlx_update_matrix with any parameter
  2. Don't see any difference

Expected behavior
I expect that the function would use its parameters. If the parameters should always be ignored, I expect the function to use local variables instead.

Additional context
This is an internal function, so nobody should call it and this bug doesn't matter if mlx42 still works as a whole. But I though it would be nice to let you know anyways, I find it very confusing.

[REQUEST] Support for retina displays

Is your feature request related to a problem? Please describe.
Currently the window doesn't seem to match the inherent size of the screen. A.K.A 1000 x 1000 fills up way more of the screen that it's supposed too. Limiting the size you can create your screen even though it should support more.

Describe the solution you'd like
Either a flag, function call or something to turn on retina support

Describe alternatives you've considered
Unlike the former mlx this mlx crops the content and mushes it a bit where as the former version would create a window bigger than the screen. Using a screenshot hack you could still grab the pictures. With this version you get a weirdly cropped picture.

Additional context
Leon do you have any other pants that aren't checkered or with lines?

Arm64 compatibility (Apple Silicon)

Hey there!

I tried to get the library working for my new M1 mac, but no luck so far. I did find a arm64 compatible glfw-library and got it to work, but for some reason gcc keeps saying that the libmlx42.a that CMake/Make produces is built for x86_64. I disabled linking to the glfw library (I do that when compiling my project) but that won't do it. I'm more than willing to solve this myself but don't know where to look for specific x86 bits.

Kind regards,
Albert van Andel

afbeelding

[BUG] Depth issue with mlx_delete_image()

Describe the bug
There is an issue with depth, see the code below.

To Reproduce

void	loop(void *param)
{
	t_data				*data;
	static mlx_image_t	*image = NULL;
	int32_t				instance_1_id;
	int32_t				instance_2_id;

	data = param;

	// WHEN THIS IS COMMENTED IN, THE SECOND SQUARE DOESN'T GET DRAWN
	if (image != NULL)
	{
		mlx_delete_image(data->mlx, image);
		image = NULL;
	}

	if (image == NULL)
	{
		image = mlx_new_image(data->mlx, 100, 100);
		ft_memset(image->pixels, 255, image->width * image->height * sizeof(int));

		instance_1_id = mlx_image_to_window(data->mlx, image, 0, 0);
		instance_2_id = mlx_image_to_window(data->mlx, image, 100, 100);
	}
}

t_i32	main(void)
{
	t_data	data;

	ft_bzero(&data, sizeof(t_data));
	data.mlx = mlx_init(200, 200, "", false);
	mlx_loop_hook(data.mlx, loop, &data);
	mlx_loop(data.mlx);
	return (EXIT_SUCCESS);
}

Expected behavior
The second square to be drawn, see the comment in the code.

Additional context
If you replace the const float depth = mlxctx->zdepth; with const float depth = 1000000; inside of mlx_update_matrix() you'll see that everything works as expected, though hardcoding it to such a low value is obviously problematic when you create more than a million instances during the lifetime of the program. Ideally you also wouldn't set it to a huge ass constant since it'd still be technically reachable if you ran the program long enough, though how you resolve this issue is up to you.

[BUG] can't draw on the image/window

Describe the bug
mlx_put_pixel isn't putting pixels on image

To Reproduce

  1. copy the code from the README.md (or below) to a .c file.
click the arrow to see the code
// -----------------------------------------------------------------------------
// Codam Coding College, Amsterdam @ 2022-2023 by W2Wizard.
// See README in the root project for more information.
// -----------------------------------------------------------------------------

#include <stdio.h>
#include <stdlib.h>
#include <stdbool.h>
#include <MLX42/MLX42.h>

#define WIDTH 512
#define HEIGHT 512

static mlx_image_t* image;

// -----------------------------------------------------------------------------

int32_t ft_pixel(int32_t r, int32_t g, int32_t b, int32_t a)
{
    return (r << 24 | g << 16 | b << 8 | a);
}

void ft_randomize(void* param)
{
	for (int32_t i = 0; i < image->width; ++i)
	{
		for (int32_t y = 0; y < image->height; ++y)
		{
			uint32_t color = ft_pixel(
				rand() % 0xFF, // R
				rand() % 0xFF, // G
				rand() % 0xFF, // B
				rand() % 0xFF  // A
			);
			mlx_put_pixel(image, i, y, color);
		}
	}
}

void ft_hook(void* param)
{
	mlx_t* mlx = param;

	if (mlx_is_key_down(mlx, MLX_KEY_ESCAPE))
		mlx_close_window(mlx);
	if (mlx_is_key_down(mlx, MLX_KEY_UP))
		image->instances[0].y -= 5;
	if (mlx_is_key_down(mlx, MLX_KEY_DOWN))
		image->instances[0].y += 5;
	if (mlx_is_key_down(mlx, MLX_KEY_LEFT))
		image->instances[0].x -= 5;
	if (mlx_is_key_down(mlx, MLX_KEY_RIGHT))
		image->instances[0].x += 5;
}

// -----------------------------------------------------------------------------

int32_t main(int32_t argc, const char* argv[])
{
	mlx_t* mlx;

	// Gotta error check this stuff
	if (!(mlx = mlx_init(WIDTH, HEIGHT, "MLX42", true)))
	{
		puts(mlx_strerror(mlx_errno));
		return(EXIT_FAILURE);
	}
	if (!(image = mlx_new_image(mlx, 128, 128)))
	{
		mlx_close_window(mlx);
		puts(mlx_strerror(mlx_errno));
		return(EXIT_FAILURE);
	}
	if (mlx_image_to_window(mlx, image, 0, 0) == -1)
	{
		mlx_close_window(mlx);
		puts(mlx_strerror(mlx_errno));
		return(EXIT_FAILURE);
	}
	
	mlx_loop_hook(mlx, ft_randomize, mlx);
	mlx_loop_hook(mlx, ft_hook, mlx);

	mlx_loop(mlx);
	mlx_terminate(mlx);
	return (EXIT_SUCCESS);
}
  1. compile it.
  2. run.

Expected behavior
It should make a square with random colors just like a static TV.

Screenshots
image

Desktop (please complete the following information):

  • OS: openSUSE (via WSL2)
  • Version: tumbleweed v20230925

Additional context
The MLX from France works fine, but I'm doing my project (cub3D) with this one because is faster and better

All mlx_images_to_window show the same image

**Repost from general forum.

Since the last commit (29 march 2024), all of my opened images with the mlx_image_to_window show the same image. The first screenshot show cube3d after the last commit, the second one with the commit of early february. This is on the school mac of Quebec 42 (Catalina).

Any clue what's causing this bug?

Screen Shot 2024-03-31 at 4 28 06 PM Screen Shot 2024-03-31 at 4 30 26 PM

MLX last commit failed some unit tests and the project has incorrect rendering

Describe the bug
There is a bug how program render minimap and other features in cub3d project

With the latest commit:
commit 5bed557 (HEAD -> master, origin/master, origin/HEAD)
Author: W2Wizard [email protected]
Date: Sat Mar 30 02:02:32 2024 +0100

The program is rendering the data incorrectly. We cannot not see:

  • a minimap
  • fps monitor
  • center aim
no_map

but when i switch to this commit:
commit f87c401 (HEAD)
Author: W2Wizard [email protected]
Date: Fri Mar 29 15:33:14 2024 +0100

or even this commit
commit 5e826c2 (HEAD)
Author: W2Wizard [email protected]
Date: Wed Feb 28 12:49:56 2024 +0100

the program is rendering the image correctly. We can see:

  • a minimap
  • fps monitor
  • center aim
yes_map

To Reproduce
Steps to reproduce the behavior:

  1. Go to and dowload the project https://github.com/ShroomySquid/Cub3D
  2. Compile: make
  3. Run a game: ./cub3d ./maps/valid_map.cub
  4. See an error

Desktop

  • OS: MacOS
  • Version: Catalina 10.15.7

[BUG] Issues finding the glfw header file, Compile Error and as small Makefile example issues

For this errors I used a freshly installed MLX42, the Makefile and so_long.c example in Basics.md.

MLX42 has issues finding the headers file of my glfw which I installed with 42homebrew and it's in the .brew directory. Although cmake finds it while executing Findglfw3.cmake file when the files are compiling I get this error message:

In file included from MLX42/src/font/mlx_font.c:14:
./MLX42/include/MLX42/MLX42_Int.h:23:11: fatal error: 'GLFW/glfw3.h' file not found
# include <GLFW/glfw3.h>

I basically fixed this issue by putting "-I ~/.brew/Cellar/glfw/3.3.8/include/" into my HEADERS variable in the Makefile.

Also would be nice if we can add "$ENV{HOME}/homebrew/include/" and "$ENV{HOME}/homebrew/lib/" to the Findglfw3.cmake file for some people that install brew the "Untar anywhere (unsupported)" way which tells you to install it in ~/homebrew directory.

After the first error fixed with modifing the HEADERS variable in Makefile when I try to compile I get the error message:

MLX42/src/mlx_images.c:90:17: error: comparison of integers of different signs: 'int32_t' (aka 'int') and 'size_t' (aka 'unsigned long') [-Werror,-Wsign-compare]
if (img->count >= ctx->instances_capacity)

No idea how to fix it and it seems to me like a library issue.

And the last little thing for the Makefile example would be in the "clean" command to add a -r flag to:
@rm -f $(LIBMLX)/build

Since it's a directory with stuff in it that you can't remove without this flag. cmake also creates the directory if it doesn't exist with the -B flag so no need to change more.

I tried it on the 42 Mac at school

Pixel color incorrect - appears cyan instead of white, possible red channel rendering issue

When attempting to draw pixels on the screen using the provided pixel_put function, pixels intended to be white are instead rendered as cyan. This discrepancy suggests a potential problem with how the red channel is being handled during the rendering process.

static void pixel_put(mlx_image_t *image, int x, int y, int color)
{
    int i;
    unsigned char *pixel;

    if ((unsigned)x < (*image).width && (unsigned)y < (*image).height)
    {
        pixel = (*image).pixels + (y * (*image).width + x) * sizeof(int);
        i = sizeof(int) * 6;
        while (i >= 0)
        {
            *pixel++ = (color >> i) & 0xFF;
            i -= sizeof(int) * 2;
        }
    }
}

``
The pixel_put function is responsible for placing a pixel of a specified color at the given coordinates on an image. It operates by manipulating the pixel's color values, byte by byte, to set the appropriate RGB components.

This issue has been observed across multiple platforms, including Arch Linux and macOS Catalina. 

[BUG] segfault when using mlx_create_cursor

Describe the bug
When i try to change the cursor in this small project, it segfaults when trying to do mlx_create_cursor

To Reproduce

#include <stdio.h>
#include "MLX42/MLX42.h"

int32_t	main(void)
{
	mlx_t	*mlx;

	mlx = mlx_init(500, 500, "MLX42", true);
	if (!mlx)
		return (0);
	printf("ok\n");
	mlx_texture_t* tex = mlx_load_png("./GitHub-Mark-32px.png");
	printf("ok1\n");
	mlx_create_cursor(tex);
	printf("ok2\n");
	mlx_loop(mlx);
	mlx_terminate(mlx);
	return (1);
}

Screenshots
If applicable, add screenshots to help explain your problem.
Screen Shot 2023-01-20 at 1 36 46 PM

Desktop (please complete the following information):

  • OS: MacOS
  • Version Catalina 10.15.7

Additional context
GitHub-Mark-32px the png i use.

[REQUEST] better resize control on Mac OS X

Is your feature request related to a problem? Please describe.
I want to create smooth resize experience on Mac OS X.

Describe the solution you'd like
I want mlx_resize_callback redraw everything after executing my hook.

Describe alternatives you've considered
I wanted to call force-redraw from my hook myself, but I can't do it using only MLX42 public functions.

Additional context
When resizing the window on OS X, glfw.PollEvents() blocks and does not return until the user releases mouse button to stop resizing glfw/glfw#408 MLX42 only redraws in its main loop, so no update is possible while the loop is blocked by resizing. So on resize one gets distorted image and can't do anything about it.

Inconsistencies in private/public functions

There are some inconsistencies in the use of //= private =// and //= public =//.
I think the private functions are all static and the public functions are all non-static.

[BUG] Unable to use MLX as a submodule

Describe the bug
git submodule update --init --recursive --remote can't run as there is no .gitmodules for googletest-src

To Reproduce
Steps to reproduce the behavior:

  1. Init a new git repository
  2. Add MLX as a submodule
  3. Run git submodule update --init --recursive --remote

Expected behavior
MLX compiles without a problem, as it has done before.

Screenshots
Screen Shot 2023-03-03 at 10 50 43 AM

Desktop (please complete the following information):

  • OS: [MacOS]
  • Version: [Catalina], Version 10.15.7 (19H1715)

Additional context
My tip would be that the broken chage is with Pull request #94, but I'm not sure

[BUG] Minimizing the window in Windows crashes the application

Describe the bug
When minimizing the window or clicking on the icon it simply crashes...

To Reproduce
Steps to reproduce the behavior:

  1. Launch the application in windows
  2. Click on the Icon or the minimize widget
  3. RIP

Expected behavior
It should not crash! Even the basic GLFW example doesn't.

image

Desktop:

  • OS: Windows 11

[BUG] doesn't work with X11 redirection on Linux VM on MacOS

Describe the bug
MLX42 doesn't seem to be working when used with X11 redirection on Linux VM on MacOS.

To Reproduce
Steps to reproduce the behavior:

  • Install XQuartz (brew install --cask xquartz)
  • Install Lima (brew install lima)
  • Create a new instance (limactl create bug)
  • Select Open an editor to review or modify the current configuration, set those variables to true
  # Forward X11 into the instance
  # ๐ŸŸข Builtin default: false
  forwardX11: true
  # Trust forwarded X11 clients
  # ๐ŸŸข Builtin default: false
  forwardX11Trusted: true
  • Save and launch (limactl start bug if necessary)
  • limactl shell bug
  • cd /tmp/lima
  • Install MLX42 deps (sudo apt update && sudo apt install build-essential libx11-dev libglfw3-dev libglfw3 xorg-dev cmake -y)
  • Download and build MLX42
  • cd ..
  • create a minimal main.c
#include "MLX42/include/MLX42/MLX42.h"

int	main(void)
{
	mlx_t	*mlx = mlx_init(512, 512, "MLX42", true);
}
  • gcc main.c MLX42/build/libmlx42.a -Iinclude -ldl -lglfw -pthread -lm
  • ./a.out
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
Segmentation fault (core dumped)

Expected behavior
Nothing because no mlx_loop but not errors.
We can check that X11 redirection is working:

  • sudo apt install x11-apps
  • xeyes

Desktop (please complete the following information):

  • OS: MacOS
  • Version: Sonoma 14.0 (23A344)
  • Device: MacBook Pro M1

Additional context
We can remove the first 2 errors using export LIBGL_ALWAYS_INDIRECT=1. But I'm not sure if it sweeps the errors under the carpet or if it's really fixing part of the issue.

Readme not reflecting CMake

There is no CMake documentation for Linux and mac in the readme.
Please add examples on how to compile it and add some documentation on how to integrate it with a normal Makefile.
With kind regards
@JellevanKraaij & @Abdi-29

[BUG] Leaks on mlx_init (glfw)

Describe the bug
The mlx_init function does not free all that is allocated.

To Reproduce
Steps to reproduce the behavior:

Exemple script :

  • Install MLX42 and compile it
#include "./MLX42/include/MLX42/MLX42.h"

int32_t	main(void)
{
	mlx_t* mlx;

	mlx = mlx_init(500, 500, "MLX42", 0);
	mlx_loop(mlx);
	mlx_terminate(mlx);
	return (0);
}

When the window is closed, we get this kind of leaks ("still reachable")

==27289== 1 bytes in 1 blocks are still reachable in loss record 1 of 2,004
==27289==    at 0x483877F: malloc (vg_replace_malloc.c:307)
==27289==    by 0x4C48AB2: _XlcDefaultMapModifiers (in /usr/lib/x86_64-linux-gnu/libX11.so.6.4.0)
==27289==    by 0x4C48DE6: XSetLocaleModifiers (in /usr/lib/x86_64-linux-gnu/libX11.so.6.4.0)
==27289==    by 0x486871B: ??? (in /usr/lib/x86_64-linux-gnu/libglfw.so.3.3)
==27289==    by 0x4860059: glfwInit (in /usr/lib/x86_64-linux-gnu/libglfw.so.3.3)
==27289==    by 0x10A82C: mlx_init (in /home/lduthill/42/TEST/cub3D)
==27289==    by 0x10A2D8: main (main.c:22)
==27289== 
==27289== 2 bytes in 1 blocks are still reachable in loss record 2 of 2,004
==27289==    at 0x483877F: malloc (vg_replace_malloc.c:307)
==27289==    by 0x494DB7A: strdup (strdup.c:42)
==27289==    by 0x4C41787: _XlcCreateLC (in /usr/lib/x86_64-linux-gnu/libX11.so.6.4.0)
==27289==    by 0x4C5E340: _XlcDefaultLoader (in /usr/lib/x86_64-linux-gnu/libX11.so.6.4.0)
==27289==    by 0x4C48CED: _XOpenLC (in /usr/lib/x86_64-linux-gnu/libX11.so.6.4.0)
==27289==    by 0x4C48E38: XSupportsLocale (in /usr/lib/x86_64-linux-gnu/libX11.so.6.4.0)
==27289==    by 0x486735C: ??? (in /usr/lib/x86_64-linux-gnu/libglfw.so.3.3)
==27289==    by 0x4860059: glfwInit (in /usr/lib/x86_64-linux-gnu/libglfw.so.3.3)
==27289==    by 0x10A82C: mlx_init (in /home/lduthill/42/TEST/cub3D)
==27289==    by 0x10A2D8: main (main.c:22)
==27289== 
==27289== 2 bytes in 1 blocks are still reachable in loss record 3 of 2,004
==27289==    at 0x483877F: malloc (vg_replace_malloc.c:307)
==27289==    by 0x494DB7A: strdup (strdup.c:42)
==27289==    by 0x4C3E301: _XlcResolveLocaleName (in /usr/lib/x86_64-linux-gnu/libX11.so.6.4.0)
==27289==    by 0x4C41957: ??? (in /usr/lib/x86_64-linux-gnu/libX11.so.6.4.0)
==27289==    by 0x4C40F22: ??? (in /usr/lib/x86_64-linux-gnu/libX11.so.6.4.0)
==27289==    by 0x4C41738: _XlcCreateLC (in /usr/lib/x86_64-linux-gnu/libX11.so.6.4.0)
==27289==    by 0x4C5E340: _XlcDefaultLoader (in /usr/lib/x86_64-linux-gnu/libX11.so.6.4.0)
==27289==    by 0x4C48CED: _XOpenLC (in /usr/lib/x86_64-linux-gnu/libX11.so.6.4.0)
==27289==    by 0x4C48E38: XSupportsLocale (in /usr/lib/x86_64-linux-gnu/libX11.so.6.4.0)
==27289==    by 0x486735C: ??? (in /usr/lib/x86_64-linux-gnu/libglfw.so.3.3)
==27289==    by 0x4860059: glfwInit (in /usr/lib/x86_64-linux-gnu/libglfw.so.3.3)
==27289==    by 0x10A82C: mlx_init (in /home/lduthill/42/TEST/cub3D)

Your OS :

  • On all PCs (MacOs, WSL under Debian)

Additional context
All libraries have been installed and are up to date glfw and cmake

This happens on all my code that uses mlx_init()

[BUG] Error messages while compiling

Error messages while compiling

Steps to reproduce the behavior:

  1. Running cmake -DBUILD_TESTS=ON -B build && cmake --build build --parallel
  2. Error at [ 68%] Linking C static library libmlx42.a

Error messages:

/MLX42/build/_deps/googletest-src/googletest/include/gtest/gtest-printers.h:532:9: error: implicit conversion from 'int32_t' (aka 'int') to 'float' may lose precision [-Wimplicit-int-float-conversion]
    if (static_cast<int32_t>(val * mulfor6 + 0.5) / mulfor6 == val) return 6;
        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~
/MLX42/build/_deps/googletest-src/googletest/include/gtest/gtest-printers.h:551:17: error: in instantiation of function template specialization 'testing::internal::AppropriateResolution<float>' requested here
  os->precision(AppropriateResolution(f));
                ^
/MLX42/build/_deps/googletest-src/googletest/include/gtest/gtest-printers.h:544:9: error: implicit conversion from 'int32_t' (aka 'int') to 'float' may lose precision [-Wimplicit-int-float-conversion]
    if (static_cast<int32_t>(val / divfor6 + 0.5) * divfor6 == val) return 6;
        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~

The errors stop the built process. I deactivated -Wall -Werror -Wextra and it built. The unit tests 'ctest --output-on-failure --test-dir build' were passed.

OS: Ubuntu 22.04.1 LTS

[BUG] Shader build process executing incorrectly

Describe the bug
Cmake builds MLX42 incorrectly when a folder name contains a space character.

To Reproduce
Steps to reproduce the behavior:

  1. mkdir [name] - Make sure name contains a space. Ex: "test test"
  2. cd [name]
  3. git clone https://github.com/codam-coding-college/MLX42.git
  4. cd MLX42
  5. cmake -B build
  6. cmake --build build -j4 or do make -C build -j4

Expected behavior
MLX42 should be built without any issues.

Screenshots
Screen Shot 2023-02-24 at 12 14 43 PM

Screen Shot 2023-02-24 at 12 34 43 PM

Should contain const char* frag_shader = "#version 330 core\n" instead of const char* frag_shader = "\n"

Additional context
Apparently Cmake sees dir "test test" as 2 different directories, so when it tries to compile the shaders it can't find the files because it doesn't find the correct folder . (See screenshot)
MLX42 still gets built, but when you try to execute any code that uses the library its gives a version missing error. (See second screenshot)

[BUG] when compiling gives GLSL error message

Hi! When trying to run cub3d we get " 0:2(201): error: sampler arrays indexed with non-constant expressions are forbidden in GLSL 1.30 and later ", as an error message.

To Reproduce
Steps to reproduce the behavior:

  1. Go to 'https://github.com/DjoykeAbyah/42_CUB3D'
  2. clone repo
  3. make or make re
  4. run ./cub3d ./maps/basic.cub
  5. see error.

Expected behavior
It should not give an error

Desktop (please complete the following information):

  • Apple Inc. iMac18,3
  • Ubuntu 22.04.3 LTS

Additional context
We tried to reduce our code to the bare minimum to see where it goes wrong. just have a main with init.mlx in there and a infinite while loop. That still gave the same error.
Also on our Windows laptop and Mac laptop it worked just fine.

[BUG] Function passed to mlx_key_hook() seems to get called twice.

Description
Function passed to mlx_key_hook() seems to be called twice, when only
one key press has occurred.

To Reproduce

static void	keycodes(mlx_key_data_t keydata, void *param)
{
	if (param)
		;
	ft_printf("%c\n", keydata.key);
}

int	gameloop(t_reality *reality)
{
	mlx_key_hook(reality -> mlx, keycodes, NULL);
	mlx_loop(reality -> mlx);
	return (TRUE);
}

Expected behavior
When key is pressed, given function to mlx_key_hook() should only run once.

Desktop

  • OS: Error occurs on MacOS and Arch Linux

Apologies if this issue is caused by a misunderstanding of the use of hooks.

[BUG] Address sanitizer reports leaks

  • Linux machine (Archlinux)
  • MLX42 v2.3.1
    I have copied the same code in the README.md, I compiled it with -fsanitize=leak flag and it reports memory leaks
    when I removed the mlx_terminate() function it's no longer showing memory leaks

Screenshot from 2023-04-19 09-10-57

[BUG] Double free cause by mlx_freen when executing mlx_terminate

Describe the bug
When exiting the program, i call mlx_terminate which is gonna try and deallocate all mlx related memory. When mlx_lstclear is called with mlx_freen as argument to try and free all mlx images it causes a double free.

To Reproduce
Im not really sure how to reproduce this.
It think it has something to do with multiple images using the same allocated pixel buffer pointer.

Expected behavior
The program should exit without any problems

Screenshots
Screen Shot 2023-03-31 at 12 43 24 PM

Desktop:

  • OS: MacOS
  • Version: Mojave

Additional context
Im allocating the pixel buffers for my animations manually. All the enemies play the same animation at the same time, so they use the same pixel buffer pointer. Im assuming it has something to do with that.

[BUG] mlx_terminate segfaults

NOTE
Before creating a bug report! Make sure you git pull from master and check if the bug still exists!

Describe the bug
mlx_terminate segfaults with minimal program

To Reproduce

# include "MLX42/MLX42.h"
# include <stdio.h>
# include <stdlib.h>

# define WIDTH 512
# define HEIGHT 512

int    main(void)
{
    mlx_t    *mlx;

    if (!(mlx = mlx_init(WIDTH, HEIGHT, "MLX42", true)))
    {
        puts(mlx_strerror(mlx_errno));
        return(EXIT_FAILURE);
    }
}
FROM ubuntu:latest

RUN apt-get update && apt-get install -y \
    gcc \
    g++ \
    cmake \
    libglfw3 \
    libglfw3-dev \
    libgl1-mesa-dev \
    xorg \
    mesa-utils \
    git \
    libgl1-mesa-glx \
    libgl1-mesa-dri \


ENV DISPLAY=:0

RUN git clone https://github.com/codam-coding-college/MLX42.git /MLX42

COPY minilibx.c /tmp

WORKDIR /tmp

RUN cd /MLX42 && cmake -B build -DCMAKE_BUILD_TYPE=Debug && cmake --build build -j4

CMD gcc minilibx.c -g /MLX42/build/libmlx42.a -I/MLX42/include -ldl -lglfw -pthread -lm && ./a.out

Expected behavior
Either open a window and quickly close it, or terminate with an error

Desktop (please complete the following information):

  • OS: ubuntu
  • Version: 22.04

Additional context
I first had these errors on our linux cluster computers:

f0r3s1% gcc mlxtest.c ../MLX42/build/libmlx42.a -I../MLX42/include
-ldl -lglfw -pthread -lm
f0r3s1% ./a.out
zsh: segmentation fault (core dumped)  ./a.out
f0r3s1% ./a.out
LLVM ERROR: Do not know how to split the result of this operator!

zsh: IOT instruction (core dumped)  ./a.out
f0r3s1% ./a.out
LLVM ERROR: Do not know how to split the result of this operator!

zsh: IOT instruction (core dumped)  ./a.out
LLVM ERROR: Invalid size request on a scalable vector.
free(): invalid pointer
fish: Job 1, './a.out' terminated by signal SIGABRT (Abort)

all on the same code. I tried to find the issue with address sanitizer, but then the bug goes away and never comes back, even without the sanitizer. So then I couldn't reproduce it anymore and I tried a docker. This segfault could be the issue. Maybe there are multiple issues.

[BUG] Recursive Make calls not working

NOTE
I was trying to setup your library (Great Job btw) on my project but in didnt work compile with the recursive call of make (Make -C folder/).

Describe the bug
The command "Make -C" with the library return highly inconsistent result. Either not compiling every file or trying to compile file in folder ending in .c which does not work. And Make -C fclean does the same

To Reproduce

  1. Clone the library
  2. Execute "Make -C MLX42"
  3. Execute "Make -C MLX42 fclean"
  4. Repeat multiple times 2 and 3 to see the inconsistencies.

Expected behavior
"Make -C MLX42" will not compile every file each times. It will either only compile the shader files (alias frag_shader and vert_shader) or all files.
Make

"Make -C MLX42 fclean" will delete everyfile but sometimes it will try to delete "src/mlx_cursor.c/mlx_font.o" for example which will not work.
Make_fclean

Desktop (please complete the following information):

  • MacOS Catalina 10.15.7

[REQUEST] Add ability to scale images with window size.

There is no way to resize an image when the window gets resized.
If you comment out line 68 this effect can be achieved, but it would be better to have it as an option somewhere:

MLX42/src/mlx_init.c

Lines 67 to 69 in 0103a86

// NOTE: Call manually once to calculate View Projection Matrix
glfwSetWindowSizeCallback(mlx->window, &mlx_on_resize);
mlx_on_resize(mlx->window, mlx->width, mlx->height);

Issue88-continue

To help you better understand what the leaks origins might be, i had this output of valgrind(valgrind-3.20.0 Linux) of the executable of the example in the bottom of this repo's README.md. (I hope it serves useful!)

==23779== Memcheck, a memory error detector
==23779== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==23779== Using Valgrind-3.20.0-5147d671e4-20221024 and LibVEX; rerun with -h for copyright info
==23779== Command: ./a.out
==23779== Parent PID: 3604
==23779== 
--23779-- 
--23779-- Valgrind options:
--23779--    --verbose
--23779--    --leak-check=full
--23779--    --track-origins=yes
--23779--    --log-file=valgrind_output_new
--23779-- Contents of /proc/version:
--23779--   Linux version 5.8.0-63-generic (buildd@lgw01-amd64-035) (gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #71~20.04.1-Ubuntu SMP Thu Jul 15 17:46:08 UTC 2021
--23779-- 
--23779-- Arch and hwcaps: AMD64, LittleEndian, amd64-cx16-lzcnt-rdtscp-sse3-ssse3
--23779-- Page sizes: currently 4096, max supported 4096
--23779-- Valgrind library directory: /usr/local/libexec/valgrind
--23779-- Reading syms from /home/linus-penguin/mlx_project/a.out
--23779-- Reading syms from /usr/lib/x86_64-linux-gnu/ld-2.31.so
--23779--   Considering /usr/lib/x86_64-linux-gnu/ld-2.31.so ..
--23779--   .. CRC mismatch (computed 6cded93a wanted 1af57820)
--23779--   Considering /lib/x86_64-linux-gnu/ld-2.31.so ..
--23779--   .. CRC mismatch (computed 6cded93a wanted 1af57820)
--23779--   Considering /usr/lib/debug/lib/x86_64-linux-gnu/ld-2.31.so ..
--23779--   .. CRC is valid
--23779-- Reading syms from /usr/local/libexec/valgrind/memcheck-amd64-linux
--23779--    object doesn't have a dynamic symbol table
--23779-- Scheduler: using generic scheduler lock implementation.
--23779-- Reading suppressions file: /usr/local/libexec/valgrind/default.supp
==23779== embedded gdbserver: reading from /tmp/vgdb-pipe-from-vgdb-to-23779-by-linus-penguin-on-???
==23779== embedded gdbserver: writing to   /tmp/vgdb-pipe-to-vgdb-from-23779-by-linus-penguin-on-???
==23779== embedded gdbserver: shared mem   /tmp/vgdb-pipe-shared-mem-vgdb-23779-by-linus-penguin-on-???
==23779== 
==23779== TO CONTROL THIS PROCESS USING vgdb (which you probably
==23779== don't want to do, unless you know exactly what you're doing,
==23779== or are doing some strange experiment):
==23779==   /usr/local/libexec/valgrind/../../bin/vgdb --pid=23779 ...command...
==23779== 
==23779== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==23779==   /path/to/gdb ./a.out
==23779== and then give GDB the following command
==23779==   target remote | /usr/local/libexec/valgrind/../../bin/vgdb --pid=23779
==23779== --pid is optional if only one valgrind process is running
==23779== 
--23779-- REDIR: 0x4022d80 (ld-linux-x86-64.so.2:strlen) redirected to 0x580be542 (vgPlain_amd64_linux_REDIR_FOR_strlen)
--23779-- REDIR: 0x4022b50 (ld-linux-x86-64.so.2:index) redirected to 0x580be55c (vgPlain_amd64_linux_REDIR_FOR_index)
--23779-- Reading syms from /usr/local/libexec/valgrind/vgpreload_core-amd64-linux.so
--23779-- Reading syms from /usr/local/libexec/valgrind/vgpreload_memcheck-amd64-linux.so
==23779== WARNING: new redirection conflicts with existing -- ignoring it
--23779--     old: 0x04022d80 (strlen              ) R-> (0000.0) 0x580be542 vgPlain_amd64_linux_REDIR_FOR_strlen
--23779--     new: 0x04022d80 (strlen              ) R-> (2007.0) 0x048426e0 strlen
--23779-- REDIR: 0x401f560 (ld-linux-x86-64.so.2:strcmp) redirected to 0x48436d0 (strcmp)
--23779-- REDIR: 0x40232e0 (ld-linux-x86-64.so.2:mempcpy) redirected to 0x4847330 (mempcpy)
--23779-- Reading syms from /usr/lib/x86_64-linux-gnu/libglfw.so.3.3
--23779--    object doesn't have a symbol table
--23779-- Reading syms from /usr/lib/x86_64-linux-gnu/libdl-2.31.so
--23779--   Considering /usr/lib/x86_64-linux-gnu/libdl-2.31.so ..
--23779--   .. CRC mismatch (computed a3ca3288 wanted 3cde2f36)
--23779--   Considering /lib/x86_64-linux-gnu/libdl-2.31.so ..
--23779--   .. CRC mismatch (computed a3ca3288 wanted 3cde2f36)
--23779--   Considering /usr/lib/debug/lib/x86_64-linux-gnu/libdl-2.31.so ..
--23779--   .. CRC is valid
--23779-- Reading syms from /usr/lib/x86_64-linux-gnu/libc-2.31.so
--23779--   Considering /usr/lib/x86_64-linux-gnu/libc-2.31.so ..
--23779--   .. CRC mismatch (computed cd1655d1 wanted 09373696)
--23779--   Considering /lib/x86_64-linux-gnu/libc-2.31.so ..
--23779--   .. CRC mismatch (computed cd1655d1 wanted 09373696)
--23779--   Considering /usr/lib/debug/lib/x86_64-linux-gnu/libc-2.31.so ..
--23779--   .. CRC is valid
==23779== WARNING: new redirection conflicts with existing -- ignoring it
--23779--     old: 0x049733d0 (memalign            ) R-> (1011.0) 0x048419a6 memalign
--23779--     new: 0x049733d0 (memalign            ) R-> (1017.0) 0x04841979 aligned_alloc
==23779== WARNING: new redirection conflicts with existing -- ignoring it
--23779--     old: 0x049733d0 (memalign            ) R-> (1011.0) 0x048419a6 memalign
--23779--     new: 0x049733d0 (memalign            ) R-> (1017.0) 0x0484194c aligned_alloc
==23779== WARNING: new redirection conflicts with existing -- ignoring it
--23779--     old: 0x049733d0 (memalign            ) R-> (1011.0) 0x048419a6 memalign
--23779--     new: 0x049733d0 (memalign            ) R-> (1017.0) 0x04841979 aligned_alloc
==23779== WARNING: new redirection conflicts with existing -- ignoring it
--23779--     old: 0x049733d0 (memalign            ) R-> (1011.0) 0x048419a6 memalign
--23779--     new: 0x049733d0 (memalign            ) R-> (1017.0) 0x0484194c aligned_alloc
--23779-- Reading syms from /usr/lib/x86_64-linux-gnu/libm-2.31.so
--23779--   Considering /usr/lib/x86_64-linux-gnu/libm-2.31.so ..
--23779--   .. CRC mismatch (computed b88da5c9 wanted 1658d783)
--23779--   Considering /lib/x86_64-linux-gnu/libm-2.31.so ..
--23779--   .. CRC mismatch (computed b88da5c9 wanted 1658d783)
--23779--   Considering /usr/lib/debug/lib/x86_64-linux-gnu/libm-2.31.so ..
--23779--   .. CRC is valid
--23779-- Reading syms from /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0
--23779--    object doesn't have a symbol table
--23779-- Reading syms from /usr/lib/x86_64-linux-gnu/libpthread-2.31.so
--23779--   Considering /usr/lib/debug/.build-id/4f/c5fc33f4429136a494c640b113d76f610e4abc.debug ..
--23779--   .. build-id is valid
--23779-- Reading syms from /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0
--23779--    object doesn't have a symbol table
--23779-- Reading syms from /usr/lib/x86_64-linux-gnu/libXau.so.6.0.0
--23779--   Considering /usr/lib/x86_64-linux-gnu/libXau.so.6.0.0 ..
--23779--   .. CRC mismatch (computed 7de9b6ad wanted e8a17129)
--23779--   Considering /lib/x86_64-linux-gnu/libXau.so.6.0.0 ..
--23779--   .. CRC mismatch (computed 7de9b6ad wanted e8a17129)
--23779--    object doesn't have a symbol table
--23779-- Reading syms from /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0
--23779--    object doesn't have a symbol table
--23779-- Reading syms from /usr/lib/x86_64-linux-gnu/libbsd.so.0.10.0
--23779--    object doesn't have a symbol table
--23779-- REDIR: 0x4978600 (libc.so.6:memmove) redirected to 0x48311ba (_vgnU_ifunc_wrapper)
--23779-- REDIR: 0x4977900 (libc.so.6:strncpy) redirected to 0x48311ba (_vgnU_ifunc_wrapper)
--23779-- REDIR: 0x4978930 (libc.so.6:strcasecmp) redirected to 0x48311ba (_vgnU_ifunc_wrapper)
--23779-- REDIR: 0x4977220 (libc.so.6:strcat) redirected to 0x48311ba (_vgnU_ifunc_wrapper)
--23779-- REDIR: 0x4977960 (libc.so.6:rindex) redirected to 0x48311ba (_vgnU_ifunc_wrapper)
--23779-- REDIR: 0x4979dd0 (libc.so.6:rawmemchr) redirected to 0x48311ba (_vgnU_ifunc_wrapper)
--23779-- REDIR: 0x4994e60 (libc.so.6:wmemchr) redirected to 0x48311ba (_vgnU_ifunc_wrapper)
--23779-- REDIR: 0x49949a0 (libc.so.6:wcscmp) redirected to 0x48311ba (_vgnU_ifunc_wrapper)
--23779-- REDIR: 0x4978760 (libc.so.6:mempcpy) redirected to 0x48311ba (_vgnU_ifunc_wrapper)
--23779-- REDIR: 0x4978590 (libc.so.6:bcmp) redirected to 0x48311ba (_vgnU_ifunc_wrapper)
--23779-- REDIR: 0x4977890 (libc.so.6:strncmp) redirected to 0x48311ba (_vgnU_ifunc_wrapper)
--23779-- REDIR: 0x49772d0 (libc.so.6:strcmp) redirected to 0x48311ba (_vgnU_ifunc_wrapper)
--23779-- REDIR: 0x49786c0 (libc.so.6:memset) redirected to 0x48311ba (_vgnU_ifunc_wrapper)
--23779-- REDIR: 0x4994960 (libc.so.6:wcschr) redirected to 0x48311ba (_vgnU_ifunc_wrapper)
--23779-- REDIR: 0x49777f0 (libc.so.6:strnlen) redirected to 0x48311ba (_vgnU_ifunc_wrapper)
--23779-- REDIR: 0x49773b0 (libc.so.6:strcspn) redirected to 0x48311ba (_vgnU_ifunc_wrapper)
--23779-- REDIR: 0x4978980 (libc.so.6:strncasecmp) redirected to 0x48311ba (_vgnU_ifunc_wrapper)
--23779-- REDIR: 0x4977350 (libc.so.6:strcpy) redirected to 0x48311ba (_vgnU_ifunc_wrapper)
--23779-- REDIR: 0x4978ad0 (libc.so.6:memcpy@@GLIBC_2.14) redirected to 0x48311ba (_vgnU_ifunc_wrapper)
--23779-- REDIR: 0x49960d0 (libc.so.6:wcsnlen) redirected to 0x48311ba (_vgnU_ifunc_wrapper)
--23779-- REDIR: 0x49949e0 (libc.so.6:wcscpy) redirected to 0x48311ba (_vgnU_ifunc_wrapper)
--23779-- REDIR: 0x49779a0 (libc.so.6:strpbrk) redirected to 0x48311ba (_vgnU_ifunc_wrapper)
--23779-- REDIR: 0x4977280 (libc.so.6:index) redirected to 0x48311ba (_vgnU_ifunc_wrapper)
--23779-- REDIR: 0x49777b0 (libc.so.6:strlen) redirected to 0x48311ba (_vgnU_ifunc_wrapper)
--23779-- REDIR: 0x4980d20 (libc.so.6:memrchr) redirected to 0x48311ba (_vgnU_ifunc_wrapper)
--23779-- REDIR: 0x49789d0 (libc.so.6:strcasecmp_l) redirected to 0x48311ba (_vgnU_ifunc_wrapper)
--23779-- REDIR: 0x4978550 (libc.so.6:memchr) redirected to 0x48311ba (_vgnU_ifunc_wrapper)
--23779-- REDIR: 0x4994ab0 (libc.so.6:wcslen) redirected to 0x48311ba (_vgnU_ifunc_wrapper)
--23779-- REDIR: 0x4977c60 (libc.so.6:strspn) redirected to 0x48311ba (_vgnU_ifunc_wrapper)
--23779-- REDIR: 0x49788d0 (libc.so.6:stpncpy) redirected to 0x48311ba (_vgnU_ifunc_wrapper)
--23779-- REDIR: 0x4978870 (libc.so.6:stpcpy) redirected to 0x48311ba (_vgnU_ifunc_wrapper)
--23779-- REDIR: 0x4979e10 (libc.so.6:strchrnul) redirected to 0x48311ba (_vgnU_ifunc_wrapper)
--23779-- REDIR: 0x4978a20 (libc.so.6:strncasecmp_l) redirected to 0x48311ba (_vgnU_ifunc_wrapper)
--23779-- REDIR: 0x4a058e0 (libc.so.6:__memcpy_chk) redirected to 0x48311ba (_vgnU_ifunc_wrapper)
--23779-- REDIR: 0x4978470 (libc.so.6:strstr) redirected to 0x48311ba (_vgnU_ifunc_wrapper)
--23779-- REDIR: 0x4977830 (libc.so.6:strncat) redirected to 0x48311ba (_vgnU_ifunc_wrapper)
--23779-- REDIR: 0x4989a30 (libc.so.6:__strrchr_sse2) redirected to 0x4842110 (__strrchr_sse2)
--23779-- REDIR: 0x4994070 (libc.so.6:__memset_sse2_unaligned) redirected to 0x4846270 (memset)
--23779-- REDIR: 0x4972260 (libc.so.6:malloc) redirected to 0x483c7dd (malloc)
--23779-- REDIR: 0x4973c90 (libc.so.6:calloc) redirected to 0x484139e (calloc)
--23779-- REDIR: 0x4989d30 (libc.so.6:__strlen_sse2) redirected to 0x4842620 (__strlen_sse2)
--23779-- REDIR: 0x4a56c50 (libc.so.6:__strncmp_sse42) redirected to 0x4842de0 (__strncmp_sse42)
--23779-- REDIR: 0x4993c40 (libc.so.6:memcpy@GLIBC_2.2.5) redirected to 0x4843800 (memcpy@GLIBC_2.2.5)
--23779-- REDIR: 0x4972850 (libc.so.6:free) redirected to 0x483f036 (free)
--23779-- REDIR: 0x4989820 (libc.so.6:__strchrnul_sse2) redirected to 0x4846e40 (strchrnul)
--23779-- REDIR: 0x4a05c90 (libc.so.6:__strcpy_chk) redirected to 0x4846eb0 (__strcpy_chk)
--23779-- REDIR: 0x4978120 (libc.so.6:__GI_strstr) redirected to 0x48475d0 (__strstr_sse2)
--23779-- REDIR: 0x4a654e0 (libc.so.6:__memcmp_sse4_1) redirected to 0x4845a80 (__memcmp_sse4_1)
--23779-- REDIR: 0x4973000 (libc.so.6:realloc) redirected to 0x48415eb (realloc)
--23779-- REDIR: 0x498f2a0 (libc.so.6:__strncpy_sse2_unaligned) redirected to 0x4842b90 (__strncpy_sse2_unaligned)
--23779-- REDIR: 0x4993560 (libc.so.6:__strstr_sse2_unaligned) redirected to 0x4847530 (strstr)
--23779-- REDIR: 0x49895f0 (libc.so.6:__strchr_sse2) redirected to 0x4842230 (__strchr_sse2)
--23779-- REDIR: 0x4993c20 (libc.so.6:__mempcpy_sse2_unaligned) redirected to 0x4846f50 (mempcpy)
--23779-- REDIR: 0x4984030 (libc.so.6:__memchr_sse2) redirected to 0x4843750 (memchr)
--23779-- REDIR: 0x4982520 (libc.so.6:__strcmp_sse2_unaligned) redirected to 0x48435d0 (strcmp)
--23779-- REDIR: 0x498ec70 (libc.so.6:__strcpy_sse2_unaligned) redirected to 0x4842710 (strcpy)
--23779-- Reading syms from /usr/lib/x86_64-linux-gnu/libXxf86vm.so.1.0.0
--23779--    object doesn't have a symbol table
--23779-- Reading syms from /usr/lib/x86_64-linux-gnu/libXext.so.6.4.0
--23779--   Considering /usr/lib/x86_64-linux-gnu/libXext.so.6.4.0 ..
--23779--   .. CRC mismatch (computed 7e27e1ef wanted 4ab025b2)
--23779--   Considering /lib/x86_64-linux-gnu/libXext.so.6.4.0 ..
--23779--   .. CRC mismatch (computed 7e27e1ef wanted 4ab025b2)
--23779--    object doesn't have a symbol table
--23779-- Reading syms from /usr/lib/x86_64-linux-gnu/libXi.so.6.1.0
--23779--    object doesn't have a symbol table
--23779-- Reading syms from /usr/lib/x86_64-linux-gnu/libXrandr.so.2.2.0
--23779--    object doesn't have a symbol table
--23779-- Reading syms from /usr/lib/x86_64-linux-gnu/libXrender.so.1.3.0
--23779--    object doesn't have a symbol table
--23779-- Reading syms from /usr/lib/x86_64-linux-gnu/libXcursor.so.1.0.2
--23779--    object doesn't have a symbol table
--23779-- Reading syms from /usr/lib/x86_64-linux-gnu/libXfixes.so.3.1.0
--23779--    object doesn't have a symbol table
--23779-- Reading syms from /usr/lib/x86_64-linux-gnu/libXinerama.so.1.0.0
--23779--    object doesn't have a symbol table
--23779-- Reading syms from /usr/lib/x86_64-linux-gnu/libX11-xcb.so.1.0.0
--23779--    object doesn't have a symbol table
--23779-- REDIR: 0x49902b0 (libc.so.6:__stpcpy_sse2_unaligned) redirected to 0x4845e70 (__stpcpy_sse2_unaligned)
--23779-- REDIR: 0x4a5b7b0 (libc.so.6:__strcspn_sse42) redirected to 0x4847780 (strcspn)
--23779-- REDIR: 0x4993c30 (libc.so.6:__memcpy_chk_sse2_unaligned) redirected to 0x4847420 (__memcpy_chk)
--23779-- REDIR: 0x4a5ba30 (libc.so.6:__strspn_sse42) redirected to 0x4847880 (strspn)
--23779-- Reading syms from /usr/lib/x86_64-linux-gnu/libGL.so.1.7.0
--23779--    object doesn't have a symbol table
--23779-- Reading syms from /usr/lib/x86_64-linux-gnu/libGLdispatch.so.0.0.0
--23779--    object doesn't have a symbol table
--23779-- Reading syms from /usr/lib/x86_64-linux-gnu/libGLX.so.0.0.0
--23779--    object doesn't have a symbol table
--23779-- Reading syms from /usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0.0.0
--23779--    object doesn't have a symbol table
--23779-- Reading syms from /usr/lib/x86_64-linux-gnu/libglapi.so.0.0.0
--23779--    object doesn't have a symbol table
--23779-- Reading syms from /usr/lib/x86_64-linux-gnu/libdrm.so.2.4.0
--23779--    object doesn't have a symbol table
--23779-- Reading syms from /usr/lib/x86_64-linux-gnu/libxcb-glx.so.0.0.0
--23779--    object doesn't have a symbol table
--23779-- Reading syms from /usr/lib/x86_64-linux-gnu/libxcb-dri2.so.0.0.0
--23779--    object doesn't have a symbol table
--23779-- Reading syms from /usr/lib/x86_64-linux-gnu/libXdamage.so.1.1.0
--23779--    object doesn't have a symbol table
--23779-- Reading syms from /usr/lib/x86_64-linux-gnu/libexpat.so.1.6.11
--23779--    object doesn't have a symbol table
--23779-- Reading syms from /usr/lib/x86_64-linux-gnu/libxcb-dri3.so.0.0.0
--23779--    object doesn't have a symbol table
--23779-- Reading syms from /usr/lib/x86_64-linux-gnu/libxcb-present.so.0.0.0
--23779--    object doesn't have a symbol table
--23779-- Reading syms from /usr/lib/x86_64-linux-gnu/libxcb-sync.so.1.0.0
--23779--    object doesn't have a symbol table
--23779-- Reading syms from /usr/lib/x86_64-linux-gnu/libxshmfence.so.1.0.0
--23779--    object doesn't have a symbol table
--23779-- REDIR: 0x4989ed0 (libc.so.6:__strnlen_sse2) redirected to 0x4842560 (strnlen)
--23779-- Reading syms from /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so
--23779--    object doesn't have a symbol table
--23779-- Reading syms from /usr/lib/x86_64-linux-gnu/libLLVM-10.so.1
--23779--    object doesn't have a symbol table
--23779-- Reading syms from /usr/lib/x86_64-linux-gnu/libz.so.1.2.11
--23779--    object doesn't have a symbol table
--23779-- Reading syms from /usr/lib/x86_64-linux-gnu/libzstd.so.1.4.4
--23779--    object doesn't have a symbol table
--23779-- Reading syms from /usr/lib/x86_64-linux-gnu/libsensors.so.5.0.0
--23779--    object doesn't have a symbol table
--23779-- Reading syms from /usr/lib/x86_64-linux-gnu/libdrm_radeon.so.1.0.1
--23779--    object doesn't have a symbol table
--23779-- Reading syms from /usr/lib/x86_64-linux-gnu/libelf-0.176.so
--23779--    object doesn't have a symbol table
--23779-- Reading syms from /usr/lib/x86_64-linux-gnu/libdrm_amdgpu.so.1.0.0
--23779--    object doesn't have a symbol table
--23779-- Reading syms from /usr/lib/x86_64-linux-gnu/libdrm_nouveau.so.2.0.0
--23779--    object doesn't have a symbol table
--23779-- Reading syms from /usr/lib/x86_64-linux-gnu/libvulkan.so.1.2.131
--23779--    object doesn't have a symbol table
--23779-- Reading syms from /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28
--23779--    object doesn't have a symbol table
--23779-- Reading syms from /usr/lib/x86_64-linux-gnu/libgcc_s.so.1
--23779--    object doesn't have a symbol table
--23779-- REDIR: 0x40209b0 (ld-linux-x86-64.so.2:strncmp) redirected to 0x4842ec0 (strncmp)
--23779-- REDIR: 0x4023140 (ld-linux-x86-64.so.2:stpcpy) redirected to 0x4845ff0 (stpcpy)
--23779-- Reading syms from /usr/lib/x86_64-linux-gnu/libffi.so.7.1.0
--23779--    object doesn't have a symbol table
--23779-- Reading syms from /usr/lib/x86_64-linux-gnu/libedit.so.2.0.63
--23779--    object doesn't have a symbol table
--23779-- Reading syms from /usr/lib/x86_64-linux-gnu/librt-2.31.so
--23779--   Considering /usr/lib/x86_64-linux-gnu/librt-2.31.so ..
--23779--   .. CRC mismatch (computed 6a819213 wanted 953fa4ef)
--23779--   Considering /lib/x86_64-linux-gnu/librt-2.31.so ..
--23779--   .. CRC mismatch (computed 6a819213 wanted 953fa4ef)
--23779--   Considering /usr/lib/debug/lib/x86_64-linux-gnu/librt-2.31.so ..
--23779--   .. CRC is valid
--23779-- Reading syms from /usr/lib/x86_64-linux-gnu/libtinfo.so.6.2
--23779--    object doesn't have a symbol table
--23779-- REDIR: 0x4994b50 (libc.so.6:wcsncmp) redirected to 0x48311ba (_vgnU_ifunc_wrapper)
--23779-- REDIR: 0xbc0ab20 (libstdc++.so.6:operator new(unsigned long)) redirected to 0x483cf67 (operator new(unsigned long))
--23779-- REDIR: 0xbc08d70 (libstdc++.so.6:operator delete(void*)) redirected to 0x483f5bb (operator delete(void*))
--23779-- REDIR: 0xbc0ab60 (libstdc++.so.6:operator new(unsigned long, std::nothrow_t const&)) redirected to 0x483d7a5 (operator new(unsigned long, std::nothrow_t const&))
--23779-- REDIR: 0x4984360 (libc.so.6:__rawmemchr_sse2) redirected to 0x4846e70 (rawmemchr)
--23779-- REDIR: 0x49749b0 (libc.so.6:posix_memalign) redirected to 0x48418b0 (posix_memalign)
--23779-- REDIR: 0xbc08d80 (libstdc++.so.6:operator delete(void*, unsigned long)) redirected to 0x483f82f (operator delete(void*, unsigned long))
--23779-- REDIR: 0xbc0ab80 (libstdc++.so.6:operator new[](unsigned long)) redirected to 0x483e191 (operator new[](unsigned long))
--23779-- REDIR: 0xbc08da0 (libstdc++.so.6:operator delete[](void*)) redirected to 0x48405ad (operator delete[](void*))
--23779-- REDIR: 0x4a57c30 (libc.so.6:__strcasecmp_sse42) redirected to 0x4842f30 (strcasecmp)
--23779-- memcheck GC: 1000 nodes, 119 survivors (11.9%)
--23779-- memcheck GC: 1000 nodes, 119 survivors (11.9%)
--23779-- memcheck GC: 1000 nodes, 119 survivors (11.9%)
--23779-- memcheck GC: 1000 nodes, 126 survivors (12.6%)
--23779-- memcheck GC: 1000 nodes, 129 survivors (12.9%)
--23779-- memcheck GC: 1000 nodes, 346 survivors (34.6%)
--23779-- memcheck GC: 1014 new table size (driftup)
--23779-- memcheck GC: 1014 nodes, 411 survivors (40.5%)
--23779-- memcheck GC: 1029 new table size (driftup)
--23779-- memcheck GC: 1029 nodes, 663 survivors (64.4%)
--23779-- memcheck GC: 1455 new table size (stepup)
==23779== Conditional jump or move depends on uninitialised value(s)
==23779==    at 0x803A343: ??? (in /usr/lib/x86_64-linux-gnu/libLLVM-10.so.1)
==23779==    by 0x7F7A5E7: llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (in /usr/lib/x86_64-linux-gnu/libLLVM-10.so.1)
==23779==    by 0x7DE4D75: llvm::FPPassManager::runOnFunction(llvm::Function&) (in /usr/lib/x86_64-linux-gnu/libLLVM-10.so.1)
==23779==    by 0x7DE4FF2: llvm::FPPassManager::runOnModule(llvm::Module&) (in /usr/lib/x86_64-linux-gnu/libLLVM-10.so.1)
==23779==    by 0x7DE549F: llvm::legacy::PassManagerImpl::run(llvm::Module&) (in /usr/lib/x86_64-linux-gnu/libLLVM-10.so.1)
==23779==    by 0x8F30B34: llvm::MCJIT::emitObject(llvm::Module*) (in /usr/lib/x86_64-linux-gnu/libLLVM-10.so.1)
==23779==    by 0x8F30F1D: llvm::MCJIT::generateCodeForModule(llvm::Module*) (in /usr/lib/x86_64-linux-gnu/libLLVM-10.so.1)
==23779==    by 0x8F316AD: llvm::MCJIT::finalizeObject() (in /usr/lib/x86_64-linux-gnu/libLLVM-10.so.1)
==23779==    by 0x8EF587F: LLVMGetPointerToGlobal (in /usr/lib/x86_64-linux-gnu/libLLVM-10.so.1)
==23779==    by 0x6409041: ??? (in /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so)
==23779==    by 0x63FD9EF: ??? (in /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so)
==23779==    by 0x63E9937: ??? (in /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so)
==23779==  Uninitialised value was created by a stack allocation
==23779==    at 0x8038D3A: ??? (in /usr/lib/x86_64-linux-gnu/libLLVM-10.so.1)
==23779== 
--23779-- memcheck GC: 1455 nodes, 392 survivors (26.9%)
--23779-- memcheck GC: 1476 new table size (driftup)
--23779-- memcheck GC: 1476 nodes, 1386 survivors (93.9%)
--23779-- memcheck GC: 2087 new table size (stepup)
--23779-- memcheck GC: 2087 nodes, 297 survivors (14.2%)
--23779-- memcheck GC: 2087 nodes, 298 survivors (14.3%)
--23779-- Discarding syms at 0x5dd5ff0-0x6b18ab2 in /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so (have_dinfo 1)
--23779-- Discarding syms at 0xba12240-0xbaa3d0a in /usr/lib/x86_64-linux-gnu/libzstd.so.1.4.4 (have_dinfo 1)
--23779-- Discarding syms at 0xbaba580-0xbac0f68 in /usr/lib/x86_64-linux-gnu/libsensors.so.5.0.0 (have_dinfo 1)
--23779-- Discarding syms at 0xbaca2a0-0xbad0b5d in /usr/lib/x86_64-linux-gnu/libdrm_radeon.so.1.0.1 (have_dinfo 1)
--23779-- Discarding syms at 0xbada580-0xbaeb105 in /usr/lib/x86_64-linux-gnu/libelf-0.176.so (have_dinfo 1)
--23779-- Discarding syms at 0xbaf6740-0xbafaf01 in /usr/lib/x86_64-linux-gnu/libdrm_amdgpu.so.1.0.0 (have_dinfo 1)
--23779-- Discarding syms at 0xbb013c0-0xbb051ae in /usr/lib/x86_64-linux-gnu/libdrm_nouveau.so.2.0.0 (have_dinfo 1)
--23779-- Discarding syms at 0xbb196c0-0xbb4af16 in /usr/lib/x86_64-linux-gnu/libvulkan.so.1.2.131 (have_dinfo 1)
--23779-- Discarding syms at 0x5417660-0x541c288 in /usr/lib/x86_64-linux-gnu/libXcursor.so.1.0.2 (have_dinfo 1)
--23779-- Discarding syms at 0x51ff360-0x52056b9 in /usr/lib/x86_64-linux-gnu/libXrandr.so.2.2.0 (have_dinfo 1)
--23779-- Discarding syms at 0x542a0f0-0x542aa31 in /usr/lib/x86_64-linux-gnu/libXinerama.so.1.0.0 (have_dinfo 1)
--23779-- Discarding syms at 0x520ba60-0x5211ab5 in /usr/lib/x86_64-linux-gnu/libXrender.so.1.3.0 (have_dinfo 1)
--23779-- Discarding syms at 0x51ed460-0x51f7d1b in /usr/lib/x86_64-linux-gnu/libXi.so.6.1.0 (have_dinfo 1)
--23779-- Discarding syms at 0x58761c0-0x587901d in /usr/lib/x86_64-linux-gnu/libGL.so.1.7.0 (have_dinfo 1)
--23779-- Discarding syms at 0x5976700-0x599048c in /usr/lib/x86_64-linux-gnu/libGLX.so.0.0.0 (have_dinfo 1)
--23779-- Discarding syms at 0x58fb240-0x58fd4eb in /usr/lib/x86_64-linux-gnu/libGLdispatch.so.0.0.0 (have_dinfo 1)
--23779-- Discarding syms at 0x59c1d60-0x5a04a42 in /usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0.0.0 (have_dinfo 1)
--23779-- Discarding syms at 0x542f040-0x542f11f in /usr/lib/x86_64-linux-gnu/libX11-xcb.so.1.0.0 (have_dinfo 1)
--23779-- Discarding syms at 0x5423300-0x54256ea in /usr/lib/x86_64-linux-gnu/libXfixes.so.3.1.0 (have_dinfo 1)
--23779-- Discarding syms at 0x51d0240-0x51d29f9 in /usr/lib/x86_64-linux-gnu/libXxf86vm.so.1.0.0 (have_dinfo 1)
--23779-- Discarding syms at 0x51da5e0-0x51e484e in /usr/lib/x86_64-linux-gnu/libXext.so.6.4.0 (have_dinfo 1)
--23779-- Discarding syms at 0x5a2f1a0-0x5a3c410 in /usr/lib/x86_64-linux-gnu/libglapi.so.0.0.0 (have_dinfo 1)
--23779-- Discarding syms at 0x5a61780-0x5a6b489 in /usr/lib/x86_64-linux-gnu/libdrm.so.2.4.0 (have_dinfo 1)
--23779-- Discarding syms at 0x5a7d0a0-0x5a85b29 in /usr/lib/x86_64-linux-gnu/libxcb-glx.so.0.0.0 (have_dinfo 1)
--23779-- Discarding syms at 0x5a910a0-0x5a92309 in /usr/lib/x86_64-linux-gnu/libxcb-dri2.so.0.0.0 (have_dinfo 1)
--23779-- Discarding syms at 0x5a971a0-0x5a97b1b in /usr/lib/x86_64-linux-gnu/libXdamage.so.1.1.0 (have_dinfo 1)
--23779-- Discarding syms at 0x5a9f230-0x5abab07 in /usr/lib/x86_64-linux-gnu/libexpat.so.1.6.11 (have_dinfo 1)
--23779-- Discarding syms at 0x5acb0e0-0x5acbfd7 in /usr/lib/x86_64-linux-gnu/libxcb-dri3.so.0.0.0 (have_dinfo 1)
--23779-- Discarding syms at 0x5ad00a0-0x5ad097a in /usr/lib/x86_64-linux-gnu/libxcb-present.so.0.0.0 (have_dinfo 1)
--23779-- Discarding syms at 0x5ad7100-0x5ad9416 in /usr/lib/x86_64-linux-gnu/libxcb-sync.so.1.0.0 (have_dinfo 1)
--23779-- Discarding syms at 0x5ade960-0x5adec2c in /usr/lib/x86_64-linux-gnu/libxshmfence.so.1.0.0 (have_dinfo 1)
==23779== 
==23779== HEAP SUMMARY:
==23779==     in use at exit: 298,622 bytes in 2,554 blocks
==23779==   total heap usage: 166,353 allocs, 163,799 frees, 76,537,183 bytes allocated
==23779== 
==23779== Searching for pointers to 2,554 not-freed blocks
==23779== Checked 12,997,488 bytes
==23779== 
==23779== 112 (56 direct, 56 indirect) bytes in 1 blocks are definitely lost in loss record 1,887 of 1,927
==23779==    at 0x4841428: calloc (vg_replace_malloc.c:1340)
==23779==    by 0x676607E: ???
==23779==    by 0x63E1C3B: ???
==23779==    by 0x63CC7A5: ???
==23779==    by 0x63CC86C: ???
==23779==    by 0x63CD479: ???
==23779==    by 0x6390A33: ???
==23779==    by 0x639335C: ???
==23779==    by 0x638E2BC: ???
==23779==    by 0x6351357: ???
==23779==    by 0x637533D: ???
==23779==    by 0x6372C76: ???
==23779== 
==23779== 5,294 bytes in 255 blocks are definitely lost in loss record 1,922 of 1,927
==23779==    at 0x483C853: malloc (vg_replace_malloc.c:393)
==23779==    by 0x497750E: strdup (strdup.c:42)
==23779==    by 0x5A3C0D6: ???
==23779==    by 0x5A3BE84: ???
==23779==    by 0x59DDE16: ???
==23779==    by 0x58FB436: ???
==23779==    by 0x58FBE1C: ???
==23779==    by 0x5977419: ???
==23779==    by 0x5978C57: ???
==23779==    by 0x4880A06: ??? (in /usr/lib/x86_64-linux-gnu/libglfw.so.3.3)
==23779==    by 0x486FDEB: ??? (in /usr/lib/x86_64-linux-gnu/libglfw.so.3.3)
==23779==    by 0x48756AA: glfwCreateWindow (in /usr/lib/x86_64-linux-gnu/libglfw.so.3.3)
==23779== 
==23779== LEAK SUMMARY:
==23779==    definitely lost: 5,350 bytes in 256 blocks
==23779==    indirectly lost: 56 bytes in 1 blocks
==23779==      possibly lost: 0 bytes in 0 blocks
==23779==    still reachable: 293,172 bytes in 2,295 blocks
==23779==         suppressed: 44 bytes in 2 blocks
==23779== Reachable blocks (those to which a pointer was found) are not shown.
==23779== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==23779== 
==23779== ERROR SUMMARY: 185 errors from 3 contexts (suppressed: 0 from 0)
==23779== 
==23779== 183 errors in context 1 of 3:
==23779== Conditional jump or move depends on uninitialised value(s)
==23779==    at 0x803A343: ??? (in /usr/lib/x86_64-linux-gnu/libLLVM-10.so.1)
==23779==    by 0x7F7A5E7: llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (in /usr/lib/x86_64-linux-gnu/libLLVM-10.so.1)
==23779==    by 0x7DE4D75: llvm::FPPassManager::runOnFunction(llvm::Function&) (in /usr/lib/x86_64-linux-gnu/libLLVM-10.so.1)
==23779==    by 0x7DE4FF2: llvm::FPPassManager::runOnModule(llvm::Module&) (in /usr/lib/x86_64-linux-gnu/libLLVM-10.so.1)
==23779==    by 0x7DE549F: llvm::legacy::PassManagerImpl::run(llvm::Module&) (in /usr/lib/x86_64-linux-gnu/libLLVM-10.so.1)
==23779==    by 0x8F30B34: llvm::MCJIT::emitObject(llvm::Module*) (in /usr/lib/x86_64-linux-gnu/libLLVM-10.so.1)
==23779==    by 0x8F30F1D: llvm::MCJIT::generateCodeForModule(llvm::Module*) (in /usr/lib/x86_64-linux-gnu/libLLVM-10.so.1)
==23779==    by 0x8F316AD: llvm::MCJIT::finalizeObject() (in /usr/lib/x86_64-linux-gnu/libLLVM-10.so.1)
==23779==    by 0x8EF587F: LLVMGetPointerToGlobal (in /usr/lib/x86_64-linux-gnu/libLLVM-10.so.1)
==23779==    by 0x6409041: ???
==23779==    by 0x63FD9EF: ???
==23779==    by 0x63E9937: ???
==23779==  Uninitialised value was created by a stack allocation
==23779==    at 0x8038D3A: ??? (in /usr/lib/x86_64-linux-gnu/libLLVM-10.so.1)
==23779== 
--23779-- 
--23779-- used_suppression:      2 dtv-addr-init /usr/local/libexec/valgrind/default.supp:1476 suppressed: 44 bytes in 2 blocks
==23779== 
==23779== ERROR SUMMARY: 185 errors from 3 contexts (suppressed: 0 from 0)

CMakeLists.txt missing c file leading to linker command failure

it appears that there's some c file(s) missing from the CMakeLists.txt file, leading to compilation errors when trying to use "mlx_put_string".

Undefined symbols for architecture x86_64:
"_mlx_get_font", referenced from:
_raycasting in raycasting.o
ld: symbol(s) not found for architecture x86_64

After adding the line

${SOURCE_DIR}/font/mlx_font.c

to the CMakeLists.txt file, the issues was fixed for us.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.