Activity for Andre Maute
-
Andre Maute posted a comment on ticket #345
Hi Martin, thanks for posting your insights, I wonder if it would be possible to let the two projects converge a little bit more, so my fix functionality isn't needed anymore. Perhaps Axel reads this. https://github.com/a3emdot/zintzxingcppdemo/blob/e025de87460cd88769a2ef289a5401b5f37c66ba/src/barcode.cpp#L336 int zintFixZintSymbology(const std::string& input, int zintsymbology); and https://github.com/a3emdot/zintzxingcppdemo/blob/e025de87460cd88769a2ef289a5401b5f37c66ba/src/barcode.cpp#L509 std::string...
-
UPC-A and GS1 Databar inconsistencies with Upstream zxing-cpp and zint versions
-
This ticket can be closed now. Thank you very much for the quick fix. Kind regards Andre On 5/27/24 04:31, Git Lost wrote: As you probably guessed given our previous experience with the MSVC optimizer, it seems something about the inner top/right/bottom/left loops in az_populate_map() was causing it not to emit code for them (or at least emit code that didn't set the AztecMap array correctly - didn't do any real debugging - placing a printf() in any one of the loops made it work correctly for all!)....
-
This ticket can be closed now. Thank you very much for the quick fix. Kind regards Andre On 5/27/24 04:17, Git Lost wrote: Ah I see, the test wasn't cleaning up directories properly after itself, it should do this now with commit [3960df], thanks Andre [tickets:#316] non asciii characters used for directory and filenames in test Status: open Milestone: 1.0 Created: Thu May 23, 2024 03:08 PM UTC by Andre Maute Last Updated: Fri May 24, 2024 08:46 AM UTC Owner: nobody Hi all, I wonder if these non...
-
Currently I only have this screenshot here. Would it be possible to slightly change your tests? So they fail if they can't create the files and directories AND also fail if they can't delete the files and directories with these non-ASCII characters? So these files and directories have already been cleaned up, when the build directory is getting zipped.
-
the used batch file for building and testing Best Regards Andre
-
broken tests with 32bit windows build and recently updated buildtools 2022 installation
-
non asciii characters used for directory and filenames in test
-
Hi gitlost, I wonder what the current implementation status for this ticket is? Do you have any updates for this ticket? Regards Andre
-
For completeness I would like to add quote: "The signedness of char depends on the compiler and the target platform: the defaults for ARM and PowerPC are typically unsigned, the defaults for x86 and x64 are typically signed. " (see https://en.cppreference.com/w/cpp/language/types) And I believe I had a similar discussion in the past with gitlost, but I couldn't find it.
-
Hi Antoine, I hope your GL_RENDERER hint is helpful ;-) my glxinfo doesn't provide any "GL_RENDERER" string but an "OpenGL renderer string" string (hint, as we see in a moment this is the one requested) perhaps there was a typo and it should have been "glinfo" but I couldn't find any reference to the glinfo tool within the Fedora biosphere https://rpmfind.net/linux/RPM/fedora/devel/rawhide/x86_64/g/glx-utils-9.0.0-4.fc40.x86_64.html mesa-23.3.2.tar.xz from mesa3d.org doesn't contain any reference...
-
Nevertheless thank you. I just verified it, that it is still broken and was not 'accidentally' fixed due to a library update. I needed a lot of clicking this time, approximately 50? clicks. But at the moment I can't debug this any further. Regards Andre
-
no it is still still somehow reproducible, QT6 doesn't help!
-
no it is still still somehow reproducible, QT6 doesn't help!
-
Looks like building with QT6 somehow fixes this issue?? see https://sourceforge.net/p/auber/bugs/894/
-
This worked, thank you very much And somehow I can't reproduce the Crash which I reported here https://sourceforge.net/p/auber/bugs/893/ any more.
-
Can't compile Tulip with QT6 enabled
-
still crashes when self-compiled, using essentially tar xvfz tulip-5.7.3.tar.gz cd tulip-5.7.3 mkdir build cd build cmake .. cmake --build . make install
-
When compiling from source I see the following [ 64%] Building CXX object plugins/import/BibTeX/CMakeFiles/BibTeXImport-5.7.3.dir/ImportBibTeX.cpp.o In function ‘char* seq(char*)’, inlined from ‘std::string& forceUtf8String(std::string&)’ at /home/user/Downloads/tulip-5.7.3/plugins/import/BibTeX/ImportBibTeX.cpp:1001:16: /home/user/Downloads/tulip-5.7.3/plugins/import/BibTeX/ImportBibTeX.cpp:88:18: warning: storing the address of local variable ‘c4’ in ‘utf8seq’ [-Wdangling-pointer=] 88 | return...
-
crash when double-clicking a graph node
-
Hi gitlost, FYI. My latest version https://github.com/a3emdot/zintzxingcppdemo/commit/5ec4f7540491e6c00e399c225d1da15ca65f3dd0 with zxing-cpp 2.2.1 and zint '2e350232' shows, that all the currently reported crashes from #1 to #16 can't be reproduced anymore. Best regards Andre
-
Here is #16 https://github.com/a3emdot/zintzxingcppdemo/commit/fe16d8e550742466e71e54a9ba58d2c669c9c243 Regards Andre [user@fedora zintzxingcppdemo]$ cd build/local/src/ [user@fedora src]$ ./zint-crash-20231208-1 zint-crash-20231208-1: /home/user/zintzxingcppdemo/build/local/deps/third-party/zint/backend/qr.c:1764: int qrcode(struct zint_symbol *, struct zint_seg *, const int): Assertion `0' failed. Aborted (core dumped)
-
you're welcome ;-) I only reevaluated some still existing corpus files.
-
Here is #15 https://github.com/a3emdot/zintzxingcppdemo/commit/1b06dbf87348912910939fc8303ad51598344277 I wonder if this is a regression - 'a14fe77a' isn't affected - 'ff992a42' is affected Regards Andre [user@fedora zintzxingcppdemo]$ cd build/local/src/ [user@fedora src]$ ./zint-crash-20231205-1 zint-crash-20231205-1: /home/user/zintzxingcppdemo/build/local/deps/third-party/zint/backend/qr.c:1764: int qrcode(struct zint_symbol *, struct zint_seg *, const int): Assertion `0' failed. Aborted (core...
-
Hi Martin, perhaps take this one here as a starting point https://github.com/google/oss-fuzz/blob/master/projects/cairo/targets/raster_fuzzer.c As a substitute for 'main', you'll have to provide an implementation for int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size); Use the 'data' and 'size' variables for setting up a zint symbol and some payload and call ZBarcode_Encode. The rest to be done is an integration problem as I was told by a co-worker. Use clang as a compiler with sanitize...
-
Hi Martin, perhaps take this one here as a starting point https://github.com/google/oss-fuzz/blob/master/projects/cairo/targets/raster_fuzzer.c As a substitute for 'main', you'll have to provide an implementation for int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size); Use the 'data' and 'size' variables for setting up a zint symbol and some payload and call ZBarcode_Encode. The rest to be done is an integration problem as I was told by a co-worker. Use clang as a compiler with sanitize...
-
I have let the fuzzer run for the whole weekend. Nothing turned up, so i think you may close this ticket as 'fixed' Best regards Andre
-
Re HRT above, If there is no precedent based on an official document, I'm in favor not supporting it. Re HRT for barcodes in general, If there is precedent based on an official document, I'm in favor supporting that. Regarding the text below databar expanded stacked barcodes as in my Ticket #249 they come from the official gs1.org site.
-
Re HRT and font, The font could be o.k. I'll have to ask. Re HRT and multiline, looks good to me Re 3rdparty. I'll have to pass here. The hassle for getting an extra library in is to much at the moment. Re pango/cairo/harfbuz. Yes, it depends on the project. Re your last barcode rendering what happened to the top of that one I checked with a windows qtZint.exe under wine and it looks different
-
Re HRT and font, The font could be o.k. I'll have to ask. Re HRT and multiline, looks good to me Re 3rdparty. I'll have to pass here. The hassle for getting an extra library in is to much at moment. Re pango/cairo/harfbuz. Yes, it depends on the project. Re your last barcode rendering what happened to the top of that one I checked with a windows qtZint.exe under wine and it looks different
-
Re HRT The font looks good for me on first sight. Though it looks a little bit smaller as in the 'databar_expanded_stacked.png' example I posted from the gs1.org website (see. Ticket #249 ) Re HRT multiline Do you think the HRT will split similarly as in the 'databar_expanded_stacked.png' example? Re third party libraries It depends on the projects. But with these "black-white" printers the experience we made is, that antialiasing makes the output often worse (e.g after pango 1.44??) Some parts of...
-
Would it be possible to optionalize FreeType similarly as LibPNG?
-
Re #249 Using FreeType would also be an issue. The fallback with the built-in old bitmap fonts would be the thing I need here. I can't cope with antialiased pixel data. Perhaps a bitmap font with larger glyphs might be needed? Do you have some example gs1databar expanded stacked renderings with HRT using your fallback mode?
-
Re HRT above and EAN/UPC i'll have to ask my co-workers first. But for a first iteration i believe i would ignore EAN/UPC. Re ticket #249. - Would that be implemented without libpng (this often led to different library problems for us) - and use the old bitmap fonts without antialiasing? For black-white printers dithering to black-white usually deteriorates the image quality. We only have black-white printers. which only can put black dots on paper. Kind regards Andre
-
What about OSSFuzz? (Haven't tried it myself) https://security.googleblog.com/2022/09/fuzzing-beyond-memory-corruption.html Would that be an option for the zint project? Andre
-
And thank you for fixing these crashes. I stopped further fuzzing yesterday after nothing new was found for 12 hours. But let us do an addtional run for two days more and see if it stays calm ;-) Regarding your font stuff, do you have something in the pipeline for Ticket #249? Placing the human readable text above the symbol would also be a nice feature to have ;-) Kind regards Andre
-
And thank you for fixing these crashes. I stopped further fuzzing yesterday after nothing new was found for 12 hours. But let us do an addtional run for two days more and see if it stays calm ;-) Regarding your font stuff, do you have something in the pipeline for Ticket #249? Placing the human readable text above the symbol would also be a nice feature to have ;-) Andre
-
Looks like it is calming down at the moment. this is the last one I currently have left Thank you very much and kind regards Andre P.S.: I wonder if you're already planning the release of version 2.13? Here is #14 https://github.com/a3emdot/zintzxingcppdemo/commit/f26e0bfa09ebd3d49ed46cae017fa90d29fc9fe8 [user@fedora zintzxingcppdemo]$ cd build/local/src/ [user@fedora src]$ ./zint-crash-20231128-1 ================================================================= ==28559==ERROR: AddressSanitizer:...
-
Here they come #11 up to #13 I have realised I should use 'Debug' mode for my sanitizer build script, so one gets line numbers within the stack trace. Sorry, for missing that ;-) After these I'm going to update my tooling Regards Andre Here is #11 https://github.com/a3emdot/zintzxingcppdemo/commit/f4c42f26164c16b93a4918f45fc34a9ab8ba8fea [user@fedora zintzxingcppdemo]$ cd build/local/src/ [user@fedora src]$ ./zint-crash-20231127-1 =================================================================...
-
Here is #13 https://github.com/a3emdot/zintzxingcppdemo/commit/0172675b6fd1374d2ee2f4473e980173ffb49297 [user@fedora zintzxingcppdemo]$ cd build/local/src/ [user@fedora src]$ ./zint-crash-20231127-3 /home/user/zintzxingcppdemo/build/local/deps/third-party/zint/backend/composite.c:820:12: runtime error: inf is outside the range of representable values of type 'int' SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /home/user/zintzxingcppdemo/build/local/deps/third-party/zint/backend/composite.c:820:12...
-
Here is #12 https://github.com/a3emdot/zintzxingcppdemo/commit/31bb12dc8a9bf2cf77aafb3368855557cf5d5a61 [user@fedora zintzxingcppdemo]$ cd build/local/src/ [user@fedora src]$ ./zint-crash-20231127-2 ================================================================= ==7149==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fc1d8b04610 at pc 0x7fc1db0b96c6 bp 0x7fff76e487b0 sp 0x7fff76e487a8 WRITE of size 4 at 0x7fc1d8b04610 thread T0 #0 0x7fc1db0b96c5 in c1_encode /home/user/zintzxingcppdemo/build/local/deps/third-party/zint/backend/code1.c:849:30...
-
Here they come #11 up to #13 I have realised I should use 'Debug' mode for my sanitzer build script, so one line numbers within the stack trace. Sorry, for missing that ;-) After these I'm going to update my tooling Regards Andre Here is #11 https://github.com/a3emdot/zintzxingcppdemo/commit/f4c42f26164c16b93a4918f45fc34a9ab8ba8fea [user@fedora zintzxingcppdemo]$ cd build/local/src/ [user@fedora src]$ ./zint-crash-20231127-1 ================================================================= ==7127==ERROR:...
-
Whoa. your last patch was huge, #1 up to #10 don't crash anymore, gorgeous 👏
-
Here is #6 https://github.com/a3emdot/zintzxingcppdemo/commit/30b902a2badda67496f09639e3f4a1ee1170359e [user@fedora zintzxingcppdemo]$ cd build/local/src/ [user@fedora src]$ ./zint-crash-20231126-2 ================================================================= ==22320==ERROR: AddressSanitizer: dynamic-stack-buffer-overflow on address 0x7ffde4bcc323 at pc 0x7f9dfcaae9ba bp 0x7ffde4bcc2f0 sp 0x7ffde4bcc2e8 READ of size 1 at 0x7ffde4bcc323 thread T0 #0 0x7f9dfcaae9b9 in cc_binary_string composite.c...
-
Here is #7 https://github.com/a3emdot/zintzxingcppdemo/commit/e99b8c150d9850dd145c31722b38bc981a13dbcd [user@fedora zintzxingcppdemo]$ cd build/local/src/ [user@fedora src]$ ./zint-crash-20231126-3 /home/user/zintzxingcppdemo/build/local/deps/third-party/zint/backend/pdf417.c:450:13: runtime error: index 2710 out of bounds for type 'int[2710]' SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /home/user/zintzxingcppdemo/build/local/deps/third-party/zint/backend/pdf417.c:450:13 in =================================================================...
-
Here is #8 https://github.com/a3emdot/zintzxingcppdemo/commit/405405dbe39f53ed910a419bf3edcf180d1a4110 [user@fedora zintzxingcppdemo]$ cd build/local/src/ [user@fedora src]$ ./zint-crash-20231126-4 ================================================================= ==22356==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffa8f704610 at pc 0x7ffa918f70dc bp 0x7ffd951c93d0 sp 0x7ffd951c93c8 WRITE of size 4 at 0x7ffa8f704610 thread T0 #0 0x7ffa918f70db in c1_encode code1.c #1 0x7ffa918e84a8...
-
Here is #9 https://github.com/a3emdot/zintzxingcppdemo/commit/405405dbe39f53ed910a419bf3edcf180d1a4110 [user@fedora zintzxingcppdemo]$ cd build/local/src/ [user@fedora src]$ ./zint-crash-20231126-5 /home/user/zintzxingcppdemo/build/local/deps/third-party/zint/backend/codablock.c:628:26: runtime error: signed integer overflow: -2147483648 - 5 cannot be represented in type 'int' SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /home/user/zintzxingcppdemo/build/local/deps/third-party/zint/backend/codablock.c:628:26...
-
Here is #10 https://github.com/a3emdot/zintzxingcppdemo/commit/447dd745bd4c4ccf2c7e6b08c7d9d4dc2bb22ea1 [user@fedora zintzxingcppdemo]$ cd build/local/src/ [user@fedora src]$ ./zint-crash-20231126-6 ================================================================= ==22388==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7f759e203318 at pc 0x7f75a024b744 bp 0x7ffcaa7db950 sp 0x7ffcaa7db948 WRITE of size 4 at 0x7f759e203318 thread T0 #0 0x7f75a024b743 in pdf_byteprocess (/home/user/zintzxingcppdemo/build/local/deps/build/prefix/lib/libzint.so.2.12+0x24b743)...
-
Here is #4 https://github.com/a3emdot/zintzxingcppdemo/commit/3172428ef9972b8c8d3fd79e3b6a86d7b6451193 FYI. #3 'zint-crash-20231124-1' should be fixed. Best Regards Andre user@fedora ~]$ git clone https://github.com/a3emdot/zintzxingcppdemo.git Cloning into 'zintzxingcppdemo'... remote: Enumerating objects: 244, done. remote: Counting objects: 100% (244/244), done. remote: Compressing objects: 100% (148/148), done. remote: Total 244 (delta 151), reused 186 (delta 93), pack-reused 0 Receiving objects:...
-
Here is #3 https://github.com/a3emdot/zintzxingcppdemo/commit/f8ca7f4b21586ec5714a174f7010195a2ed9e885 [user@fedora ~]$ git clone https://github.com/a3emdot/zintzxingcppdemo.git Cloning into 'zintzxingcppdemo'... remote: Enumerating objects: 240, done. remote: Counting objects: 100% (240/240), done. remote: Compressing objects: 100% (144/144), done. remote: Total 240 (delta 149), reused 184 (delta 93), pack-reused 0 Receiving objects: 100% (240/240), 2.10 MiB | 2.51 MiB/s, done. Resolving deltas:...
-
Here is #2 https://github.com/a3emdot/zintzxingcppdemo/commit/b4de2b1d83dac45ed093af62f24c1bfa394c6ef7 [user@fedora zintzxingcppdemo]$ cd build/local/src [user@fedora src]$ ./zint-crash-20231122-1 /home/user/zintzxingcppdemo/build/local/deps/third-party/zint/backend/aztec.c:1131:13: runtime error: index 19968 out of bounds for type 'char[19968]' SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /home/user/zintzxingcppdemo/build/local/deps/third-party/zint/backend/aztec.c:1131:13 in =================================================================...
-
FYI. The crash was found against HEAD and not against commit id fae3e6d9 which is hard coded within my repo.
-
Crash while fuzzing Zint C-API
-
Thany you all for your provided support Andre
-
At least this behavior should be somehow documented.
-
Indeed see Ticket #888, which we have already resolved, rebuilding from the source tar.gz doesn't show the crashes. This makes sense, locally -march=native is always ok. But for something portable like an AppImage, -march=native somehow works against the idea of portability. Question: Would it be possible to drop that -march=native somehow for the AppImage? Regards Andre
-
Could this be a CPU problem with my old Intel Core i7-3770 processor? The combinations - Ryzen 5 5625U + Ubuntu 22.04 - Ryzen 7 5700U + Fedora 37 with the AppImage don't crash
-
shouldn't it be possible to extract the contents of the AppImage without running it? The documentation from AppImage suggests that this should be possible. see https://github.com/AppImage/AppImageKit and search for --appimage-extract --appimage-mount --appimage-version
-
How exactly did you use this .iso file? I installed virt-manager and started the systemd service. Then i added the .iso to a new VM with 16Gb of RAM and 4 Cores, on my 32Gb i7-3770 host Used the first option in the Grub menu (Live Image) with the .iso file. Opened Firefox, downloaded from sourceforge the AppImage, chmodded it and executed it and crash. This all was very slow. Regards Andre Here is the output from the crash [liveuser@localhost-live ~]$ cd Downloads/ [liveuser@localhost-live Downloads]$...
-
How exactly did you use this .iso file? I installed virt-manager and started the systemd service. Then i added the .iso to a new VM with 8Gb of RAM and 4 Cores, on my 32Gb i7-3770 host Used the first option in the Grub menu (Live Image) with the .iso file. Opened Firefox, downloaded from sourceforge the AppImage, chmodded it and executed it and crash. This all was very slow. Regards Andre Here is the output from the crash [liveuser@localhost-live ~]$ cd Downloads/ [liveuser@localhost-live Downloads]$...
-
Checked again, still crashes. - I wonder if it would be possible to share how you built the Tulip-5.7.2.AppImage - Looks like it depends on the AppImage version being used, it might be possible to make the AppImage extractable. https://superuser.com/questions/1301583/how-can-i-extract-files-from-an-appimage - If extraction would be possible it should be easier for debugging
-
I'm attaching the output of a configure step when there is no python3-devel package installed
-
searching for this object.h file was the correct hint. The python3-devel package wasn't installed. After installing it the build worked with the unmodified tulip-5.7.2 shipped ConsoleUtilsModule.cpp file. But I suggest to error out at configure time and give some hints when the cmake configure step can't detect this file Regards and thank you very much Andre
-
the build still errors with the same file
-
I wonder where can I find the repo with the newest code? sourceforge looks too old and github has that remark that that repo isnt used anymore https://github.com/Tulip-Dev/tulip Regards Andre
-
I wonder where can I find the repor with the newest code? sourceforge looks too old and github has that remark that that repo isnt used anymore https://github.com/Tulip-Dev/tulip Regards Andre
-
nope, still 3.11.6 [user@localhost ~]$ python --version Python 3.11.6 [user@localhost ~]$ dnf list installed | grep python3.x86_64 boost-python3.x86_64 1.78.0-14.fc38 @updates libcap-ng-python3.x86_64 0.8.3-8.fc38 @updates libpeas-loader-python3.x86_64 1.36.0-1.fc38 @fedora python3.x86_64 3.11.6-1.fc38 @updates
-
missing text for property names for algorithm configurations when building with QT6 support
-
Add support for the trivial graph format .tgf
-
Can't compile Tulip 5.7.2 on Fedora 38
-
Tulip-5.7.2.AppImage crashes when selecting a layout algorithm within the GUI
-
Yes my relevant CI jobs are working again. Though I don't know how much longer I can keep these 32-bit build jobs running. Thank you very much for the quick fix. This ticket can now be closed. Best regards Andre
-
Yes my relevant CI jobs are working again. Thank you very much for the quick fix. This ticket can now be closed. Best regards Andre
-
broken test with Fedora 32bit build
-
broken test under clang memory sanitizer
-
Thank you very much gitlost for the additional information. So I think, this ticket can be closed. Best Regards Andre
-
Hi Martin, thank you very much for your reply. I'll have to check first, if it is possible that my input data already might provide the leading zeros for UPC-A and the check digits for all of the four symbologies mentioned in my ticket above. I have checked the zint manual but found nothing for configuring this behavior. Regarding quiet zones, I wonder if my quiet zone hack is really needed. We had a discussion some time ago where it was suggested by you as far as I can remember. Question: For the...
-
AztecCode and QRCode validation works as expected
-
ZXing-Cpp can't read zint generated EANX, UPCA, GS1_DBAR_OMN, GS1_DBAR_OMNSTK barcodes
-
Oh a classical PEBKAC :-( Turning off PNG and QT is done within my gitlab-ci.yml and injected into the zint-test.sh script. But locally I forgot to do this on my own for my zint-test.sh. Sorry. So this ticket can be closed. Kind regards Andre
-
Strangely. using the attached Dockerfile the libpng line in the output of the 'ldd' command doesn't show up.
-
Hi gitlost, Sorry, for misunderstanding this. I was trying to quickly write the zint output into a file, and reading it again with zxing-cpp. No libs are available (png, cairo, tiff, qt, etc) on my windocker CI setup at the moment. The only libs available are zint and zxing-cpp. But I can't link them together at the moment. Please don't ask ;-) I haven't checked zxing-cpp yet, if it has some self-contained graphics format support. Speed doesn't matter. Would it perhaps be possible to add support...
-
Here is the "debug output" of my attached zint-test.sh executed locally on my desktop pc in an empty directory. This is slightly different from the initial post, but shows the same behavior. + echo '--- begin debug output' --- begin debug output + cmake -E chdir /home/user/zint-test/build ls -al frontend total 100 drwxr-xr-x. 4 user user 4096 Jan 24 09:37 . drwxr-xr-x. 8 user user 4096 Jan 24 09:38 .. drwxr-xr-x. 3 user user 4096 Jan 24 09:36 CMakeFiles -rw-r--r--. 1 user user 2909 Jan 24 09:36 cmake_install.cmake...
-
turning off png support will still link the zint executable against libpng
-
hexadecimal dump is incomplete in dump_plot library function
-
Thank you Axel and gitlost for the clarifications.
-
Thank you for your support. I think this ticket can be closed. Kind regards Andre
-
Hi gitlost, essentially your suggestions fixed my problem, but I had to rework the Dockerfile a bit, supposedly due to recent changes within the fedora repo. I'm attaching my current Dockerfile in use.
-
Hi Alex, no I haven't noticed that yet. I only read some development discussions on github for zxing-cpp from time to time. So if I might dare to ask, is libzueci already dead? I'm currently refactoring some programs for testing from one of my co-workers. Regarding the dependency of zxing-cpp 2.0.0 on libzueci, if I do see libzueci occurrences in the output while building the library, wouldn't that count indeed as a dependency. nitpicking-off I do indeed only need READER support from zxing-cpp. Do...
-
sorry for the typo, should read 'Hi gitlost'.
-
It could be possible that I might miss a package which needs to be installed when using Fedora. Though using one of my opensuse 15.4 setups works out-of-the-box.
-
Broken qzint test under Fedora 36 and Gitlab CI
-
port a patch from Zint ticket #279
-
workaround gcc warning false positive
-
I've just once more checked with the most recent commit of master - gcc version 12.2.1 20221121 (Red Hat 12.2.1-4) (GCC) - clang version 14.0.5 (Fedora 14.0.5-1.fc36) on a fully updated Fedora 36 x64_86 and a slightly patched zint for getting extra debug output for that 'bp' variable My generated output files with gcc and clang were binary identical! Thus I consider this issue fixed. Thank you very much for your support gitlost Andre
-
Yes that fixed it. Thank you very much for the quick response as always. The ticket can be closed.
-
Linux (not Windows) tests broken with commit 831c704
-
a recent build with a prerelease Fedora 37 and a gcc 12.2.1-1.fc38, fc38?? is also clean for all my linux builds (fedora and opensuse). I wish I could use the clang memory sanitizer for the 32-bit builds, but the Fedora repo seems to lack the necessary libraries at the moment
-
I can't see these failues here anymore, so this ticket can be closed. Thank you very much @gitlost for your fixes.
-
add missing attachments
1 >
