@MamePPCA1

So this is playable without the new Enhancer pack?

What would be nice is at least read-only access to the bugs database, with of course ID numbers. And with any new release a reference to the ID numbers that have been fixed.

I don't think gdb works for us at the moment. There is "spotless" debugger.

Two things

1. I wouldn't expect the need to explicitly pass in the include flags to the compiler since -mcrt clib2 should do that anyway behind the scenes?

2. Maybe you can recompile with SDL SOFTWARE rendering flag instead of HARDWARE ACCELERATED.

Just some thoughts.

Quote:

How did this work out for you? There is no working GDB, right?

Thanks @walkero

Nice.

If I remember this is because of the SDK version you are using. Need 53.34...

I got this error not long ago and if I recall, that's what I needed.

@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).

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.

Then again, only devs would probably use cmake!

@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.

AbiWord seems capable enough. Opened doc and docx so is there really still a need or desire for OpenOffice?

@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

--- ignore.

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

Any ideas?

This worked fine.

Thanks all.

Is there a reason why open office would not be portable under AmiCygnix?

Is the fan size standard on nemo? If so, I can just buy anything.

Hi, the link to the blog was not a problem, I am talking about the link within the blog that no longer works.

@328gts

Thanks, that is a nice guide, but I am unable to click on the initial link, otherwise I would definitely consider buying that fan.

Is anyone able to provide a link to a suitable fan that offers a quiter solution?

@kas1e
You are as helpful as ever, thank you. I just want to clear something up:

Quote:
2.x is backwards compatible with 1.3? If so, then you can use GL4ES even for things that were designed with 1.3?

Quote:
What about: http://os4depot.net/share/driver/graphics/minigl4gl4es.lha. This seems to include GLUT that is built on GL4ES, so that it is usable, but there is no
link library, only a shared library and there are no include files.
===

At the point in time, I have installed the GL4ES library and followed the readme. All good so far, and I can build and run the examples.

I am just wondering if it is possible to build an old OpenGL 1.3 program that also uses GLUT and have it work on a Polaris X5000.

I can get GLUT from the minigl.lha, but that is build on Warp3D, so no good? Or, I can get GLUT from minigl4gl4es.lha, but that does not include header files and only a shared library.

Thanks for your patience.