Activity for Ryan Carsten Schmidt
-
Ryan Carsten Schmidt created ticket #197
README refers to nonexistent Fig.ad
-
gawk-gd: error: incompatible function pointer types initializing 'awk_value_t *(*const)(int, awk_value_t *, struct awk_ext_func *)' (aka 'struct awk_value *(*const)(int, struct awk_value *, struct awk_ext_func *)') with an expression of type 'awk_value_t *(int, awk_value_t *)' (aka 'struct awk_value *(int, struct awk_value *)') [-Wincompatible-function-pointer-types]
-
Build log
-
gawk-haru: error: incompatible function pointer types initializing 'awk_value_t *(*const)(int, awk_value_t *, struct awk_ext_func *)' (aka 'struct awk_value *(*const)(int, struct awk_value *, struct awk_ext_func *)') with an expression of type 'awk_value_t *(int, awk_value_t *)' (aka 'struct awk_value *(int, struct awk_value *)') [-Wincompatible-function-pointer-types]
-
The attached patch worked for me.
-
Undefined sqlite symbols
-
Incorrect memset size
-
radTimerListDebug declared to return int but doesn't return
-
radProcessQueueStopHandlerList declared to return int but doesn't return
-
error: implicit declaration of function 'radProcessGetNotifyFD' is invalid in C99
-
Web site doesn't exist anymore
-
In fact, identifiers containing __ are reserved by the implementation. You are not permitted to define or undefine or redefine them. In addition to undefining __BIG_ENDIAN__ and __LITTLE_ENDIAN__ in il_endian.h, there are many places in the ResIL code where such identifiers are defined. There are other identifier naming patterns that are also reserved. You should check if you're using any of those as well.
-
I am not well versed in writing cmake files but a quick search suggests using check_c_compiler_flag. It doesn't strike me as an old-cmake vs new-cmake problem. It strikes me as a problem of your CMakeLists.txt adding flags unconditionally when not all compilers support them.
-
Improve detection of Clang and when to add compiler flags
-
Only add flags if compiler supports them
-
Oh thanks! Being able to run cmake directly would certainly fix it. I've also submitted a stopgap fix for MacPorts that might also avoid the problem by running the cmake-unix, cmake-build, and cmake-install targets directly rather than getting to them through the switcher target: https://github.com/macports/macports-ports/pull/27594 I tried briefly to solve the Makefile problem... Several of the targets have rules that invoke multiple commands each, without using || exit $? after each command; however,...
-
Exit status not set correctly if cmake fails
-
I didn't add the pkgconfig dependency because di's only dependency is gettext which doesn't install pkgconfig files. Yes, if we used gmp or libtommath we might need pkgconfig. I'm aware of the libtommath issue and was looking into it. I think this issue can be closed. We got successful builds of di 5.0.3 on all systems (Mac OS X 10.6 and later). Thanks!
-
Thanks, I can confirm this is fixed in 5.0.3.
-
Thanks. I don't see any commits past the tag for 5.0.0 in this repository. When I install 5.0.2 from the tarball and run di --version it says di version 5.0.2 beta. In contrast, 5.0.0 said di version 5.0.0 production. Is 5.0.2 a beta version or stable?
-
I applied this smaller patch and we had successful builds on Mac OS X 10.6, 10.7, and 10.10 and later: https://github.com/macports/macports-ports/blob/0330f15f8f3e3548f4ac5d84ecae37357803d339/sysutils/di/files/CMakeLists.txt.patch We had this failure on OS X 10.8 and 10.9: clang: error: unknown argument: '-fstack-protector-strong' On 10.7 it just warned: clang: warning: argument unused during compilation: '-fstack-protector-strong' On 10.6 there was no problem because we use a newer clang that understands...
-
Installation of di.mo gettext message catalog bypasses destroot
-
That patch looks like it changes a heck of a lot more than just this problem. I'll try a more targeted fix. One option is to define the version in a separate file that contains nothing else. You can easily read such a file from cmake or a Makefile.
-
Right, but if the Makefile is going to call cmake then the one place to define your versions should be in the CMakeLists.txt not the Makefile. Sure, I can apply a patch to the port and see what happens on the build system.
-
On Mac OS X 10.7: $ grep 'typedef.*caddr_t' /usr/include/sys/types.h typedef char * caddr_t; /* core address */ On macOS 12: % grep 'typedef.*caddr_t' /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/_types/_caddr_t.h typedef char * caddr_t; Presumably what's relevant is that on MacPorts 10.12 buildbot builds it finds sys/quota.h: -- Looking for sys/quota.h -- Looking for sys/quota.h - found whereas on 10.11 and earlier it doesn't: -- Looking for sys/quota.h -- Looking for sys/quota.h...
-
Marius, I'm not sure what you mean when you say CLT are not recommended on Sequoia. Implicit function declarations have been an error since the version of clang included in Xcode 12.0. CMake exists on all versions of macOS in MacPorts. The fact that the ports web site doesn't show the file contents for CMake for some OS versions is likely just a bug in the ports web site. Take any information it provides with a grain of salt. On 10.11: $ egrep ' quotactl' $(find /Library -name quota.h 2>/dev/null)...
-
Correction: the old disk has macOS 10.15, not macOS 15.
-
Unable to find target partition "sda1".
-
Thanks. Your change looks reasonable: https://github.com/stevenshiau/clonezilla/commit/f1f246ab8ac2c0b29afefcf564e4acf54bdde7b0 I won't be able to try it at the moment. I don't want to erase and re-clone the affected drive right now, and I don't have another spare drive handy to try it on.
-
The original 256GB disk: Disk /dev/sdc: 232.89 GiB, 250059350016 bytes, 488397168 sectors Disk model: Sabrent Disk Dev Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 33553920 bytes Disklabel type: gpt Disk identifier: 830DB9E6-83B0-4628-A003-CF84835586AE Device Start End Sectors Size Type /dev/sdc1 40 409639 409600 200M EFI System /dev/sdc2 409640 123114719 122705080 58.5G Apple HFS/HFS+ /dev/sdc3 123114720 124384255...
-
Size of macOS recovery partitions should not be changed
-
Missing versions after 1.2.11
-
incompatible function pointer types
-
Spam in tcllib discussions
-
This error occurs when compiling vtwm 5.5.0 on macOS 12 with Apple Clang 14: add_window.c:463:19: error: implicit declaration of function 'time' is invalid in C99 [-Werror,-Wimplicit-function-declaration] int curtime = time(NULL); ^ To fix it, add #include <time.h>.
-
Newer compilers like llvm.org clang 18 consider this to be an error, not a warning: add_window.c:460:12: error: type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int [-Wimplicit-int] 460 | static lastwingroup = 0; | ~~~~~~ ^ | int add_window.c:461:12: error: type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int [-Wimplicit-int] 461 | static lastwin = 0; | ~~~~~~ ^ | int add_window.c:462:12: error: type specifier missing, defaults...
-
This warning occurs when compiling vtwm 5.5.0 on macOS 12 with Apple Clang 14: add_window.c:490:32: warning: converting the result of '<<' to a boolean always evaluates to true [-Wtautological-constant-compare] tmp_win->hints.flags &= !PPosition; ^ /opt/local/include/X11/Xutil.h:105:23: note: expanded from macro 'PPosition' #define PPosition (1L << 2) /* program specified position */ ^
-
These warnings occur when compiling vtwm 5.5.0 on macOS 12 with Apple Clang 14: add_window.c:460:12: warning: type specifier missing, defaults to 'int' [-Wimplicit-int] static lastwingroup = 0; ~~~~~~ ^ add_window.c:461:12: warning: type specifier missing, defaults to 'int' [-Wimplicit-int] static lastwin = 0; ~~~~~~ ^ add_window.c:462:12: warning: type specifier missing, defaults to 'int' [-Wimplicit-int] static lasttime = 0; ~~~~~~ ^
-
libintl.h is part of gettext. gettext is not part of Mac OS X so you'll have to install it separately.
-
error: call to undeclared function 'filedlg_show'
-
Duplicate of bug #14 which already has a patch to fix this.
-
Wrong GPL license version in about box
-
Translator credits don't appear in about box because of mismatch between code and .po file
-
glibmm build errors: no member named … in namespace 'Glib'
-
Spam in tinyxml discussions
-
I am able to extract if I exclude the bin directory, which is fine since I don't want the pre-compiled binaries: 7za x lzma2405.7z -x'!bin/*'
-
p7zip 16.02's 7za cannot extract lzma2405.7z
-
Spam posted by mughalhammad022
-
/opt/local/include/lqt/lqt_codecinfo.h:247:23: warning: this function declaration is not a prototype [-Wstrict-prototypes] void lqt_registry_init(); ^ void /opt/local/include/lqt/lqt_codecinfo.h:257:26: warning: this function declaration is not a prototype [-Wstrict-prototypes] void lqt_registry_destroy(); ^ void /opt/local/include/lqt/lqt_codecinfo.h:265:24: warning: this function declaration is not a prototype [-Wstrict-prototypes] void lqt_registry_write(); ^ void /opt/local/include/lqt/lqt_codecinfo.h:281:29:...
-
Where is your issue tracker? clang warns that you have some non-prototypes in your header: /opt/local/include/lqt/quicktime.h:563:20: warning: this function declaration is not a prototype [-Wstrict-prototypes] int quicktime_major(); ^ void /opt/local/include/lqt/quicktime.h:572:20: warning: this function declaration is not a prototype [-Wstrict-prototypes] int quicktime_minor(); ^ void /opt/local/include/lqt/quicktime.h:582:22: warning: this function declaration is not a prototype [-Wstrict-prototypes]...
-
Use cp -R instead of cp -r
-
My user email alias says 550 unknown user
-
Whether test failures are a concern is up to you! I just wanted to make sure you were aware of them. I can't recall whether the system I was using when I reported this initially was sluggish. Today I'm on a different Mac running macOS 12.7.2 and with gawk-select 1.1.4 I get some different test failures: ======== Starting select tests ======== kill inputfd outputfd nonblock Files ./nonblock.ok and _nonblock differ make[1]: [nonblock] Error 1 (ignored) select Files ./select.ok and _select differ make[1]:...
-
Thank you, I tested gawk-lmdb 1.1.3 on macOS 12.7.2 and it built fine.
-
As announced a year ago, GitHub has removed the Subversion bridge so you can't use svn:externals to reference GitHub repositories anymore.
-
linSmith was added to MacPorts in 2004, back when the project was called DarwinPorts; we changed our name to MacPorts in 2006. Not all of our contributors always inform the upstream developers when their software becomes available in MacPorts, but you do mention the availability of this port here: http://jcoppens.com/soft/linsmith/distros.en.php If you retain this information on your web site, please change the link to https://ports.macports.org/port/linsmith and change "Mac OS X" to "macOS". (Apple...
-
Hello, I'm a developer with MacPorts. We have version 0.99.31 of linSmith in MacPorts and it does not build on current versions of macOS (with clang). I noticed 0.99.32 and 0.99.33 were released last year and hoped that the build issues might have been corrected but they have not been. At configure time, this message is printed: configure: WARNING: 'missing' script is too old or missing I can use autoreconf to work around that, but at build time, these errors occur: remote.c:40:37: error: non-void...
-
Agreed, I am seeing the same crash with other software that uses gtk.
-
crash on launch in gdk_x_error
-
@elmimmo, looks like you've attached Makefile.mac from fondu_src-051010.tgz, the latest version in the Files section of this SourceForge project. In that version, running ./configure on macOS just copies Makefile.mac to Makefile and exits. In that version, it looks like the relevant line is: CORE = /System/Library/Frameworks/CoreServices.framework/CoreServices However, that is not the latest version. The latest version is available on this SourceForge project's web page and is called fondu_src-060102.tgz....
-
Thank you for your reply. If you haven't looked at this SourceForge project for ages, does that mean that the primary development site for this software, and the authoritative location for tarballs, has moved elsewhere? If so, where? Or does it mean this project is dead?
-
Nobody knows why these files were deleted?
-
Xcode project doesn't install macOS framework or headers or dynamic library anymore
-
Is this still an issue? This report was closed, then reopened. The URL for SuperTuxKart's bug report appears to have changed to: https://github.com/supertuxkart/stk-code/issues/894 and the URL for the fix appears to have changed to: https://github.com/supertuxkart/stk-code/commit/8dc86308e93b1e25ad605e87975c2f6e0711cfa2 That change does not appear in Irrlicht's 1.8 branch nor trunk (1.9), though I also don't think the proposed change makes any sense. The first part of the change which initializes...
-
property 'wantsLayer' not found on object of type 'id'
-
Yes I imagine that in addition to adding the arm directory and its files, you'd have to tell your various build systems to build those files, and possibly only on ARM systems; I'm not sure. This isn't a Mac-specific issue. Bug #443 was reported on an ARM system running Linux. There's also an edition of Windows for ARM processors that may be affected. I probably won't work on this myself since I don't use irrlicht and don't have an ARM system. My motivation as a MacPorts developer is to fix build...
-
This patch is not correct. For the right fix, see https://sourceforge.net/p/irrlicht/bugs/462/
-
The trunk patch.
-
cannot initialize a parameter of type 'id<NSFileManagerDelegate>' with an rvalue of type 'id<NSApplicationDelegate>'
-
Sure, here's the patch.
-
Undefined Neon symbols building for Apple Silicon
-
Your fix came in while I was writing this—thanks! I haven't made any effort to disable IRR_USE_NON_SYSTEM_ZLIB. I'm just doing a default build of the Xcode project. Is there any documentation for how to use that macro and the releated macros for the other libraries, especially when using the Xcode project? Sounds like this may be what I want in order to use my pre-existing libraries. Angle-bracket include statements (e.g. #include <zlib.h>) search all directories specified with -I in order, except...
-
Please check if the patch I attached to bug #459 fixes it.
-
The attached patch fixes it for me. This may also fix bug #442.
-
Case mismatch in IrrFramework-Info.plist filename
-
Undefined symbols: _inflateValidate
-
imaxima and imath web site not found
-
Specifically I think it was fixed in https://sourceforge.net/p/freeimage/svn/1809/ . The problem was reported again in https://sourceforge.net/p/freeimage/patches/153/ and the same patch suggested in here was submitted there again. Both of these submitted patches differ from what was committed in r1809. In r1809, the lines that called SwapLong on the elements of ddpfPixelFormat were removed, but in the two submitted patches, those calls were retained and ddpfPixelFormat was just renamed to ddspf....
-
Duplicate of #135, also.
-
The first three hunks of this patch were already committed years before you filed this issue as r1809 but I would ask the maintainer of freeimage to look at the last hunk of the patch to see if that is needed since r1809 did something different there. See https://sourceforge.net/p/freeimage/svn/1809/
-
gmtl-0.6.1.tar.gz file is created when building
-
Build failure when scons uses python 3 (patch attached)
-
I didn't like this patch because it determines either the gcc or the clang version and then uses them as if the two compilers have identical version histories, which they don't. For example, the script adds -fcoalesce-templates if the compiler version is less than 4. That's correct for gcc and incorrect for clang. Instead my patch looks at the preprocessor macros. gcc defines __GNUC__ to the major version and __GNUC_MINOR__ to the minor version. gcc 3 and later also define __GNUC_PATCHLEVEL__ to...
-
I didn't like this patch because it determines either the gcc or the clang version and then uses them as if the two compilers have identical version histories, which they don't. For example, the script adds -fcoalesce-templates if the compiler version is less than 4. That's correct for gcc and incorrect for clang. Instead my patch looks at the preprocessor macros. gcc defines __GNUC__ to the major version and __GNUC_MINOR__ to the minor version. gcc 3 and later also define __GNUC_PATCHLEVEL__ to...
-
version:1:1: error: expected unqualified-id
-
Well, without the period at the end: https://ports.macports.org/port/disktype
-
Update web page to mention availability in MacPorts
-
Here is one possible solution for the abort issue: https://github.com/macports/macports-ports/blob/cfbf212da89fb01c629b60859f1f76c93a76786a/math/tiemu3/files/abort.patch
-
This bug still exists in gdcm 3.0.10. Please apply the patch. It seems like the case of the library name should also be fixed in the find_library call, although it appears to work even with the wrong case. Note also that these changes will make gdcm no longer work with CharLS versions earlier than 2.1.0 on case sensitive filesystems since it was in CharLS 2.1.0 that the file names changed from "CharLS" to "charls". Here is a revised patch addressing these issues: --- CMake/FindCharLS.cmake.orig 2021-10-06...
-
I've reported it to Apple as feedback id FB9866173.
-
I found that in the MacPorts portfile, we were running strip cscope after compilation, and that removing that fixed the problem. I don't know why we were stripping the executable, but we had been doing so ever since cscope was added to MacPorts back in 2003. macOS was a much younger operating system back then and perhaps there was a good reason for stripping things at that time or perhaps it was just a whim of whoever added it. I don't know why stipping the executable is now all of a sudden causing...
-
dyld[39272]: symbol not found in flat namespace '_yylex'
-
Create a bug tracker
-
gawk-select 1.1.2 has the same problem and the same fix works.
-
gawk-select: outputfd and nonblock tests fail on macOS
-
gawk-lmdb: failure to parse headers on macOS
-
gawk-lmdb: basic test fails on macOS
-
configure: error: Could not find libid3tag
-
Wrong version in configure.ac
-
1.3.0 was released in 2020.
1 >
