We so need an updated browser!

@ChrisH

It doesn't matter. Thesites that complain now actually do use functions not supported by our old webkit. Can't comment on facebook, can't open the chat. Lots of things stopped working recently. Spoofing doesn't appear to help much. I tried most options....

@BSzili

Quote:

I totally agree! You still end up with a non-working/non-compilable webkit.

Getting Odyssey up-to-date is BY FAR the easiest route to a very well functioning browser.

Trying to restart Timberwolf, or port Chrome from scratch is just a shitload more work.

One must not forget all the manyears of work Fab has put into Odyssey to make it a very good Amiga application.

What's needed is a C++11 compiler for AmigaOS and to fix the JS-engine. The latter is the hard and time consuming part.

@Deniil
Quote:
GCC 5.3.0 supports C++11, but we're missing the C++11 standard library. I'd love to see that change. In particular, C++11 has a standardised multi-threading model that would be great to have.

Perhaps solving this should be top priority. More and more projects are using C++11 features (incl. LLVM).


Quote:
AFAIK, there's no way around this. Google Chrome's Blink engine (a Webkit derivative) has the same issue. Firefox's Gecko is probably heading that way too.

There is Netsurf, but they seem to be struggling to keep up with web standards.

Hans

@Hans

Quote:

Lack of developers. The JavaScript engine is big endian compatible though, and highly likely to stay that way.

If you need to be wolf, then it is better to be a king of wolfs, than one of the wolfs.

There is a few Netsurf developers, if there would be five "amiga" devs involved to Netsurf develobment, amiga would be a "king of wolfs".

WebKit devs are not interested Amiga.

Work for HTML5 is started and there is a proper roadmap for Netsurf.

There is a huge possibility that fixing Webkit problems would be endless loop.

@utri007
What does that even mean? If they break the big endian support again, then you fix it again. Where is the endless loop? What you are saying is: don't do anything, just in case it won't work forever. This is simply defeatism.
Bringing the JavaScript engine in NetSurf up to the level that's compatible with Facebook, or Google sites is orders of magnitude more work.

@BSzili

You are right, no doubt for that. But I didn't meant just javascript engine. Endian issues are not issues for WebKit devs anymore, so there is huge risk that other parts get broken for Amiga point of view. That would be endless loop, at least when thinking how diffucult to fix current problem is.

Netsurf is not anywhere near of Odyssey in current form, but it is possible to work how Netsurf is developed and wich direction. That is not possible with WebKit.

@utri007

I'm with BSzili here; patching WebKit to make it big-endian compatible would almost certainly be less work than keeping Netsurf's web engine up-to-date with the latest web standards.

Yes, every WebKit update would require work to support. However, Netsurf's engine would also need continual updates to stay current, and that's after the huge task of bringing it up-to-date is done.

WebKit has enough developers (and corporate backing) to stay current, while Netsurf needs more people working on it.

Hans

@Hans

Quote:

I agree, however there is an advantage that you don't need to find developers that have a vested (or any) interest in big endian hardware, which makes it much easier to find somebody to do the work.

Whereas WebKit fixes need somebody with big endian hardware in order to test fixes, together with it being a much more complicated piece of software to debug.

@BSzili

I mentioned Qt 5 in hope it's port is similar enough how Qt works on Windows and Linux so even if it's still the same Webkit hopefully porting and recompiling would be easier than with OWB.

You hit the nail with your Javascript comment. How on earth somebody can fix the javascript core issues of the Webkit/Odyssey when they don't even know how to compile the whole d**n thing.

@all

This community really have to learn to work together and share heroism/scoring points with others.

Of course, there's all those problems with endianess and lack of C++11 capability, like many have mentioned many times already. So all the work needs to take small steps one at the time to fix all the issues in the end and requires a group of people.

@All
Just few notes about odysseys port:


@TSK
Quote:

Facepalm ? Everyone who want , already works together and share everythng with everyone they need. Fab share his code with everyone, Deadwood share his code with everyone, i share my changes with everyone : everything on github already.

And please, do not show it like problem is "non having step by step guide how build that code". Its already easy enough to build, just run CMAKE with necessary options. You just didn't try, so no need to show it like "if only there will be guide how to compile, i will fix all the problems". If you are, why you still don't try to build it ? I remember only zzd10h and Jaokim trying to start to do something , but fast refuse as it hard and time consuming like hell (see below).

Quote:

No, there is no lack of c++11 compatiblity already (we have necessary gcc already, and SBA after i ask him about implemnt some patches in terms of threading support). And i assure you, that is nothng in compare with "Endian issues".

