Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Either 0.7.0 is bad, or I'm doing something wrong
#1
I downloaded 0.7.0 this evening. I deleted all files from my 0.6.0 location and extracted 0.7.0 to this location.

Problem 1: If I go to Help / About it still reports that it is 0.6.0.

Problem 2: My program that compiled fine under 0.6.0 fails to compile on 0.7.0. Something odd about this as well. My program file is named "WordClock 1.0.1.9.bas" but when it compiles it, an EXE called "WordClock.EXE" is created.

If I rename the program to "WordClock.bas" it still compiles to "WordClock.exe", but I still get an error and the EXE file size is significantly larger than it was with 0.6.0 (5.53MB vs 3.54MB).

Error reported is: C++ Compilation failed (Check .\internal\temp\compilelog.txt)

The contents of that log:

internal\c\c_compiler\bin\c++.exe -w -DGLEW_STATIC -DFREEGLUT_STATIC -DDEPENDENCY_NO_SOCKETS -DDEPENDENCY_NO_PRINTER -DDEPENDENCY_ICON -DDEPENDENCY_NO_SCREENIMAGE -DDEPENDENCY_LOADFONT internal\c/qbx.cpp -c -o internal\c/qbx.o
internal\c\c_compiler\bin\windres.exe -i internal\temp\icon.rc -o internal\temp\icon.o
internal\c\c_compiler\bin\objcopy.exe -Ibinary -Oelf64-x86-64 -Bi386:x86-64 internal\temp/data.bin internal\temp/data.o
internal\c\c_compiler\bin\c++.exe -w -DGLEW_STATIC -DFREEGLUT_STATIC -DDEPENDENCY_NO_SOCKETS -DDEPENDENCY_NO_PRINTER -DDEPENDENCY_ICON -DDEPENDENCY_NO_SCREENIMAGE -DDEPENDENCY_LOADFONT internal\c/libqb/libqb_make_0000010100000.o  internal\c/qbx.o internal\temp\icon.o internal\temp/data.o -o C:\Users\hanness\Desktop\WordClock  internal\c/parts/video/font/ttf/src.a internal\c/parts/core/src.a  -static-libgcc -static-libstdc++ -mwindows -lopengl32 -lglu32 -lwinmm -lgdi32
internal\c\c_compiler\bin\objcopy.exe --only-keep-debug C:\Users\hanness\Desktop\WordClock internal\temp/C:\Users\hanness\Desktop\WordClock.sym
internal\c\c_compiler\bin\objcopy.exe: 'C:\Users\hanness\Desktop\WordClock': No such file
mingw32-make: *** [Makefile:346: C:\Users\hanness\Desktop\WordClock] Error 1


My questions:

1) Other than extracting the files, is there something else I should be doing?

2) I am running on what may possibly be the final build of Windows 11 22H2. This is as yet to be determined, but I thought that it was important that I mention this. Is it possible that this could be contributing to the problem?

One last piece of info: As a test, I disabled real time virus scanning to be sure that is not a contributing factor.
Reply
#2
Follow-up to my original post:

I reverted to 0.6.0 and that solves all problems. The EXE is now created with the correct name, the EXE is smaller than with 0.7.0, and the QB64pe correctly identifies its version number.

I realize that there was one other piece of information I neglected to post originally:

The file that I downloaded was the qb64_win-x64.7z for use with 64-bit Windows. That should be obvious since Win 11 has no 32-bit version, but wanted to be 100% clear that this is indeed what I pulled down.
Reply
#3
Problem 1 is a simple glitch that I mentioned in the other post -- I forgot to update the HELP ABOUT values. You're working with 0.7.0 instead of 0.6.0.

How do I know?

Because you're reporting a glitch that just popped up with 0.7.0 -- the makefile build process doesn't like the spaces in your filename that you're trying to create. Change the filename to "WordClock_1.0.1.9.bas" and it should run for you, I'd think.

Don't worry -- we're working on a fix for the glitch even now, and it should be ready soon for a quick v0.7.1 version to address the issue. Wink
Reply
#4
(05-23-2022, 04:35 AM)SMcNeill Wrote: Problem 1 is a simple glitch that I mentioned in the other post -- I forgot to update the HELP ABOUT values.  You're working with 0.7.0 instead of 0.6.0.

How do I know?

Because you're reporting a glitch that just popped up with 0.7.0 -- the makefile build process doesn't like the spaces in your filename that you're trying to create.  Change the filename to "WordClock_1.0.1.9.bas" and it should run for you, I'd think. 

Don't worry -- we're working on a fix for the glitch even now, and it should be ready soon for a quick v0.7.1 version to address the issue.  Wink

Nope - as I noted in the original post, I already renamed the file to just WordClock.bas, and while it did compile, it reported compile errors and the file size of the resulting EXE was greatly increased. In fact, the log output I attached was the result with the file already renamed to WordClock.bas.
Reply
#5
I suspect all the dots in the file name. I just tried to save a file "hello 1.0.1.0", although it compiled and created an exe properly (v2.0) it did not create a .bas source, probably because it saw the . in name and didn't think it needed a bas extension?
b = b + ...
Reply
#6
(05-23-2022, 01:12 PM)bplus Wrote: I suspect all the dots in the file name. I just tried to save a file "hello 1.0.1.0", although it compiled and created an exe properly (v2.0) it did not create a .bas source, probably because it saw the . in name and didn't think it needed a bas extension?

I don't know if you saw my follow-up message just before your post. The compiler is throwing the errors even with a simple name like "WordClock.bas". So, let me summarize:

If I have a name such "WordClock 1.0.1.9.bas" compiling the program will result is a file named "WordClock.exe". In addition, the resulting EXE file size is significantly larger than it was with 0.6.0 (5.53MB vs 3.54MB). Finally, the compiler displays the error message "C++ Compilation failed (Check .\internal\temp\compilelog.txt)".

If I rename the .bas to something simple such as "WordClock.bas" all of the above still applies. The only difference is that the resulting .exe file has the same base name as the .bas file (WordClock.exe). However, the other symptoms still apply.
Reply
#7
As I mentioned, v0.7.0 had a few issues with the makefile. If you have a change, try out v0.7.1 which addresses the issues we know of, and see if the problem is still there. https://qb64phoenix.com/forum/showthread...46#pid2546

If you're still having issues after this patch, feel free to post the code in question and we'll dig into whatever the problem might be. Wink
Reply
#8
i had the similar compilation error with version 0.7.0.
Now version 0.7.1 seems to work fine.

Many thanks for the fast correction!
Reply
#9
Much better!

1) Program compiles just fine now.
2) The problem of increased size on the final compiled .EXE is resolved.
3) The fix for the original problem that I reported (not being able to get physical screen dimensions while the QB display is hidden) is working perfectly. This has allowed me to create a much cleaner and more visually appealing transition from a Windowed mode to full screen in my program.
4) I also really like the visual changes to the help system within QB64pe.

Bravo! Great job.

Thank you all again for your help.
Reply




Users browsing this thread: 1 Guest(s)