Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
190 user(s) are online (101 user(s) are browsing Forums)

Members: 2
Guests: 188

Hypex, Murakami, more...

Headlines

Forum Index


Board index » All Posts (sTix)




Re: gcc 9 and 10
Just popping in
Just popping in


@walkero
Quote:
Maybe it has to do with my compiling environment. I will investigate more.


I'm not in front of a proper machine right now so I can't do any real digging but it looks like there could be a dlopen() problem. In the configure script in binutils/bfd you'll see that enable_dlopen isn't set if you search for the error message you showed.

If you look in native-build/binutils-native-something/bfd you should find a config.log. That's the autotools output from the configure step. In that one you might find some dlopen related clues.

Go to top


Re: gcc 9 and 10
Just popping in
Just popping in


@kas1e

I agree, for compilers localization isn't worth the effort. Since it's GNU, maybe it depends on glibc, gettext and whatnot. Just guessing though.

Go to top


Re: gcc 9 and 10
Just popping in
Just popping in


@kas1e

Interesting. My guess is that it's due to this:

Quote:
--enable-plugin is necessary for gcc-ar, gcc-nm and gcc-ranlib to work, which
must be used with GCC 4.9 for LTO to work.


From the binutils Makefile, --enable-plugin isn't set in the native target (and maybe there's a reason for that):
Quote:

18 cross:
19 mkdir -p $(CROSS_BUILD_DIR)
20 cd $(CROSS_BUILD_DIR); CFLAGS="-Wno-switch -Wno-unused -Wno-implicit-fallthrough -Wno-cast-function-type" $(REAL_SRC_DIR)/configure \
21 --enable-plugins \
22 --target=ppc-amigaos \
23 --prefix=$(PREFIX)
24 make -C $(CROSS_BUILD_DIR)
25
26 native:
27 mkdir -p $(NATIVE_BUILD_DIR)
28 cd $(NATIVE_BUILD_DIR); LDFLAGS="-lunix" CFLAGS="-Wno-switch -Wno-unused -Wno-implicit-fallthrough -Wno-cast-function-type" $(REAL_SRC_DIR)/
29 --target=ppc-amigaos \
30 --host=ppc-amigaos \
31 --disable-nls \
32 --prefix=/gcc
33 make -C $(NATIVE_BUILD_DIR)

Go to top


Re: GNU Make and VPATH
Just popping in
Just popping in


@walkero

It's pretty simple to reproduce.

Create a directory structure like this:

Quote:
7.RAM Disk:> list
src Dir ----rwed Today 20:48:13
build Dir ----rwed Today 20:48:33


In 'src' create something like this:

Quote:
7.RAM Disk:> type src/input
test


In 'build' create a Makefile like this:

Quote:
7.RAM Disk:> type build/Makefile
VPATH := ../src

output: input
cat $< > $@


Then if you use make 3.81 you'll get this, which is what you would expect:

Quote:
7.RAM Disk:build> make
cat ../src/input > output
7.RAM Disk:build> type output
test


But if you use 3.82 you get this:

Quote:
7.RAM Disk:build> make382
make382: *** No rule to make target `input', needed by `output'. Stop.


With 3.82 'input' can't be found despite VPATH being set.




Go to top


Re: GNU Make and VPATH
Just popping in
Just popping in


@trgswe

Yes, vpath is more specific, using pattern rules, but the result is the same; it's ignored by 3.82 but works with 3.81.

Go to top


Re: GNU Make and VPATH
Just popping in
Just popping in


@trgswe

I tried both I'm afraid. But I just noticed that 3.81 included in the latest SDK works the way it should. Looks like something broke when going from 3.81 to 3.82.

Go to top


GNU Make and VPATH
Just popping in
Just popping in


Has anyone else run into problems using VPATH when building with the GNU make on OS4Depot (make-bin.lha uploaded by Steven Solie)?

To me it seems like VPATH is totally ignored. Both make and gmake behave in the same way.

Go to top


Re: x5000 benchmarks / speed up
Just popping in
Just popping in


@geennaam
Thanks, extremely valuable info. I got significant performance gains for barely no money at all (in Amiga terms).

Before (HX316C10FR/4)
Quote:
READ32: 656 MB/Sec
READ64: 1225 MB/Sec
WRITE32: 860 MB/Sec
WRITE64: 864 MB/Sec


After (KF318C10BBK2/8):
Quote:
READ32: 698 MB/Sec
READ64: 1270 MB/Sec
WRITE32: 1537 MB/Sec
WRITE64: 1542 MB/Sec




Go to top


Re: GDB
Just popping in
Just popping in


@kas1e

Sounds good! Regarding #3: I always liked cgdb which is also curses based. I don't consider #3 to be a must though.

Go to top


Re: Is gprof ever works on os4 ? It is! And can be still!
Just popping in
Just popping in


@joerg
Quote:
Most users of course don't understand the extreme consequences of unusable or missing development tools, but expect to get something like FireFox or Chromium to get ported to AmigaOS, which is nearly impossible without the development and bug fixing tools


