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.
Thanks! Version 1.60 does seem to fix it.
extraneous boxes with a "?" appended to directory entries
The PR has been merged so this can be closed.
https://github.com/net-snmp/net-snmp/pull/309
It was fixed in https://github.com/mej/Eterm/commit/4b35c31087048af38083a5a0273ab5a72064626b several years before your bug report.
Aften fails to build under arm64 macOS
This is the same as https://sourceforge.net/p/mcrypt/bugs/36/, but you should not include malloc.h or malloc/malloc.h on any system; you should include stdlib.h on all systems.
No, don't include malloc.h or sys/malloc.h on any system. On all systems, include stdlib.h.
Build failure due to implicit declaration of functions
I downloaded the new configure file and put it into the autoconf directory of schily-2020-11-04 and ran make. It failed with: In file included from cdda2wav.c:102: ./mytype.h:29:1: error: unknown type name 'error' error need an integer type with 32 bits, but do not know one! ^ Earlier in the configure output I see: checking size of char... 0 checking size of short int... 0 checking size of int... 0 checking size of long int... 0 checking size of long long... 0 checking size of __int64... 0 checking...
Do you mean https://sourceforge.net/projects/schilytools/files/? I don't see a separate configure file there. You could attach a file to this ticket if you want.
If you have a fix you'd like me to test before release I can do that.
implicitly declaring library function 'exit'
gnu-pw-mgr should be available in MacPorts within the hour: sudo port install gnu-pw-mgr
libintl.h is part of gettext, which Apple does not include in macOS; you would have to install gettext yourself, either by building it from source or installing it using a package manager like MacPorts or Homebrew. I assume the password manager you're referring to is gnu-pw-mgr? I could try adding it to MacPorts for easier installation.
An alternative to messing with DYLD_LIBRARY_PATH, if it's too difficult to manually propagate it to everywhere it's needed, is to build the library with an install_name pointing to its location in the build tree. Then the tests should run just fine, since the library will be where its install_name says it is. Upon installation, relink the library with the install_name pointing to the final install location and relink all the programs that had been linked with the library during the build. The install_name...
DYLD environment variables are available to the autogen process, they're just not automatically propagated to subprocesses anymore. This is a new security measure introduced in OS X 10.11 as part of a feature Apple calls System Integrity Protection. Apple isn't trying to prevent programs from passing DYLD variables along manually, they just don't do so automatically anymore since that was a security vulnerability. Running the test suite on OS X 10.10 which does not have that protection, the test...
You're right, dyld is the macOS-specific dynamic library loading mechanism, and the DYLD environment variables that can be used to modify its behavior are also macOS-specific. You're also right that libtool should handle this. libtool creates a script agen5/autogen which sets DYLD_LIBRARY_PATH and then launches the compiled executable agen5/.libs/autogen. I think the problem is related to the fact that autogen relaunches itself. When the getopt test fails, macOS generates two crash reports. Usually...
Should '-no-install' be removed?
Thanks, that's promising. It got -L/opt/local/lib into the compile flags, but still not -lintl. With a little experimentation, I found that the changes to Makefile.am were not needed and the following changes let the tests (except getopt.test) pass: --- a/autoopts/test/defs.in +++ b/autoopts/test/defs.in @@ -283,7 +283,7 @@ compile() test "X${Dnam}" = "X" && Dnam="${testname}" d=`echo TEST_TEST_${Dnam}_OPTS | ${TR} '[a-z]-' '[A-Z]_'` - cc_cmd="${CC} ${CFLAGS} -D$d ${INC} -o ${Cexe} ${Csrc}.c ${LIB}"...
Just to add, if nobody else sees this problem on macOS, maybe that's because nobody else is running the tests on macOS, or those who are aren't trying to do so with gettext. macOS doesn't ship with gettext so the user would have to install it themselves and configure autogen to use it. If I just run ./configure --disable-dependency-tracking ac_cv_func_utimensat=no make -j8 make check then it doesn't find gettext and all tests succeed (except one, for which I've filed bug #200). But if I have gettext...
getopt.test test fails on macOS
Well I'm the maintainer of gettext in MacPorts and I have over 150 other ports installed that use gettext, so I think gettext is installed correctly. I agree that the tests are failing because gettext symbols can't be found, but I think the reason for that is that the -L/opt/local/lib -lintl flags are not being used here in the tests. I don't know why that is though.
I tried the tests again now on macOS 10.13 and got the same failing results.
Fix implicit declaration of functions
Here is a patch to fix it.
error: call to 'wcschr' is ambiguous
The latest code on github uses the cmake build system. The autotools build system has been deleted. This can be closed.
It has been fixed in the latest code on github. This can be closed.
address of array will always evaluate to 'true'
result of comparison of constant 0 with expression of type 'bool' is always false
error: use of undeclared identifier 'bfd_get_section_name'
Well I'm not going to subscribe to a mailing list just to report this problem to you again somewhere else. :)