Activity for Marshall
-
Marshall posted a comment on ticket #354
Is it better to use the MSCV code for MinGW? Or does it really make no difference? The primary use case for the static library is to build and link everything to a single exe binary using the same MinGW compiler/toolchain, so the chance that a different pthread library is used should be low. 08.11.2023 16:28:51 Leon Bottou leonb@users.sourceforge.net: warning "This only works with MSVC. Memory leak otherwise" Now I remember this horror. The handling of thread local storage under windows is a catastrophe....
-
Just to make sure, do you confirm that adding DJVUAPI on Monitor and GSafeFlags is enough to make --export-all-symbols useless when compiling libdjvu as a dll? This was at least the case during my tests, yes. But I will do some more tests. Update: this isn't needed anymore it seems. pthreads: What is the benefit of using MINGW's pthread emulation on Windows? Same thing again: it can make sense to give priority to pthread if detected, but will this work on all platforms? I've tested enabling pthreads...
-
Just to make sure, do you confirm that adding DJVUAPI on Monitor and GSafeFlags is enough to make --export-all-symbols useless when compiling libdjvu as a dll? This was at least the case during my tests, yes. But I will do some more tests. Update: this isn't needed anymore it seems. pthreads: What is the benefit of using MINGW's pthread emulation on Windows? Same thing again: it can make sense to give priority to pthread if detected, but will this work on all platforms? I've tested enabling pthreads...
-
Just to make sure, do you confirm that adding DJVUAPI on Monitor and GSafeFlags is enough to make --export-all-symbols useless when compiling libdjvu as a dll? This was at least the case during my tests, yes. But I will do some more tests. pthreads: What is the benefit of using MINGW's pthread emulation on Windows? Same thing again: it can make sense to give priority to pthread if detected, but will this work on all platforms? I've tested enabling pthreads because of a warning I got during compilation,...
-
You should also enable pthread checks for Windows because implementations are avaiable for MinGW compiler. And if pthread wasn't found then HAVE_PTHREAD won't be set. Regarding -fvisibility: you could add compiler flag checks to configure.ac for these and other flags.
-
You should also enable pthread checks for Windows because implementations are avaiable for MinGW compiler. And if pthread wasn't found then HAVE_PTHREAD won't be set.
-
The changes in JPEGDecoder are needed because the build will otherwise break for some people on MinGW32: https://github.com/mxe/mxe/issues/3012 Besides I really wonder what these strange redefines are even meant for. They're not needed for GCC Linux and MinGW so I guess they're some workaround for MSVC? -fvisibility is known by clang but I guess you can make it optional. The user can always add it to the build flags themself.
-
Here's a much better patch. It will use »__attribute__((visibility("default")))« if a GNU compiler is used which works well on MinGW and Linux targets.
-
readelf fail to build with -Werror on Linux
-
build fixes for MinGW
-
also: aesdec, aesdeclast, vbroadcasti128
-
I don't really like the lack of MASM assembler dialect support on Linux. The assemblers are difficult to build from scratch. I don't know much about assembler programming, but is there a reason why the asm source files aren't written in a dialect supported by let's say NASM?
-
Unix Makefile updates
-
"gnu things"... I like you Pavlov :-) Well, there's a readme.txt file explaining how to compile on Unix systems.
-
I'll take a look at the makefiles and see if I can make unrar optional. Update: Here's a patch. Now you can set USE_JWASM=1 to build with jwasm instead of asmc and set DISABLE_RAR=1 to disable rar entirely. I've also added a distclean target and I've added "-nologo" to the AFLAGS.
-
I'll take a look at the makefiles and see if I can make unrar optional.
-
By the way: you can use jwasm, it only chokes on AesOpt.asm but the rest assembles fine. So if you can't use asmc you need to compile the AES sources with asm disabled (better than having asm disabled entirely I guess). make sure "asmc" is a link to "jwasm" cd CPP/7zip/Bundles/Alone2 build with asm, ignore errors: USE_ASM=1 IS_X64=1 make -j4 -k -f makefile.gcc rebuild AES files without asm: rm -f _o/Aes.o _o/MyAes.o && IS_X64=1 make -j4 -f makefile.gcc link with ASM enabled: USE_ASM=1 IS_X64=1 make...
-
By the way: you can use jwasm, it only chokes on AesOpt.asm but the rest assembles fine. So if you can't use asmc you need to build the AES sources with asm disabled (better than having asm disabled entirely I guess). make sure "asmc" is a link to "jwasm" cd CPP/7zip/Bundles/Alone2 build with asm, ignore errors: USE_ASM=1 IS_X64=1 make -j4 -k -f makefile.gcc rebuild AES files without asm: rm -f _o/Aes.o _o/MyAes.o && IS_X64=1 make -j4 -f makefile.gcc link with ASM enabled: USE_ASM=1 IS_X64=1 make...
-
A little hint on the Unix makefiles: add "-q" to the build flags to suppress the copyright message
-
Thanks for the Linux version! A hint if you want to provide Linux binaries: build them on old distros. I think it was mentioned before, simple Linux binaries built on old distros normally run on newer ones too, but often not the other way around. Your binary was linked against libgcc, libstdc++ and glibc, so no fancy dependencies there. If you can't run the 32 bit version on a 64 bit distro that means this distro has no multilib support installed.
-
Windows compatibility
-
I remember a discussion about the differences between 7zip and p7zip and why p7zip was outdated, but can't find it anymore. So I'm sorry for creating a new topic instead. I took a look at the lzma1900 sdk source and most of the C source files will actually build without problems on Linux. The example tools for 7z and lzma can be build with the provided Makefiles, for the full C sources I have attached a Makefile. Multi-threading still requires porting the code to use pthread, but compiling single-threading...
-
I remember a discussion about the differences between 7zip and p7zip and why p7zip was outdated, but can't find it anymore. So I'm sorry for creating a new topic instead. I took a look at the lzma1900 sdk source and most of the C source files will actually build without problems on Linux. The example tools for 7z and lzma can be build with the provided Makefiles, for the full C sources I have attached a Makefile. Multi-threading still requires porting the code to use pthread, but compiling single-threading...
-
I hope this is the right place to post this. I have written my own simple GUI using the FLTK toolkit: https://github.com/darealshinji/mediainfo-fltk I thought people may find it useful if they want to use libmedianfo and don't know where to start.
-
I think you can close this, as by now AppImage, Flatpak and Snap are provided.
-
Same issue. Seems to happen when I open an archive and adjust the file list table a bit. Since PeaZip launches and is capable of reading and creating common archive formats the issue is unlikely just a missing dependency. Addendum: This is the console output: $ peazip [DEBUG] Name com.canonical.AppMenu.Registrar does not exist on the session bus TApplication.HandleException Access violation Stack trace: $0000000000694F85 $00000000008B8A21 $000000000052C81F $00000000008AA7B4 $0000000000979A32 $0000000000939A45...
-
Same issue. Seems to happen when I open an archive and adjust the file list table a bit. Since PeaZip launches and is capable of reading and creating common archive formats the issue is unlikely just a missing dependency
-
Better .deb package creation [Linux]
-
p7zip seems to have diverged from 7zip quite a lot, so doing a simple diff doesn't help much. I guess someone would have to start from scratch by downloading the 7zip sources and writing a posix makefile for 7za, adding all the files needed to build it to that makefile and then going step by step through all the files that don't build. Quite a lot of work but probably not as much as trying to update p7zip.
-
You can at least compile an extractor from the official lzma sdk. There's a Makefile for GCC located at "C/Util/7z" that works on Linux.
-
Is that variable declaration thing in nsvg__addActive() really an issue? As for the float thing, the regular atof() function returns returns double too. I'd rather replace float with double wherever it's possible. Update: I've fixed remaining "-Wfloat-conversion" warnings.
-
Is that variable declaration thing in nsvg__addActive() really an issue? As for the float thing, the regular atof() function returns returns double too. I'd rather replace float with double wherever it's possible.
-
I've changed the code to not convert any unicode names. I've also edited nsvg__atof(). https://github.com/darealshinji/nsis-plugin-svg2bmp-test
-
Can you make a pull request to Github or post your changes somewhere else? Using Windows specific calls is fine since NSIS is Windows specific. As for float, isn't it better to use double everywhere? Maybe rendering of larger images can be speed up if you lower the DPI, which is currently hard-coded to 96.0.
-
I should have mentioned that I'm the guy who wrote the plugin. I've uploaded compiled DLLs to the release section: https://github.com/darealshinji/nsis-plugin-svg2bmp-test/releases The reason I'm using a shell script to build is that I only have VS 2017 installed. I don't have too much experience with VS and using MinGW seems to create smaller binaries while limiting the runtime dependencies to KERNEL32.dll, msvcrt.dll and USER32.dll.
-
I should have mentioned that I'm the guy who wrote the plugin. I've uploaded compiled DLLs to the release section. The reason I'm using a shell script to build is that I only have VS 2017 installed. I don't have too much experience with VS and using MinGW seems to create smaller binaries while limiting the runtime dependencies to KERNEL32.dll, msvcrt.dll and USER32.dll.
-
Here's a plugin to convert SVG files to BMP: https://github.com/darealshinji/nsis-plugin-svg2bmp-test I just don't know how to use it in a good way inside an NSIS script.
-
Here a plugin to convert SVG files to BMP. I just don't know how to use it in a good way inside an NSIS script.
-
It should be possible to use NanoSVG to write a small plugin.
-
cmake doesn't prefix intrinsics symbols
-
If this only works with MSVC isn't it better do surround it by #ifdef _MSC_VER ?
-
silence pragma warnings with MinGW
-
MingW32 static library builds
-
Appearently it's not that difficult to build a working static library with MingW32. Just apply the attached patch and make sure you build with -DDJVU_STATIC
-
Here are fixed debian packaging files. No lintian warnings at all. Everything important like removal of the old "malformed" repo packages or the removal of the conffiles is handled in the maintainer scripts preinst and postrm. I hope that helps.
-
repo-MediaArea-*.deb: incorrect packaging
-
An AppImage is a downloadable file for Linux that contains an application and everything...
-
An AppImage is a downloadable file for Linux that contains an application and everything...
-
An AppImage is a downloadable file for Linux that contains an application and everything...
-
"fullscreen" misspelled in option.c
-
please make installation paths configurable
-
compiler warnings
-
You can view the source code from an option in the context menu. At least on the...
-
Seems to be fixed in the latest versions. Using v0.7.87, compiled from source, on...
-
mingw32: can't (cross-)compile static library
-
Looking on the Google groups releaved this seems to be a common problem depending...
-
--checkbox option for text-info
-
--center not always working on v0.35.0
-
What about setting it through ./configure for the WxWidgets GUI? Also, since Tree...
-
build on Linux without libbsd
-
Same problem here. I just wanted to copy some files, but whatever I do, the ext4...
-
Merge pull request #34 from darealshinji/patch-1
-
Update autotools stuff for libtheora and build ...
-
libtheora: build with -fno-aggressive-loop-opti...
-
jpeg: CVE-2013-6629 and CVE-2013-6630 fix
-
move aclocal.m4
-
sqlite: use aclocal to generate aclocal.m4
-
Delete sqlite/aclocal.m4
-
xul.linux.rel.i686.lint: we're using our own op...
-
xul.linux.rel.x86_64.lint: we're using our own ...
-
xulrunner/nss: build with `-fno-strict-aliasing...
-
sqlite: enable warnings
-
taglib: pass build flags
-
lint-build hardening flags
-
taglib buildflags
-
Set correct path to symbolstore.py
-
lint-build.sh: build-deps for Debian-based systems
-
Merge pull request #31 from darealshinji/xul-19...
-
Update xulrunner's sqlite to v3.8.11.1
-
Update sqlite to v3.8.11.1
-
sqlite: set correct configuration, copy Makefil...
-
Update flags for hardened Xulrunner builds
-
Merge 9aeb26c4463306e31a1597412e3b2e9a5a5e7724 ...
-
Merge 9aeb26c4463306e31a1597412e3b2e9a5a5e7724 ...
-
build.sh: build sqlite first, strip release bin...
-
lint-build.sh: build sqlite and taglib first, s...
-
Merge 9aeb26c4463306e31a1597412e3b2e9a5a5e7724 ...
-
Merge b6c72405254b11ad4aa358fc9699e2971bb281a7 ...
-
Merge b6c72405254b11ad4aa358fc9699e2971bb281a7 ...
-
Merge 9aeb26c4463306e31a1597412e3b2e9a5a5e7724 ...
-
Merge b6c72405254b11ad4aa358fc9699e2971bb281a7 ...
-
Merge b6c72405254b11ad4aa358fc9699e2971bb281a7 ...
-
Debian packaging: don't override dh_builddeb
-
Debian packaging: bump Standards-Version
-
Add trailing newline to debian/rules
-
Try to fix Makefile verbosity stuff for Mac
-
Don not automatically silence strip
-
Use less confusing makro names
-
Still learning, but I'll try my best. ;-) Thanks for the advice.
-
You might want to take a look at this: https://github.com/darealshinji/debian-packaging/tree/master/games/alephone-svn...
1 >