Work on Qt 5.8 has begun :)

@alfkil
dunno if it best, but in e-uae code found this:

https://sourceforge.net/p/euaeppcjit/c ... trunk/src/include/sleep.h

@kas1e

Super!

It turns out, that ::usleep works just fine, because there are never requests for any time interval less than a microsecond. :)

---

Now: How to emulate mmap and munmap??

@alkfil
That probably require some rewriting of code, or at moment just return -1. See here for more info:
http://forum.hyperion-entertainment.b ... hp?f=26&t=3418&hilit=mmap

Will be cool to have some mmap.c which we just can include in all the stuff later, same cool as fork.c :)

@alfkil

Quote:

Waiting for intervals less than 1 microsecond would need special handling on AmigaOS anyway, as the internal clock works in microseconds you'd need to put something together with the EClock.

Quote:

This might be sufficient: https://github.com/chris-y/libgit2/blob/development/src/amiga/map.c

@Chris

Thanks!

What do these mean??!



??

@alfkil
It mean that real porting starts now ! :)

@kas1e

It was because of .symver. Easy to fix .

http://stackoverflow.com/questions/31 ... node-not-found-for-symbol

There seems to be a problem with GCC 5.3.0. When linking c++ executables with -use-dynld, you will get underfined references - apparently from the fact, that it links agains c libraries and not c++ (it needs to link against libstdc++.so, but fails to do so).

Is there any fix for this??!

@alfkil

Again, a problem with the directory structure of the unofficial GCC 5.3.0 distro.

Files in
Quote:

need to be copied to
Quote:

Thank you!

@alfkil

Make sure you're feeding back these problems to the repo:
https://github.com/sba1/adtools

@Chris

I will. And probably yet more to come.....



So close, and yet so far.... ;-/

Is there perhaps a missing libatomic in the unofficial GCC 5.3.0?

Sorry, probably not a mistake, since why would you support 64 bit atomic operations on a 32 bit platform.....? ;)

---
First app linked to libQt5Core.so.5:

Nice to see progress :)

@alfkil Quote:
I'm definitely no expert, but it's not uncommon to use 64-bit numbers on a 32-bit platform. So it seems perfectly reasonable (to me) that someone might want atomic 64-bit operations, particularly if the code was ported from a 64-bit platform.

I have no idea if it's possible to support 64-bit atomic operations on our PPC processors, but I don't see why not (it just requires that 64-bit numbers can be written atomically, which a 32-bit CPU might easily support, it the designer's wanted it to).

But maybe I am missing something really obvious. I'm just an arm-chair programmer, as far as atomic stuff is concerned...

@ChrisH

I think it is 'supposed' to be supported. But it is hard to pin down, where something has been left out. Commenting out the 64 bit atomic functions in Qt makes it at least compile. Other than that, I think that parts of the c++ library has to be ported, before it can be supported on our os. But anyway, I am as much in a wheelchair as you regarding those issues ;).

---
Now, has anyone got a good overview over the different select/waitselect possibilities in newlib/bsdsocket? I remember opting for the bsdsocket/WaitSelect() in the old Qt4 port, but why exactly did I do that? Was it simply to be able to 'select' for AmigaOS signals, or was there perhaps something else involved as well? It could be really cool, if someone could pin out exactly what the differences and drawbacks of each possibility is.

@alfkil

WaitSelect() and waitselect() enable you to wait on AmigaOS signals and socket fds at the same time. If you need to do that, then that's definitely what you should use.

Don't mix bsdsocket.library and newlib calls - either use WaitSelect along with bsdsocket, or waitselect with the newlib equivalent functions (I'd advise to use newlib unless you need any of the more quirky bsdsocket features that newlib doesn't expose)

@Chris

Ah, that was exactly the kind of response, I was looking for. :)

So, for some reason, I chose bsdsocket/WaitSelect in the Qt4 port, but I cannot quite remember the exact reason. I would much rather use waitselect (newlib), so I have got to figure out, what the exact reason was. Any guesses?

@thread:

There is an issue with datagrams. It appears, that Qt5 wants to use the cmsghdr structure to get different kinds of info about a package. It uses several macros, that are not defined in newlibs sys/socket.h. For instance

CMSG_SPACE

and

CMSG_LEN

The definition of CMSG_DATA differs rom its Linux counterparts, so I am guessing, that the whole section of definitions are not transferable. The question is: Should I just disable this part of the code, or is there any sence in trying to recover some of its functionalities while abandoning others? I am not too well informed about sockets, so any advise is going to be helpful.
---
BTW in that part of the includes (sys/socket.h), there is a reference to a macro 'ALIGN()' that does not exist in any of the SDK includes.

Just curious, with making a newer version of QT work on Amiga OS NG systems, what if any newer QT based apps will be expected to work for us?

Is there a newer better QT based Web Browser as an example? One that can offer us a better web experience? Say play youtube html videos within the browser at normal speeds?

Scribus DTP app? That is QT based. I see they have a Haiku version too.

Stuff like that I wonder?

TJ