Activity for ECMA-234 Metafile Library
-
Allen Barnett posted a comment on ticket #7
Hi Sergey: Can you checkout the SVN HEAD. I applied a patch for this some months ago, but I never heard back from the submitter that it worked, so I never made a release. If you could test it, I would appreciate it. Thanks, Allen
-
Sergey Fedorov created ticket #7
1.0.13 build is broken on macOS due to using of Linux-specific header
-
Hi Hanspeter and Scott: I have committed Hanspeter's patch to the repository (along with an update to the autotools/configure scripts). Please check that the svn HEAD (r101) compiles and passes regression on a macos machine. If it works, I'll make a release of 1.0.14 (if I can remember how, anyway). I've been trying to remember why the endian-ness check is a run-time function and not a manifest attribute of the platform. But, I just can't recall what I was thinking in 2010 :-) I don't really want...
-
Apply Hanspeter Niederstrasser's patch for macos.
-
Update to latest autotools 1.16 on Pop!_OS (Ubuntu 22.04 LTS).
-
Scott Hannahs posted a comment on ticket #6
The bigEndian() check is a run time check. The #include <byteswap.h> is always included by the precompiler before the compile phase. It would have to be excluded by an #IFDEF or some other precompiler flag along with removing the actual call to bswap_32 also with an #IFDEF compiler directive.</byteswap.h>
-
Hanspeter Niederstrasser posted a comment on ticket #6
My patch to add libkern/OSByteOrder.h on Apple is attached. It's pretty simplistic and only checks for __APPLE__. As Scott says, an autotools method (AC_C_BIGENDIAN) could be 'better' (for some definition of better), but it seems overkill for this and then having to maintain configure.ac, etc. Would it improve it to wrap the entire set of includes on an #ifdef for __BIG_ENDIAN__ (does gcc have this macro or just __ORDER_BIG_ENDIAN__ )? The only thing I'm unclear on is why my x86_64 system (little...
-
Thanks for your suggestions. I will probably apply Hanspeter's #include change as that seems like the simplest way.
-
Or if you want to be specific to Apple clang, it has the following relefant defines to avoid including bytesswap.h? #define __APPLE__ 1 #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__ #define __LITTLE_ENDIAN__ 1 #define __ORDER_BIG_ENDIAN__ 4321 #define __ORDER_LITTLE_ENDIAN__ 1234 #define __ORDER_PDP_ENDIAN__ 3412
-
Shouldn't endianess be determined by configure and byteswap.h only included if the system is big-endiean? Usualy configure is used to determine endianess at compile time.
-
Not a C person, but looking at the code, I'm confused as to what it's actually doing. It goes into the DWORD swab, and checks if the system is bigEndian(). If not, then it returns a. Should that then exit and not run bswap_32(a)? Or am I misunderstanding and it'll always return both a and the swapped a? I'm on x86_64, which is little endian, so I would expect it to not try to run bswap_32 (forgetting for the moment the header issue).
-
Yes, both the Arm and X86_64 Apple systems are little endian. Can we just trigger not to call byteswap or include it ifdef Apple ?
-
I have no recollection of why I put the #include in the middle of the function; it seems dumb in retrospect. Your #ifdef/else at the top is OK with me. I don't want to have to struggle with autotools anymore. I have no way to test this on a mac, but if you send me a patch I'll apply it. Are the new ARM-based macs run in little endian mode? Because the whole bswap business is never invoked on little endian machines anyway. On Fri, Apr 18, 2025 at 7:49 AM Hanspeter Niederstrasser nieder@users.sourceforge.net...
-
So I tried that, but if I put the following in place of the #include <byteswap.h> down on line 75, I get errors about function definitions before '{' tokens. #ifdef __APPLE__ #include <libkern/OSByteOrder.h> #define bswap_32(x) OSSwapInt32(x) #else #include <byteswap.h> #endif So I had to move the whole #include chunk to the very top after #include <climits> I don't know if it would be more appropriate to check for byteswap.h in configure and check for other possibilities if not found rather than...
-
Searching gives changes like this: #include <libkern/OSByteOrder.h> #define bswap_16(x) OSSwapInt16(x) #define bswap_32(x) OSSwapInt32(x) #define bswap_64(x) OSSwapInt64(x) Would need to #ifdef on __APPLE__ probably. https://stackoverflow.com/questions/41770887/cross-platform-definition-of-byteswap-uint64-and-byteswap-ulong
-
It looks like bswap_32 is the only function used from byteswap.h. Is there an equivalent function on macOS? (https://man7.org/linux/man-pages/man3/bswap.3.html)
-
1.0.13 build fails with newer gnulib::byteswap.h
-
Nuno Teixeira posted a comment on ticket #5
Hello, Committed in https://cgit.freebsd.org/ports/commit/?id=2f3cbb880dc06413014f6661caea4e046bf36c5f Thanks
-
Hello Allen, graphics/libemf port uses gnu configure and I'm using workaround: USES=compiler:c++14-lang (to tell ports framework that a c++14 capable compiler is needed) USE_CXXSTD=c++14 (to force -std=c++14 on compiler) IMHO there is no need to change to cmake just because of forcing -std, but cmake is a newer build system. Since clang16 have landed a lot of programs have broken because of c++17 default standard and solutions are being searched to fix code so c++17 compliant can be achieved when...
-
Hello Allen, graphics/libemf port uses gnu configure and I'm using workaround: USES=compiler:c++14-lang (to tell ports framework that a c++14 capable compiler is needed) USE_CXXSTD=c++14 (to force -std=c++14 on compiler) IMHO there is no need to change to cmake just because of forcing -std, but cmake is a newer build system. Since clang16 have landed a lot of programs have broken because of c++17 default standard and solutions are being searched to fix code so c++17 compliant can be achieved when...
-
Thanks for the report. I think using the CMake version of the build system would be the best way to introduce the --std=c++14 flag. What version of CMake is available in the port system?
-
Thanks for the report. I think using the CMake version of the build systemm would be the best way to introduce the --std=c++14 flag. What version of CMake is available in the port system?
-
build fails on clang16
-
ECMA-234 Metafile Library released /libemf/1.0.13/README
-
Release of libEMF-1.0.13
-
-
-
Add CVE message to NEWS file.
-
I learned something new: integer division of INT_MIN (0x80000000) by
-
Re-Release of libEMF-1.0.12
-
-
-
For re-release: Merge the updated NEWS file from the trunk.
-
Add the resolved CVEs to the NEWS file.
-
Michael Shigorin modified a comment on ticket #3
Thank you, libemf 1.0.12 builds fine on both aarch64 and e2k with no extra patches. Just for the record: the pristine tarball builds on e2k with lcc 1.24.09 (while 1.23.21 would error out even with explicit -std=c++11 but that's another story apparently not worth solving). PS: http://git.altlinux.org/tasks/250671
-
Thank you, libemf 1.0.12 builds fine on both aarch64 and e2k with no extra patches. Just for the record: the pristine tarball builds on e2k with lcc 1.24.09 (while 1.23.21 would error out even with explicit -std=c++11 but that's another story apparently not worth solving).
-
Tag 1.0.12
-
Release of libEMF-1.0.12
-
-
Use a few more C++11-isms to simplify the code.
-
1. Be more resistant to division by zero in the window and viewport
-
Be more robust in the face of corrupted metafiles. Print a bit more
-
Hi Michael: I have committed your patches to the SVN repository. Please check out the trunk and make sure it functions as you expect. Thanks, Allen On Sun, Sep 22, 2019 at 10:43 AM Michael Shigorin gvy@users.sourceforge.net wrote: [patches:#3] https://sourceforge.net/p/libemf/patches/3/ initial aarch64 and e2k support patches* Status: open Group: Unstable_(example) Labels: arch Created: Sun Sep 22, 2019 02:43 PM UTC by Michael Shigorin Last Updated: Sun Sep 22, 2019 02:43 PM UTC Owner: nobody Attachments:...
-
Done. And thanks for your contribution! On Sat, Mar 28, 2020 at 4:02 PM Michael Shigorin mike@altlinux.org wrote: On Sat, Mar 28, 2020 at 07:56:33PM -0000, Allen Barnett wrote: I committed the updated config.sub and config.guess. svn up; ./configure; make CXXFLAGS+=-std=c++11 all check went fine, thank you! If you're happy, I will close ticket #3. I was happy with your initial commit already :-) -- ---- WBR, Michael Shigorin / http://altlinux.org ------ http://opennet.ru / http://anna-news.info
-
Done. And thanks for your contribution! On Sat, Mar 28, 2020 at 4:02 PM Michael Shigorin mike@altlinux.org wrote: On Sat, Mar 28, 2020 at 07:56:33PM -0000, Allen Barnett wrote: I committed the updated config.sub and config.guess. svn up; ./configure; make CXXFLAGS+=-std=c++11 all check went fine, thank you! If you're happy, I will close ticket #3. I was happy with your initial commit already :-) -- ---- WBR, Michael Shigorin / http://altlinux.org ------ http://opennet.ru / http://anna-news.info --...
-
initial aarch64 and e2k support patches
-
On Sat, Mar 28, 2020 at 3:25 PM Allen Barnett allenbarnett5@gmail.com wrote: On Sat, Mar 28, 2020 at 3:08 PM Michael Shigorin mike@altlinux.org wrote: On Sat, Mar 28, 2020 at 06:54:27PM -0000, Allen Barnett wrote: Well almost, autoreconf -fisv has masked the need to update config/config.{guess,sub} from recent gnu-config so it has these arches handy too; would be perfect if you updated them from http://git.savannah.gnu.org/gitweb/?p=config.git I'm planning on deprecating the autoconf build in favor...
-
Update config.guess and config.sub to newer versions supporting aarch64 and
-
Hi Michael: I have committed your patches to the SVN repository. Please check out the trunk and make sure it functions as you expect. Thanks, Allen On Sun, Sep 22, 2019 at 10:43 AM Michael Shigorin gvy@users.sourceforge.net wrote: [patches:#3] https://sourceforge.net/p/libemf/patches/3/ initial aarch64 and e2k support patches* Status: open Group: Unstable_(example) Labels: arch Created: Sun Sep 22, 2019 02:43 PM UTC by Michael Shigorin Last Updated: Sun Sep 22, 2019 02:43 PM UTC Owner: nobody Attachments:...
-
On Sat, Mar 28, 2020 at 3:08 PM Michael Shigorin mike@altlinux.org wrote: On Sat, Mar 28, 2020 at 06:54:27PM -0000, Allen Barnett wrote: Well almost, autoreconf -fisv has masked the need to update config/config.{guess,sub} from recent gnu-config so it has these arches handy too; would be perfect if you updated them from http://git.savannah.gnu.org/gitweb/?p=config.git I'm planning on deprecating the autoconf build in favor of CMake. I find the autoconf stuff just to hard to maintain. Well if good...
-
On Sat, Mar 28, 2020 at 2:35 PM Michael Shigorin mike@altlinux.org wrote: On Sat, Mar 28, 2020 at 01:39:31PM -0400, Allen Barnett wrote: I have committed your patches to the SVN repository. Please check out the trunk and make sure it functions as you expect. Well almost, autoreconf -fisv has masked the need to update config/config.{guess,sub} from recent gnu-config so it has these arches handy too; would be perfect if you updated them from http://git.savannah.gnu.org/gitweb/?p=config.git I've tested...
-
Alternative build system based on CMake.
-
Add big-endian mips configuration.
-
Add "context" support for aarch64 and e2k architecture.
-
Fix file reading on big-endian CPUs.
-
Remove unused code.
-
Generally, try to be more robust in the face of inconsistent EMF
-
Thanks! I will try to apply your patches in the not-too-distant future.
-
initial aarch64 and e2k support patches
-
Balint Reczey posted a comment on ticket #4
Hi Allen, Yes QEMU can emulate big endian systems, but I have already tested it on s390x patching the current Debian package. So if you are happy with it on amd64 I think you can safely take it.
-
Hi Balint: Thank you for the patch. I see what you're getting at there. I don't have any way to test the big-endian code. I used to have a sparc-based javastation, but that has long since gone to electronics recycling. Do you have a suggestion for how I could build and test the big-endian code? Does QEMU simulate big-endian systems?
-
Hi Allen, The fix broke libemf on big endian systems, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919766 . The attached patch tries to follow the concept of the original fix in an endian-aware way. Please consider accepting it. LibEMF could also make use of a test where it tries to read a sample file truncated to 0..n-1 bytes wrapped in Valgrind. Thanks, Balint
-
docheck2 test failure
-
Release of libEMF 1.0.11
-
I guess this is fixed in 1.0.10 (and later). Thanks for the reports.
-
Tag 1.0.11
-
-
Update the version to 1.0.11.
-
Be more careful when reading a metafile. EOF is only allowed when
-
Tag 1.0.10
-
Rename the docheck scripts to docheck.sh and then add a dependency on
-
For what it's worth, I think I have a fix for this. I'll try to patch it up over Christmas break. Thanks for your reports. On Mon, Dec 3, 2018 at 12:50 PM Daniel Bermond danielbermond@users.sourceforge.net wrote: I also have the same issue. I add here that the 'docheck2' test fails randomly for me. Sometimes it fails and sometimes it passes. System Information: OS: Arch Linux x86_64 Compiler: gcc 8.2.1 libEMF: 1.0.9 [bugs:#4] https://sourceforge.net/p/libemf/bugs/4/ docheck2 test failure* Status:...
-
Daniel Bermond posted a comment on ticket #4
I also have the same issue. I add here that the 'docheck2' test fails randomly for me. Sometimes it fails and sometimes it passes. System Information: OS: Arch Linux x86_64 Compiler: gcc 8.2.1 libEMF: 1.0.9
-
OK! I can cause the same problem on linux with "make -j2 check". So, I'm at the mercy...
-
It's a race condition in the make check sequence. I noticed that the output during...
-
Here's check2.emf. check1 and check3 pass OK.
-
I'm not sure I can find such a system to test on. I'll ask around. Meanwhile, can...
-
I'm on OS X 10.11, using in the built-in clang compiler. I build with the standard...
-
Hey: I just downloaded, built and tested the 1.0.9 release. It works OK for me (on...
-
docheck2 test failure
-
Release of libEMF-1.0.9
-
-
Update the Doxygen documentation.
-
Thanks to Guillaume Horel for pointing out that...
-
Release of libEMF-1.0.8
-
-
An installer for testing. The idea is that you ...
-
Try to put installers (or distributions) here.
-
Not really a good place for this.
-
Create a place to store installers (or distribu...
-
Update the Doxyfile to version 1.8 and clean th...
-
Some more updates due to newer versions of the ...
-
More updates to the Doxygen HTML.
-
Add TextOutW and ExtTextOutW courtesy of Bill C...
-
Patches needed to compile under GCC 3.2
-
Sorry. For a long time source forge was throwing away my mail. It should work now,...
-
libEMF-1.0.4
-
I think this is fixed.
-
Wow. I didn't even know these feature requests existed. This seems reasonable. I'll...
-
Update to gcc4
1 >
