cmake for AOS4 specific shared object libcurl.so.9 (And the mess of SOBJS in general)

Hi, the libcurl shared object available on os4depot is version 11, cmake from os4depot needs 9.

Any ideas?

Did you try to make a soft link from the 9 to 11?

@walkero

Hi, yeah I already tried that. The error message remains:


To be sure, I tried both (in local/newlib/lib):


and, just in case

@rjd324

Quote:

thats the wrong place.

".so" files should be installed into SOBJS: assign / sys:SObjs

This files has to be distributed with the executable file, and installed into the SObjs:,
(it won’t be logical to install in the SDK: not every user is a developer.)

@liveforit

Perfect thanks, I see, yes rpath set in /SObjs. Do not often see shared objects being used so far in my time using NG amiga, especially since they still are properly "shared", or so I hear.

Is there anything similar to LD_LIBRARY_PATH on the Amiga? Or, must these SO be in /SObjs?

I mean, it is still broken anyway for users who do not have an SDK. You install the libraries from OS4Depot, and they do not even in their autoinstall scripts set up the libraries for you in SOBJs.

No objections from me, I will just have to manually do this.

Then again, only devs would probably use cmake!

@rjd324

I think .so objects are unnecessary complex, static compiled all the why for me, unless, so objects are dynamic loaded like plugin or something, even then I most likely pick the . library format, unless I worried about being hacked. Like SSL most likely should not be a shared amiga library, not that any plugin can’t be totally replaced.

Quote:

No they not shared, they linked by ELF loader, just before program loads, but they can be loaded as plugins. for example if you ported XMMS you can use the plugin’s, without a major rewrite.

Even without considering Amiga, I have thought of SO to also be overly complicated.

The SOBJ situation really seems quite messy to me. On linux, we have SOs in one location. The linker knows where they are, and subsequently, the loader knows where they are and I am not even talking about the memory. It is the fact that the file itself is in the same location. But, currently, they seem poorly implemented on the Amiga... I now have to copy over all the SO files that are relevant for all of my programs that are loading them in at run time from - say - newlib to sobj:. This is now two places where I have to keep consistency. If there was an additional method to the rpath, like LD_LOAD_LIBRARY then I would consider just pointing it at local/newlib/lib -I would considere even that preferrable to having both SOBJS and the libs in newlib.

I think I will just try reassigning SOBJS: to that location (or, append it to that assign) and see what happens. Probably not a good idea.

Anyway, I am wondering why no one else has raised this complexity with CMAKE. I guess you guys are generally just cross compiling?

Alternatively, re-build cmake statically.

===
In fact, this SOBJ situation is such a mess, I am giving up and either rebuilding it all statically or just cross compiling.

@rjd324

Quote:

The things I work on is natively compiled; I have not built anything using dynamic linking.
I have had to make my own makefiles few times, or change things to build stuff.

@LiveForIt

For sure I prefer it that way, rather than using the cross compiler. The issue comes generally when porting things though. Either some project is using cmake, or the configure scripts call things like pkg-config which is just seemingly broken on Amiga. It is easier to get these to work on a linux machine where these tools work, and even the core-utils are more solid. Unless you also create your home-brew'd Makefiles from scratch.

(Actually, pkg-config invoked from configure scripts does work on amiga but not very well. you need to be in the directory of the pkg-config binary to run, for example, pkg-config --exists sdl2, otherwise it will always exit code non zero, even if you have it in your lib/pkg-config).

@rjd324

Yes, a lot of the Linux commands are broken, and deserves a better conversion, some of SH/ABCShell commands crash.