Hyperion Entertainment Message Boards

I just got the server name corrected for AmiUpdate SDK updates and have downloaded a massive number of updates. Since this was my first SDK update with AmiUpdate, I decided to install everything manually. There seems to be some inconsistancy with file locations. For example, several libraries I've installed are placing config files in the SDK:local/newlib/lib/pkgconfig directory while "libftgl" is creating a new directory SDK:local/newlib/pkgconfig for it's config file. Some libraries are placing docs in SDK:local/share while others place them in SDK:local/newlib/share. Are the AmiUpdate libraries "officially" sanctioned additions/updates and are they being screened for consistancy??

I've never used shared-objects (.so) but the installation of the shared objects in the SDK is confusing to me. For one thing, why do we have links in SDK:local/newlib/lib/ pointing to shared object files in the SOBJS: directory? Are programs being compiled to load shared objects from the SDK instead of the SOBJS: directory?? My previous installation of libfreetype had a link in SDK:local/newlib/lib/ pointing to SOBJS:libfreetype.so but the new Freetype2 from AmiUpdate installs "libfreetype.so.16" in SDK:local/newlib/lib/ and overwrites the previous SDK:local/newlib/lib/libfreetype.so link with a new link to libfreetype.so.16. Is that right?? It also seems that programs will now be compiled to use the new includes for freetype but when executed they will load the old shared object in the SOBJS: directory. Is that wise? I doubt that we would be releasing SDK includes for a new OS shared library (like intuition.library) before the new library is officially added to the "public" OS installation and released to the users.

I'm sure some people will think I'm paranoid/crazy for installing all the SDK updates manually but it has raised some questions in my mind but I can't really change the way things are installed if I want my SDK to be consistant with everyone elses SDK installation.

I did the same and everything went fine afterwards, all projects still building

MickJT did take over the SDK update maintenance (and so far did a tremendous job)...
he will eventually find this thread and probably be very glad for your hints

As the SdkServer is nothing to do with AmiUpdate admin, nor Hyperion, you might have better luck contacting "Spot" or "MickJT" directly. It certainly isn't a discussion topic suitable for this forum. "MickJT" definitely checks amigans.net regularly, and there is a thread already active there.

Thank you

Simon

Here is a reply from MickJT regarding this subject:

Not all of the libraries at the SdkServer are compiled by me. Some are compiled by others, and they have chosen different directories to put things in. pkg-config files (.pc) should always be in SDK:local/<newlib or clib2>/lib/pkgconfig, so libftgl is using the wrong path there. I could fix the archive, and notify Spot if he wants to update it on OS4Depot as well. I won't change the datestamp, so it will not appear as a new update if you already have it installed.

As for documentation in SDK:local/share, that will have been done by other people, or if I was trying to keep consistency with older ports. I try to stick to standard paths, which will be local/newlib/share or local/clib2/share. If you find one of my own ports using a different path, it is only because I am being consistent with a previous porter's work. I will put header files in local/common/include unless they must differ between newlib and clib2.

SdkServer is not officially sanctioned, or at least I hope it isn't I do the best I can, but I don't have any real programming ability despite being able to port libraries, which doesn't require programming knowledge, except a bit of intuition.

As for libfreetype and any other shared libraries, I am consistent and let the configure scripts decide the version numbers. Previous ports by other people name the shared object as just .so. That happens because libtool doesn't recognize AmigaOS4 by default and doesn't put a version number for an unrecognized operating system. This is problematic as not all new versions are API compatible with previous versions. As with Linux, and my ports, they have a version number at the end. Normally that corresponds with a "MAJOR" number which increases with an API change or new features, and so it doesn't necessarily always increase with each new port. After running the configure script, I modify libtool and change version_type to freebsd-elf and deplibs_check_method to pass_all. This is, AFAIK, how kas1e also does it.

libfreetype.so.16 is the proper filename, and a symlink libfreetype.so will point to it. If you build a new program after installing libfreetype from the SdkServer, it will use .so.16, not the old .so in SOBJS:, so that is OK. None of my ports (or anyone else's AFAIK) on SdkServer should install anything to SOBJS. The shared objects in SOBJS: are files that come with the operating system, and perhaps a few that are installed automatically when installing the SDK. Overwriting files there could cause incompatibility with programs or the OS, although I am unaware of any OS components that make use of the default files in SOBJS:. Personally, I do fiddle with SOBJS:, adding new files only, but that's my own choice to do that.

Like you, I am very selective in which updates from SdkServer I choose to install, because at least with the ones I ported, I know where all the files are going to.