Who's Online |
190 user(s) are online ( 101 user(s) are browsing Forums)
Members: 2
Guests: 188
Hypex, Murakami,
more...
|
|
Headlines |
-
thumbnailmaker.lha - video/misc
Apr 26, 2024
-
mce.lha - game/utility
Apr 23, 2024
-
theme_list.lha - utility/misc
Apr 23, 2024
-
faac.lha - audio/convert
Apr 22, 2024
-
faad2.lha - audio/convert
Apr 22, 2024
-
seq.lha - audio/misc
Apr 22, 2024
-
libfaac.lha - development/library/audio
Apr 22, 2024
-
libfaad.lha - development/library/audio
Apr 22, 2024
-
image2pdf.lha - utility/text/convert
Apr 22, 2024
-
libharfbuzz.lha - development/library/graphics
Apr 20, 2024
|
|
|
|
Re: gcc 9 and 10
|
Posted on: 2022/2/14 22:36
#21
|
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.
|
|
|
|
Re: gcc 9 and 10
|
Posted on: 2022/2/14 19:31
#22
|
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.
|
|
|
|
Re: gcc 9 and 10
|
Posted on: 2022/2/14 15:35
#23
|
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)
|
|
|
|
Re: GNU Make and VPATH
|
Posted on: 2022/2/11 20:00
#24
|
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.
|
|
|
|
Re: GNU Make and VPATH
|
Posted on: 2022/2/11 14:45
#25
|
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.
|
|
|
|
Re: GNU Make and VPATH
|
Posted on: 2022/2/10 21:10
#26
|
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.
|
|
|
|
GNU Make and VPATH
|
Posted on: 2022/2/10 20:53
#27
|
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.
|
|
|
|
Re: x5000 benchmarks / speed up
|
Posted on: 2022/2/7 17:33
#28
|
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
|
|
|
|
Re: GDB
|
Posted on: 2022/2/7 10:43
#29
|
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.
|
|
|
|
Re: Is gprof ever works on os4 ? It is! And can be still!
|
Posted on: 2022/2/4 22:12
#30
|
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.
|
|
|
|
Re: gcc 9 and 10
|
Posted on: 2022/2/4 21:37
#31
|
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.
|
|
|
|
Re: Is gprof ever works on os4 ? It is! And can be still!
|
Posted on: 2022/2/3 7:45
#32
|
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.
|
|
|
|
Re: Nemo
|
Posted on: 2022/1/27 8:30
#33
|
Just popping in
|
@Raziel
I don't think the ancient Greeks would agree that that's the original Nemo :)
|
|
|
|
Re: Is gprof ever works on os4 ? It is! And can be still!
|
Posted on: 2022/1/25 18:58
#34
|
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.
|
|
|
|
Re: Is gprof ever works on os4 ? It is! And can be still!
|
Posted on: 2022/1/25 11:37
#35
|
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.
|
|
|
|
Re: Is gprof ever works on os4 ? It is! And can be still!
|
Posted on: 2022/1/23 21:31
#36
|
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 :)
|
|
|
|
Re: Is gprof ever works on os4 ? It is! And can be still!
|
Posted on: 2022/1/23 19:56
#37
|
Just popping in
|
@kas1e
The mystery 0 pops up everywhere :) Why 'needs to be' and why no 'Better idea?'.
|
|
|
|
Re: Is gprof ever works on os4 ? It is! And can be still!
|
Posted on: 2022/1/22 22:36
#38
|
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'?
|
|
|
|
Re: Is gprof ever works on os4 ? It is! And can be still!
|
Posted on: 2022/1/22 22:05
#39
|
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
|
|
|
|
Re: Introducing Profyler
|
Posted on: 2022/1/22 20:26
#40
|
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 :)
|
|
|
|