Hello, I'm trying to compile the latest SQLite for an old system that for some reason includes the word "apple" in the build target, despite being a Linux/GNU system. This causes the build to create .dylib files instead of .so files.

I tracked this down to the autosetup/proj.tcl that in the proj-looks-like-mac and proj-dll-extension functions identifies the host based on just *apple*, instead of what I think should be replaced with *-*-darwin, as it does with cygwin etc.

As a side note, the proj-dll-extension does the identification on its own instead of just using the proj-looks-like-windows and proj-looks-like-mac functions, which seems a bit unnecessary to do when the specific functions exist.

I'm trying to compile the latest SQLite for an old system that for some reason includes the word "apple" in the build target, despite being a Linux/GNU system. This causes the build to create .dylib files instead of .so files.

Certainly that's not surprising?

I tracked this down to the autosetup/proj.tcl that in the proj-looks-like-mac and proj-dll-extension functions identifies the host based on just apple, instead of what I think should be replaced with --darwin, as it does with cygwin etc.

That sounds reasonable. i will make that change but can't test it, so please be on the lookout for a checkin soon which does that and try it out. That there is an OS which uses "apple" in its name, which isn't from that particular company, comes as a complete surprise to me.

As a side note, the proj-dll-extension does the identification on its own instead of just using the proj-looks-like-windows and proj-looks-like-mac functions, which seems a bit unnecessary to do when the specific functions exist.

i'll look into that.

Thank you for the feedback!

i will make that change but can't test it, so please be on the lookout for a checkin soon which does that and try it out.

That's now in the trunk, along with your other suggested cleanup. If you're able, please build from there and verify that it's not hosed something unrelated.

Thanks again!

However, I also tried under macOS, but it turns out that there was a version number added after darwin in that case, so the detection should probaby be replaced with --darwin* which I tested to replace it with and it worked as expected.

Great, thank you! i contemplated adding that trailing asterisk initially and left it, but will do so momentarily.

I tracked this down to the autosetup/proj.tcl that in the proj-looks-like-mac and proj-dll-extension functions identifies the host based on just apple, instead of what I think should be replaced with --darwin, as it does with cygwin etc.

I was curious about what happens here for Apple machines pre-OSX -- for most projects this would be utterly irrelevant but SQLite has a long enough history that there may still be someone running it on an antique somewhere :)

It turns out that autoconf's config.sub has similar logic where a wildcard on "*-apple" defaults the OS to "macos", however this is only invoked if the OS has not already been identified.

In your case I'm guessing "apple" is part of the vendor, possibly because of the machine's hardware? It would be nice to have a record of what gcc -dumpmachine outputs for you if you're happy to share.

(props to http://wiki.osdev.org/Target_Triplet for pointing me in the direction of config.sub)

Yes, it is an old Mac in this case. The intended target is powerpc-apple-linux-gnu. Looking at Retro68, it seems like the pre-OSX versions could be called m68k-apple-macos or powerpc-apple-macos.

Also, It doesn't seem like pre-OSX uses dylib files, so that would probably not work. In fact, it looks like dylib weren't even used for the early OSX versions. Source.

Another thing I found when I looked more into this is that -darwin might not be used for some Apple targets. It seems like there also could be aarch64-apple-ios, aarch64-apple-tvos, aarch64-apple-visionos and aarch64-apple-watchos, but I'm not sure if all these use dylib files. Source.

I noticed that one of my previous posts isn't shown yet, but my intended target was powerpc-apple-linux-gnu. Pre-OSX could be called m68k-apple-macos or powerpc-apple-macos, but those doesn't seem to use dylib files.

Regarding iOS, watchOS and tvOS, they also seem to use dylib files the same way as macOS. I suggest that these are added as possible Mac platform targets.

If pre-OSX is to be supported, I do think that the best compatibility would be to treat them as Linux, as I guess most other Apple specific code is due to the Darwin implementations.

The safest way of identifying modern Apple OS:es seems to be using the #ifdef __APPLE__ predefined macro, but is it that those are maybe not supported in tcl files? Pre-OSX seems to use #ifdef Macintosh in such cases.

Indeed, I used, and maintained security updates to mklinux for a number of years. Even though mklinux was an Apple spin-off, i.e. a Mach micro-kernel with RedHat style user land, all dynamic objects were .so files.