Agree. Missing tools make me more nervous than missing applications.

Go to top


Re: gcc 9 and 10
Just popping in
Just popping in


@kas1e
Quote:
I mean, did i understand right, that sba/adtools is the latest public stuff we got in terms of gcc/binutils


Correct, Sebastian is very quick to respond to PR:s so sba1/adtools is always up to date.

Quote:
but when it comes to clib2, then what we have on the sba/adtools are outdated stuff, and we can not need to rely on it


No, when you build adtools you get the latest stable from my clib2 fork (it's unfortunate that it exists at all, but it is what it is, you know the history :)).

If you look in 'native-build/makefile' in adtools you'll find the following lines:

Quote:

CLIB2_URL=https://github.com/sodero/clib2
CLIB2_SHA1=18ff2b535a59fff8aa5237c08fe32551cb0bfe45


The SHA1 refers to HEAD of the 'main' branch in sodero/clib2 (not 'master', that's full of experiments).

Summary:
- sba1/adtools is always up to date.
- PR:s for clib2 should be made for the 'main' branch in sodero/clib2.
- Once the clib2 PR is merged another PR with an updated CLIB2_SHA1 should be made for 'master' in sba1/adtools.

Quote:
ps. Is your mail that ola.soder at axis current one?

Yes, but I tend to not read e-mails during the weekends, too much work related things pop up.

Go to top


Re: Is gprof ever works on os4 ? It is! And can be still!
Just popping in
Just popping in


@kas1e
Quote:
Seems that we found a developer, so once it will be closed to pay off, I will write there. As i say i will pay from my own, but if some of you will cover a little bit that will be good as well :)

Great, I'll chip in as well.

Go to top


Re: Nemo
Just popping in
Just popping in


@Raziel

I don't think the ancient Greeks would agree that that's the original Nemo :)

Go to top


Re: Is gprof ever works on os4 ? It is! And can be still!
Just popping in
Just popping in


@kas1e
Quote:
Right, so will try to find out someone who can do so. But probably it's only Corto, Thomas, Salas00, or SBA1. We can start from 1000$, and I can cover it by myself in general if we will find someone.


Sounds good, but let's split the costs, there are probably others that would like to contribute as well.

Go to top


Re: Is gprof ever works on os4 ? It is! And can be still!
Just popping in
Just popping in


@kas1e
Lots of good info there.
Quote:
For first, Thomas thinks that 0x01000000 switch was necessary for the shared objects support since these did add a .plt section, potentially in front of the .text (which means 0 as text base address was no longer working). So that kind of explains it.


Sounds reasonable.

Quote:
Then, Frank says that yes, the 0x01000000 is arbitrarily chosen and has no real meaning, as the executables will be relocated to their real load address in any case. He also thinks that we have a bug with all that 0x00000000 because even Unix ELF executables will always have a non-null start address as well.

I'm not sure that we can compare with Unix ELF executables that very often aren't PIE (or at least haven't been in the past). And if not relocated, it's probably wise to avoid an address of 0.

About fixing it, it's better if someone with a working performance monitor does it

I'm also willing to donate.


Go to top


Re: Is gprof ever works on os4 ? It is! And can be still!
Just popping in
Just popping in


@kas1e

Very interesting, thanks for sharing. If clib2 works with 0x01000000 then we have one problem less and learnt something along the way :)

Go to top


Re: Is gprof ever works on os4 ? It is! And can be still!
Just popping in
Just popping in


@kas1e

The mystery 0 pops up everywhere :) Why 'needs to be' and why no 'Better idea?'.

Go to top


Re: Is gprof ever works on os4 ? It is! And can be still!
Just popping in
Just popping in


@kas1e
Quote:
Works too ! I just do that:
ppc-amigaos-gcc -mcrt=clib2 -Ttext=0x0000000 -pg -gstabs test_gprof.c test_gprof_new.c -o test_gprof_clib2 -lprofile


And it works!


Brilliant. I guess you could ask the original authors if there's a good reason for having text at 0x01000000 and not at 0x00000000? Are the Friedens on a beta-tester mailing list of some sort?

But the output from 'nm file_built_with_normal_ld' seems identical to 'nm file_built_with_patched_ld'?


Go to top


Re: Is gprof ever works on os4 ? It is! And can be still!
Just popping in
Just popping in


@kas1e

Very nice. What happens if you build with the unpatched ld and add '-Ttext=0x0000000' when building?

What is the output from the following 3 commands:

> nm file_built_with_patched_ld
> nm file_built_with_normal_ld
> nm file_built_with_normal_ld_plus_text_option

Go to top


Re: Introducing Profyler
Just popping in
Just popping in


@IamSONIC
Quote:
Maybe sTix can provide some more profound information here


I haven't done any benchmarking I'm afraid, but on average, the newest gcc tends to be the fastest gcc :)

Go to top



TopTop
« 1 (2) 3 4 5 ... 12 »




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project