Re: [Fink-users] update of mysql-unified failure

[Daniel M. <dm...@ne...>]

 





On Sat, 18 Jul 2026 17:33:39 -0400, Scott Hannahs via Fink-users <fin...@li...> wrote:

>>
>>
>> > On Jul 18, 2026, at 5:58 AM, Daniel Macks wrote:
>> >
>> >
>> > On Thu, 16 Jul 2026 21:49:47 -0400, Scott Hannahs via Fink-users wrote:
>> >
>> >>> Luigi, Hanspeter,
>> >>>> On Jul 8, 2026, at 6:50 AM, Hanspeter Niederstrasser wrote:
>> >>>>
>> >>>>>>> On Jun 29, 2026, at 05:40, Luigi Ernesto Zanotti
>> >>>>>>>> wrote:
>> >>>>>>>
>> >>>>>>> Why is 'libndbclient.a' missing? Is it a problem with the 'old'
>> >>>>>>> Mojave system?
>> >>>>>>> Am I the only one that gets this?
>> >>>>>>> Thanks and best regards, Luigi Zanotti
>> >>>>>>>
>> >>>>>>
>> >>>>>> I haven’t installed mysql on even a recent macOS, but in doing a web
>> >>>>>> search on ‘libndb’ I find that is primarily for compatibility with
>> >>>>>> Plan 9 operating systems. I am not sure why it is being required.
>> >>>>>> Perhaps a configuration option needs to be tweaked? Is the source
>> >>>>>> code of libndb included in the mysql bundle that is downloaded?
>> >>>>>>
>> >>>>>> Another option is that fink is building libndb as a dynamic library
>> >>>>>> instead of a static one. Use the -k option to check if the library
>> >>>>>> exists as a dynamic library in the build folder. It looks like that
>> >>>>>> library should be part of the build.
>> >>>>>>
>> >>>>>> “In summary, libndb serves as a crucial tool for developers working
>> >>>>>> within the Plan 9 operating system, enabling them to manage databases
>> >>>>>> efficiently and effectively.”
>> >>>>
>> >>>> On 7/5/26 3:39 AM, Luigi Ernesto Zanotti wrote:
>> >>>>> Hello Scott,
>> >>>>> after reading your considerations and suggestions I decided to leave my lazyness and have a look into the build files.
>> >>>>> So I discovered that the issue isn't the libndbclient.a missing, but the folder /.libs/ missing, (see the message below)
>> >>>>> clang: error: no such file or directory: '../ndb/src/.libs/libndbclient.a'
>> >>>>> I then took the hazard of creating the /.libs/ and putting in it the library libndbclient.a taken from a previous mysql installation (2021); the result was that, after trials and errors due to 'bad permisssion' to be modified, I got a successful build, and new .deb files.
>> >>>>> Curiously, the libndbclient.a, that was required at the time of the error, is wiped out at further stages of the build, that I tried to follow in its evolution.
>> >>>>> I'm glad, but the point is that I found a therapy for my case, but wasn't able to find where the illness is starting from.
>> >>>>> Maybe it's a special issue for Mojave systems; unfortunately, when I sent the first message, I put in Cc the maintainer and got an 'invalid address' answer.
>> >>>>> Maybe you, that surely know how fink's tasks are assigned, can bring the issue to the attention of somebody else.
>> >>>>> Thank you so much for your help; best regards L. Z.
>> >>>>
>> >>>> I also have 10.14, but had no problems building mysql-unified. There are two likely reasons why libndbclient.a was not found/built:
>> >>>>
>> >>>> 1) It failed to build earlier in the build process, but the process didn't completely stop until it was required elsewhere, or
>> >>>> 2) the configure step is missing a dependency, which makes it decide to not build the NDB client library, but then doesn't propagate that it's not used to where it might be needed.
>> >>>>
>> >>>> For (1), check earlier in your build log if there's another error. Searching for the string 'error:' is usually enough.
>> >>>>
>> >>>> For (2), check the configure parts of the build process to see if NDB features are discovered.
>> >>>>
>> >>>> I see this where it worked:
>> >>>>
>> >>>> checking for csv storage engine... yes
>> >>>> checking for blackhole storage engine... yes
>> >>>> checking for NDB Cluster... Using NDB Cluster
>> >>>> could not find sci transporter in /{include, lib}
>> >>>> checking for NDB Cluster options...
>> >>>> -- not including ndbapi test programs
>> >>>> -- not including ndbapi and mgmapi documentation
>> >>>> done.
>> >>>>
>> >>>> Hanspeter
>> >>>
>> >>> It has been awhile, but I finally got around to attempting a build of mysql-unified on MacOS 26.5/Intel. I get to a different error since the compiler is pickier. But I am guessing that this is part of the build of libndbclient? The Makefile has the lbindbclient.a mentioned but no rule to build it.
>> >>>
>> >>> -Scott
>> >>>
>> >>> NdbScanOperation.cpp:696:10: warning: variable 'ret' set but not used [-Wunused-but-set-variable]
>> >>> 696 | bool ret = true;
>> >>> | ^
>> >>> NdbScanOperation.cpp:1191:20: error: non-constant-expression cannot be narrowed from type 'int' to 'Uint32' (aka 'unsigned int') in initializer list [-Wc++11-narrowing]
>> >>> 1191 | Uint32 buf[2] = { type, ahValue };
>> >>> | ^~~~
>> >>> NdbScanOperation.cpp:1191:20: note: insert an explicit cast to silence this issue
>> >>> 1191 | Uint32 buf[2] = { type, ahValue };
>> >>> | ^~~~
>> >>> | static_cast( )
>> >>> 13 warnings and 1 error generated. >> _______________________________________________
>> >
>> > That's the same result and as far as I was able to push mysql-client on 26.0/ARM a few weeks ago before I gave up. This package is a fairly old version, not easily diff'able vs current upstream such as it is.
>> >
>> > Regarding manually looking through Makefile recipes,".a" files are often called ".la" files when libtool is used as part of the autotools toolchain.
>> >
>> > dan
>>
>> Well, I can patch the source to add a cast on line 1191 of NdbScanOperation.cpp
>> Uint32 buf[2] = { type, ahValue }; -> Uint32 buf[2] = { static_cast(type), ahValue };
>> But I think I will just run into many many more tweaks to bring the source up to modern requirements. And since fink quits on the first error this could be a long iterative process.
>>
>> Probably “type” should have been declared as a Uint32 originally, thus avoiding the cast?

Per upstream it's all sorts of tangle, and I don't pretend to understand it:(

dan