Quote:

There is already group of people : those ones who work on webkit. If they refuse to worry about endian changes: join and fix them ! Do your small steps, one at time :) You can just build webkit for any big endian machine, for telephone maybe, for macos or whatever, and check how your fixes going. Why you don't do it already ?:) There was even one man (Tobias ?) who seems to trying to deal with JS issues (by building webkit for macos-ppc), so it should be easy for you do fix remaining bugs :)

@All

Just few points about odyssey's building system: forget about native build. Just forget about. cross-compiling is need it for compile everything fast, and problems less. fab for morphos, deadwood for aros and me for os4 - we all use crosscompilers. So, asking anyone "please write me step by step guide how to build it natively, even if natively we didn't have bunch of necessary linux apps working properly" kind of too much.

You can't expect anyone loose their time to make proper ports to os4 of latest version of all those cmakes, autotools, make, bisons, perls, awks, whatever else build system of odyssey use. And please do not say now that "there was CMAKE port recently", or "PERL is working!", i mean situation in whole: there is dependences which is works fine on cross-compiler, and did not on os4. For what need to make ports of that apps, if everything works fine on cross-compiler already, which you just need to setup ?Then go ahead and be our hero: port everything odyssey's build system needs to os4 (list is bigger than i write previously). Its just big fat loosing of time. Just forget native building.

If some of you now will write "i have only os4 machine, i can't setup crosscompiler as i didn't have x86, intel suck, microsoft suck, linux suck" - bad for you. If you can't go and buy x86 hw even just for pure cross-compiler reassons, then it only mean how much you want to compile odyssey. Don't loose time of others with your "i can help if only" posts then.

In end of all, there is deadwood, fab, even me for anyone who want to try to build anything. There is was even some mail-group deadwood made for making it all "coop".

Only few of you trying to compile something , and once realise that there is problems which need to solve (like setup cross-compilers, build new versions of GCC from adtools with enabling experemental threading support for c+11 (i.e. testing, making test cases, asking SBA to implemt patches, etc) , fixing new bugs in new port) - then ops, no more asking for "how to".

I for myself know that i can't deal with JS endian bugs. I can deal with everything else there : with GCC, all those threading c++11 issues (SBA pretty supportive there and helpfull) , with porting all other parts, but i not programmer, and can't deal with JS code. And , there is not only need programmer, but programmer who can : 1) works fast 2) deliver bug free code 3) be in sane mind :)

Is there anyone who want to deal with ? I mean, not in his spare time or "when i will have time if only then" ? I.e. just taking aside all other deals, and concetreate on fixing js bugs till that not will be done, and making it top priority , even overprioroty it over real life issues ? Can't ? Then don't loose our times. Such a sad truth ! :)

@kas1e
Quote:
What are the "necessary options?" You say it has to be built with a cross-compiler (which alone is problematic for me). I have no idea how to tell CMake to use a cross-compiler instead of doing a native build. And yes, I did try to figure it out once with LLVM. My internet searches didn't delivered confusing and contradictory information that simply didn't work.

Don't assume that it's easy just because you find it easy. I've personally never been good with porting stuff from other platforms. Often their complicated build systems have been the killer (whether it's autoconf, CMake or something else).

A simple Compiling-OS4.txt file with basic instructions like "you need a cross-compiler on Linux, these dependencies, and these CMake options" would be very helpful.

Quote:
Good to know there's progress. Last I heard was that we still didn't have a full C++11 std library.

Hans

@THREAD

So moving forward what is the real solution?

1. Netsurf: seems to be to far behind the current modern browsers and has too few people developing it.

2. Odyssey: Has a webkit endianness issue that has no real solution in sight.

3. Timberwolf: Is an option but seems like to much work for anyone to commit to but TENFOURFOX maybe the last minute hero to save the day.

4. Lets just eat pancakes and reminisce about the good old days?

Why doesn't Hyperion think an up to date web browser is an important strategy for marketing their operating system? It perplexes me that one of the Friedens took this on then dumped it, what was Ben Hermans thinking?

As an OS4.1FE user I would gladly accept a pause on AmigaOS updates for features and bug fixes if it meant a modern browser was being implemented.

@Fairdinkem
Quote:
Huh? So somebody already tried to fix it, and declared it's not possible?

@BSzili

I don't think anyone has declared it impossible but from what I have read on all the forums it is a big task to overcome, hence the lack of an update to Odyssey for quite some time now.

I guess it's why I have asked the question what is the solution to move forward.

To use Cmake as cross compiler use this useful tip:

use ccmake and call it with a toolchain file. You can use this command:

ccmake -DCMAKE_TOOLCHAIN_FILE=/usr/local/amiga/bin/cmake.ppc-amigaos ..

With the interactive cmake you can configure the project. It will fail most of time.
To fix everything go in advanced mode and set library paths manually
Click again on configure to see if everything is working, otherwise cmake will show you what is wrong

I've created this toolchain file

# this one is important
SET(CMAKE_SYSTEM_NAME AmigaOS4)
SET(CMAKE_SYSTEM_VERSION 4)
SET(CMAKE_SYSTEM_PROCESSOR "powerpc")
SET(CMAKE_COMMAND /usr/bin/cmake)

SET_PROPERTY(GLOBAL PROPERTY TARGET_SUPPORTS_SHARED_LIBS TRUE)

# specify the cross compiler
SET(CMAKE_C_COMPILER /usr/local/amiga/bin/ppc-amigaos-gcc.exe)
SET(CMAKE_CXX_FLAGS -fPIC)
SET(CMAKE_C_FLAGS -fPIC)
SET(CMAKE_LD_FLAGS -lgcc_eh)
SET(CMAKE_EXE_LINKER_FLAGS "-use-dynld -Wl,--no-undefined")
SET(CMAKE_INSTALL_PREFIX /usr/local/amiga/ppc-amigaos/SDK/local/newlib)
SET(CMAKE_MODULE_LINKER_FLAGS -shared)
SET(CMAKE_SHARED_LINKER_FLAGS -shared)
SET(CMAKE_CXX_COMPILER /usr/local/amiga/bin/ppc-amigaos-g++.exe)

# where is the target environment
SET(CMAKE_FIND_ROOT_PATH /usr/local/amiga/ppc-amigaos/SDK/local/newlib)

# search for programs in the build host directories
SET(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
# for libraries and headers in the target directories
SET(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
SET(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)

ADD_DEFINITIONS("-pipe")
ADD_DEFINITIONS("-use-dynld")
SET( EXTRA_LIBS libstdc++.a libgcc_eh.a )
SET( LIBS ${LIBS} libstdc.a libgcc_eh.a )
SET(CMAKE_C_IMPLICIT_LINK_LIBRARIES "stdc++")
# add imported target
ADD_LIBRARY(imp_stdc STATIC IMPORTED)
# point the imported target at the real file
set_property(TARGET imp_stdc PROPERTY
IMPORTED_LOCATION /usr/local/amiga/ppc-amigaos/lib/newlib/libsdc++.a)

SET( EXTRA_LIBS libgcc_eh.a )
SET( LIBS ${LIBS} libgcc_eh.a )
SET(CMAKE_C_IMPLICIT_LINK_LIBRARIES "gcc_eh")
# add imported target
ADD_LIBRARY(imp_gcc_eh STATIC IMPORTED)
# point the imported target at the real file
set_property(TARGET imp_gcc_eh PROPERTY
IMPORTED_LOCATION /usr/local/amiga/lib/gcc/ppc-amigaos/4.2.4/libgcc_eh.a)

@Fairdinkem
It has nothing to do with the size of the task, it's just that nobody tried to fix it so far. Even if it's a big task, how does "has no real solution" follows from that? People here are hell-bent on creating a new modern browser engine, or porting a new browser from scratch, which is gargantuan compared to fixing what we already have.
The solution was known from the get-go: you need to find a developer who is capable or willing to fix the endianness issues in JavaScriptCore. Other than that, you can skip to 4), and reminisce over pancakes and say goodbye to Google and Facebook :)

@BSzili

I guess you miss understood my perspective on what I perceive as being "no solution in sight."

As you pointed out the issue is known but no one has attempted to resolve it. You see, knowing the issue and having an answer/solution are two different things, and that doesn't mean there is an answer at hand, or that it would be easier than starting from scratch.

To be honest I would prefer Firefox be ported than Odyssey but, hey a modern competent browser no matter the solution is desired. However skipping to eat pancakes and reminisce the good ole days is a delicious way to drown our sorrows I guess.

@Fairdinkem
I see, it must be the language barrier. To me no solution means it can't be solved, not the lack of manpower/interest.
Speaking of pancakes, I just had some great stacked crepes a couple days ago. It was a sign! :D

@all

kas1e, as always, brings reality to people! I love it!

One question: Is it the JS JIT that has endian issues, or the plain interpreter?

We have been living without JIT since the beginning of time, so let's not waste time on that to begin with. I think I heard someone (Fab?) was working on the JIT engine at some point..?