Apologies, all, for being silent for a few weeks. This is an insanely busy time for me in all my businesses. None are retail/X-mas affected, per-se!

I'll readily / happily edit my instructions if an inadvertent/unnecessary "sudo" needs to be corrected somewhere.

Can someone let me know if/what changes I may need to make to the original post?

@stonecracker


post #1 from stonecracker:

export PATH=$PATH:~/adtools/bin:/usr/local/amiga/adtools/bin

DStastny @ post #6

export PATH=$PATH:~/adtools/bin:/usr/local/amiga/adtools-ppc-uwin-20170623-404/bin
(which in my case should be: export PATH=$PATH:~/adtools/bin:/usr/local/amiga/adtools-ppc-uwin64-20170623-404/bin)


In my now working installation i have only this in bashrc:

export PATH=$PATH:~/adtools/bin:/usr/local/amiga/adtools-ppc-uwin64-20170623-404/bin

@AmigaBlitter

With the symlink in place, export PATH=$PATH:~/adtools/bin is probably all you need. Although there's that rare occasion when a configure script can't find something in /SDK/local/newlib/bin even when you use --prefix, so that can be added too.

I _think_ the culprit was an unnecessary "sudo" or maybe a missing chown/chgrp command somewhere that caused some of the simple but irritating permissions problems?

This problem doesn't show up on Cygwin, as Cygwin doesn't have sudo or root users.

But UWin, it would/could be a problem. Can someone point me to where the problem might be in my originating post? I'm quickly reviewing that post, and just don't see where the problem might be...

@stonecracker

Thank you for your tutorial. installed on Cygwin64, all seems fine !

Glad to hear. I _think_ all is working fine with my instructions, as seen in the originating/but heavily edited, original post. UWin, and Cygwin. Unless someone tells me otherwise?

@stonecracker

Hello,

i bring up again this thread cause i had a severe Windows 10 failure and lost my uwin installation.

i tried already to reinstall everything as before, having all the steps done previously written in a document and proceeded carefully with copy and paste to ensure no errors occoured during the setup phase.

Unfortunately, the make commands fails with some errors and i can't complete the installation of the uwin environment.

At first i tought that something changed in Windows fall creator update and i figured out that only the lxss environment path has been modified as default. I think that this should not have any impact in the cross compiler setup procedure.

I would like to address this problem definitively, so i ask you (again) for help.

Thank you.

@AmigaBlitter

Stonecracker hasn't logged in in a while. So, you might want to explain where you're getting stuck here. Maybe others can help.

Hans

It looks like the instructions in post #1 jump straight into building gcc before building binutils. AmigaBlitter's screenshots he sent to me show it failed when looking for ppc-amigaos-ar in native-build/root-cross/bin/. I had a look at the Makefile in native-build and the gcc-cross target, and I don't see where binutils is made for that target.

So I suggest going into native-build, and running "make binutils-install". Then building gcc should work afterwards. Not tested, but this is my best guess.

Edit: The Makefile from when this thread was first made, used to build binutils for the gcc-cross target, but no longer does. 18 days ago a change was made (893c02b) that meant binutils would no longer be built automatically if using the gcc-cross target. Previously, gcc-cross would call clib2-cross which would call xgcc-done which called binutils-cross.

Edit 2: That wasn't right either. See salass00's post below.

@MickJT

Changing the following two lines in native-build/makefile fixed the problem with wrong path being used for ppc-amigaos-ar for me:



Eventually it failed again because it wasn't able to find clib2 files in $(CROSS_PREFIX)/ppc-amigaos/SDK/clib2 so I copied them there manually from native-build/downloads/clib2/ and ran make again, and it finished without errors building the gcc 6.4.0 cross compiler.

I missed that CLIB2_CROSS_DONE_DEPENDENCY line.

So, the makefile still builds it but doesn't always take into account modified variables.

Thank you all for the informations.

Will try to apply asap.

Making a few more changes to the makefile I was able to build a gcc 8.0.1 cross compiler without any errors.

Ok. I just went through the steps myself. I'm naming the CROSS_PREFIX directory as adtools-ppc-uwin64-20180416-480 (I used make print-dist-version to find the date/revision). After doing all the gild stuff, I went into native-build and ran:

make gcc-cross CROSS_PREFIX=/usr/local/amiga/adtools-ppc-uwin64-20180416-480

When I got to the error, I simply did:

ln -s /usr/local/amiga/adtools-ppc-uwin64-20180416-480 root-cross

So that makes a root-cross symlink inside of native-build that points to /usr/local/amiga/adtools-ppc-uwin64-20180416-480

Then I ran the "make" line again, and it continued on fine. Sorry to say salass00, your method is the hard way, even if it is more "proper" :) I'm sure Sebastian Bauer will fix CROSS_PREFIX to work properly again soon anyway (basically the same as what you did).

Edit: It was fixed on May 4th.

Well, Amigans, my apologies for not logging in for several months. As predicted, I've been stupid-swamped since November 2017.

Where'd the bouncing boing-ball land on this for the new GCC 8 build?

