Author Topic: new project wizard fails to locate glfw3.h  (Read 1340 times)

Offline Vigor

  • Multiple posting newcomer
  • *
  • Posts: 10
new project wizard fails to locate glfw3.h
« on: April 17, 2024, 01:54:44 am »
This was not a problem before I installed the 13493 nightly build.

I now have 2 installations of codeblocks on my computer, one residing at the default location, the other residing where I unzipped the nightly.   

But that is fine, the nightly installation works great for my old projects and they get their .h .dll .a .lib files from the path to them from the old installation of codeblocks.

The default path of the new nightly build installation's wizard uses the old installation of codeblocks files.   That seems strange but the files are there so, I'm not bothered.   The problem is it keeps failing to find glfw3.h which, in the past resided in a GL\ directory inside the MINGW\include\ directory.   I also tried copying the
opengl files to the respective directories in the new installation and using the MINGW64 directory of the nightly installation but that didn't work either.

I found an old post where this was an issue 6 years ago and tried to follow the instructions to fix it but it doesn't appear to be exactly the same issue.  I think that old problem is fixed in this version but my problem is just similar.  I went to edit the script for the new project but the line numbers are different.  I think i found the appropriate lines of code but they already look right.   I don't know what to change or how to change it.   Perhaps this function shows the right place?

function GetFilesDir()
    return _T("glfw/files");

Might that mean that I need to make a folder \MINGW64\INCLUDE\GLFW\FILES\ and ..\LIB\GLFW\FILES\ etc or would all of the gl files, .a .lib .dll go in one MINGW64\GLFW\FILES\ folder?    Is there even supposed to be a FILES\ folder or does the "files" in "glfw/files" act as a wildcard for files in a GLFW\ folder?

I also tried making an empty console application and converting it to a glfw3 application but that didn't work either, it said glfw3.h was missing at compile time.

In my previous/first installation of codeblocks, making a glfw project used glfw.h and I had to alter
each new project to make it a glfw3.h project.

I also tried moving all opengl .h .dll .a .lib files to the MINGW\ and MINGW64\ directories but that didn't work either.

I think i might be inclined to put all of the glfw3 files in one place to avoid needing a bunch of different paths but...   I suspect the solution to my problem is simple but arbitrary and i am unlikely to figure it out on my own.

Thank you for codeblocks and thank you for your time

Offline Vigor

  • Multiple posting newcomer
  • *
  • Posts: 10
Re: new project wizard fails to locate glfw3.h
« Reply #1 on: April 20, 2024, 01:36:53 am »
Through trial and error, going down many rabbit holes, trying to understand the glfw3 project script I found a solution to the above problem.

I took the glfw3 folder with a copy of the glfw3.h file from my initial download and moved it until I found the right spot for it.   It goes in MinGW/Include/, so MINGW/Include/GLFW3/glfw3.h

Before trying this I tried to change the path in the script to where glfw3.h is and has been working for years but it didn't work.  In fact it still works for all of my old projects so there must be a better solution.

After completing the wizard I got a new project that doesn't complile.   It gives a lot of (i think) linking errors of undefined references such as

C:\Program Files\CodeBlocks\MinGW\lib/libglfw3.a(init.c.obj):init.c:(.text+0xb9): undefined reference to `__mingw_free'

In the above error line, one thing seems peculiar.   "MinGW\lib/libglfw3.a"  sometimes it is using forward slash and other times it is using backslash.    I have seen paths written with forward slashes or with back slashes but I think this is the first time I have ever seen a path written with a combination of forward and back slashes.

libglfw3.a is in the MinGW/LIB/ folder. (i didn't need to move it from where it has been for years)

I read a post on stack exchange which had an almost identical problem where it was determined that the original poster needed to update his GCC compiler.   I recently updated mine but I went ahead and updated it again and nothing changed.

Since I have two full installations of codeblocks on my computer, I wanted to try to start projects in both, then edit both scripts and compare them side by side looking for differences.   It wouldn't let me open both a once.  I can open one, then trying to execute the 2nd brings the window to the other to the front.

Is there a way to have 2 instances of codeblocks running at once?  It would often be useful if I could have multiple instances of codeblocks running at once.   It would be really great if each instance had a unique thumbnail and didn't stack in the taskbar.

Offline Vigor

  • Multiple posting newcomer
  • *
  • Posts: 10
Re: new project wizard fails to locate glfw3.h
« Reply #2 on: April 21, 2024, 11:45:32 pm »
So, I loaded up the default 20.03 version of codeblocks, intending to copy its wizard and paste it into notepad but the wizard it showed was the same as the nightly build wizard
except there were a few more options when I right clicked to edit it.   

Among the options were...
-a warning that the script had been edited and was stored globally in my local user directory (or something like that i can't see it any more)
-an option to delete the modified script

I deleted it and then was able to start a new glfw project which worked/built/linked properly.  I can then modify that project to work with glfw3.

So, I suppose my problem is solved.  I have found a workaround that allows me to make new projects that link and build correctly.

But, the strange thing is, when I then load up the nightly version of codeblocks it won't allow me to create new projects that build/link even with the old script.   It will make a new project and it will be a glfw project, that project just won't build/link.   However,

I meddled with project build options and by changing the working directory or adding working directories I could make some of the error messages go away.   But as soon as one error went away a new error showed up.  I was not able to find a directory or combination of directories which made everything work.

Also, I'm not sure why but I tried to change the compiler.  It appears i have 3 compilers so I tried them all.   GCC Default and GCC MinGW compiler produced the same errors i think.   GCC MinGW64 compiler produced only one "error" - cannot find -lglfw3: No such file or directory.   I don't even know what lglfw3 is.  It doesn't even show an extension and AFAIK there shouldn't be an lglfw3 anything.

Final thoughts...
-i think i liked the 20.03 problems more than the nightly problems
-when I had the original problem of not being able to find glfw3.h, i felt like I needed to lie to the wizard when it asked what the path to glfw3.h is.   Specifically the path to the glfw3.h was c:/program files/codeblocks/mingw/include/glfw3/glfw3.h but in order to give the wizard what it wanted rather than what it asked for I had to put the path as c:/program files/codeblocks/mingw/ and guess at where the file actually needed to be.  Changing the path I supplied to the wizard to the actual path would make everything else fail to work.
-I think spreading files around to a bunch of different directories is asking for trouble.  If for whatever reason it seems important to quarantine glfw3 files, why not quarantine them all in the same place.   But is there a reason to quarantine them?   Why not put all .h's in an include folder, all .a's in a lib folder etc.    Or why have a bin folder with the executable rather than putting the executable right next to the project file so there would be no need for a working directory?  The more directories there are the more potential there is for problems imho opinion.   I don't contend to be on the same level of programming ability as the devs of codeblocks but I try to keep things simple.   I can only wrap my head around so much complexity.
« Last Edit: April 22, 2024, 12:13:08 am by Vigor »