I'll happily update my original post, again, to avoid people having to read all the comments/chain.

@stonecracker

I just checked, and GCC 8 has been released for AmigaOS 4.x.

Also, work has been done to get C++11 threading working. I doubt that's released yet (it's considered experimental) and I haven't had a chance to check it out, either. However, it's a good step forward.

Hans

@Hans

Is there a "user" release yet?

One where i can download and install the whole package instead of cherry picking it out of the adtools stuff?

@Raziel

You can download it from https://dl.bintray.com/sba1/adtools-native/ and it can be installed next to your old GCC, just change the assign in SDK:S/gcc-startup to test.

Tried few things like thread, async, atomic and mutex. They seem to compile OK. Needs switch -athread=native.

Another of my lengthy, sporadic posts...

@Hans

That's fantastic news. As we've noted on this site (many other threads), and on countless other posts on the Internet, the single biggest technical hurdle, by far, to getting fantastic/modern/everyday-useful software ported to OS4 is the lack of a complete C++ 11 Standard Library.

In all my discussions with the Amigan-powers-that-be, the biggest hurdle to that, in turn, is some easy, rote, but somewhat time consuming, pthread wrapper calls being hammered in to the OS4 port of GNU c++stdlib.

When I see him next, I'll ask Solie if he's had anything to do with actually implementing the threading he/I have been talking about at the OS layer -- his work at the OS level, plus C++stdlib work at the GCC level, should massively assist in unlocking an incredible amount of porting options for all the software any modern Amigan needs/wants.

If you add a complete OS4-port of c++stdlib to a complete/usable OS4 SDK that can, in turn, be used natively or (especially) from a cross-compiling dev setup on a Windows machine.....well, the options keep opening up waaaaay further.

I'm glad _someone_ took some of the charge and started some work on the C++ Std. Lib. stuff. A little disappointed in myself that it wasn't me... But alas, such is my insane schedule.

This summer, I can hopefully tackle updating this thread's particular instructions for cross-compiling (from Cygwin with GCC8); and also hopefully confirm / help shore-up the C++ Standard Library stuff, whether for native-OS4 developers or for cross-compiler/Cygwin OS4 devs.

Before Christmas, I'm also hoping to free-up enough time to help with the _much_ bigger effort in rounding-out a bunch of really important/really big, but absent/incomplete OS4 SDK work that's sorely needed, again, whether for native- or cross-compiling OS4 developers.

What do I mean by "absent/incomplete SDK" work? Well, not saying I can actually achieve this by Xmas -- and it's amazing to me that _any_ OS4 software has been successfully built without this -- but _one_ example of what's missing from the SDK is a native, or UAE-emulated, or QEMU-emulated, OS4 system that can actually run GDB Server ... so that OS4 developers can _finally_ do what almost every O/S offers: a simple remote debugging session, to make single-step source-level debugging not only possible, but in fact, easy.

If the people tackling the C++ 11 Std. Lib. work can finish that work, and I can free enough time to help with the SDK / Windows cross-compiling SDK, we have a real shot at getting some serious software ported.

Think, TenFourFox for MacOSX PPC being ported to OS4 (TenFourFox is a continuously-maintained Firefox port to PPC complete with full HTML5 support and JIT'd JavaScript interpreter and Firefox extensions).

Why do I mention all of this here?

Think about having all of this porting infrastructure available, for free, to port the hundreds of code bases out there in the world that are otherwise inaccessible to OS4; all running on some Windows-based developer's machine with that developer getting up/running from scratch inside of an hour or so.

THAT, is a game changer.

THAT (I believe) means 2 massive barriers can be eliminated to help get monster volumes of code ported to OS4: 1) the underlying code infrastructure (GCC8 with c++stdlib) and 2) the developers (usually, running Windows dev tools and _not_ wanting to spend a month getting going).


Only 3 road blocks, in turn, that I can see to getting to _that_ state...

1) C++11 Standard Library,

2) a Windows-hosted OS4 emulator capable of supporting remote debugging inside it (plus some other SDK stuff), and

3) an OS4 SDK that can used inside a Windows/Cygwin cross-compiling environment.

Someone else looks to be tackling #1; hopefully, they'll need only a small amount of help and Solie's work at the OS level (which I think he's able/willing to do -- but don't quote me on that). Anyone who can help, I'm sure, will have a welcome reception to do so. I just haven't freed the time.


I've already finished #3; with only minor updates needed to accommodate GCC8.


That leaves #2. Big task, but I think doable. Interestingly, this one isn't the exclusive realm of software developers -- Windows / OS4 power users can help a bunch.

I've discussed much of this with one of the adtools/SDK maintainers (Krystian) and I'm happy to direct folks on the missing chunks that they might be able help with (ex: getting OS4 to run in QEMU or getting some low-level serial GDB traffic working in UAE).

@Capehill

It doesn't seem "normal" to have files in bin/ (23.06.2018 release) which have pipes in names, are zero bytes and obviously not executable...

Seems the daily builds are broken