Who's Online |
63 user(s) are online ( 49 user(s) are browsing Forums)
Members: 1
Guests: 62
Georg,
more...
|
|
Headlines |
-
nvme_driver.lha - driver/storage
Mar 26, 2023
-
amiarcadia.lha - emulation/gamesystem
Mar 26, 2023
-
animwebconverter.lha - graphics/misc
Mar 27, 2023
-
vanillara.lha - game/strategy
Mar 25, 2023
-
vanillatd.lha - game/strategy
Mar 25, 2023
-
amitube.lha - video/play
Mar 25, 2023
-
amissl-sdk.lha - development/misc
Mar 23, 2023
-
unext.lha - game/platform
Mar 23, 2023
-
mce.lha - game/utility
Mar 23, 2023
-
amissl.lha - library/misc
Mar 23, 2023
|
|
|
|
Re: getcwd() issue or bad usage ?
|
Posted on: 2022/5/6 8:49
#1
|
Just popping in 
|
@salass00
Ah, it's just that it was the only source of ENAMETOOLONG that I could find.
|
|
|
|
Re: getcwd() issue or bad usage ?
|
Posted on: 2022/5/6 7:42
#2
|
Just popping in 
|
@kas1e It could have something to do with this (from just looking at it for one minute, so this could be very very wrong): In unistd_getcwd:
188 if(__translate_amiga_to_unix_path_name(&path_name,&buffer_nti) != 0)
189 goto out;
In unistd_translatea2u.c:
60 if(len >= (int)sizeof(nti->substitute))
61 {
62 D(("path name '%s' is too long (%ld characters total; maximum is %ld)!",name,len,sizeof(nti->substitute)-1));
63
64 __set_errno(ENAMETOOLONG);
65 goto out;
where nti is:
398 struct name_translation_info
399 {
400 char substitute[MAXPATHLEN];
401 char * original_name;
402 int is_root;
403 };
...and MAXPATHLEN:
include/stdio.h:#define MAXPATHLEN PATH_MAX
...and PATH_MAX:
include/limits.h:#define PATH_MAX 1024
|
|
|
|
Re: gcc 9 and 10
|
Posted on: 2022/5/3 8:53
#4
|
Just popping in 
|
@kas1e FYI: I bumped gcc to the latest release, 11.3.0 ( pending PR and test build).
|
|
|
|
Re: No std::to_string(float) in GCC 11
|
Posted on: 2022/3/18 12:17
#5
|
Just popping in 
|
@Raziel I need to correct myself if I understand ksdhans on Github correctly. The answer to your question is yes :)
|
|
|
|
Re: No std::to_string(float) in GCC 11
|
Posted on: 2022/3/17 19:48
#6
|
Just popping in 
|
@Raziel Quote: Wouldn't that be a problem in newlib? No, the gcc build (libstdc++v3 to be more specific) that he's using is built using clib2. I don't think it's a lot of work to fix this.
|
|
|
|
Re: No std::to_string(float) in GCC 11
|
Posted on: 2022/3/17 9:24
#7
|
Just popping in 
|
I can't say for sure, but it's likely due to something missing in clib2. Can't verify that here though. Does to_string(int) work?
|
|
|
|
Re: How to build AmigaOS4 cross-compiler (Binutils 2.23.2 & GCC 8.3.0) on CYGWIN
|
Posted on: 2022/3/15 20:26
#8
|
Just popping in 
|
@SinanSam460
Just like kas1e says, please don't use the sodero repo. Everything you want is in the SBA repo. The sodero repo might contain things you don't want :)
|
|
|
|
Re: gcc 9 and 10
|
Posted on: 2022/2/19 15:43
#9
|
Just popping in 
|
Yes 2.24 to 2.29 is a big step. Not much inflation in binutils land. They've only reached major version 2 in 30 years :)
Can you forward the mail to rolfkopman <snake like a> gmail <dot> com?
|
|
|
|
Re: gcc 9 and 10
|
Posted on: 2022/2/19 0:43
#10
|
Just popping in 
|
Quote: Ok, will try to understand how to do it all correctly. But how do you split on different patches? I mean, you download adtools, create your local fork in your GitHub acc. Then doing changes, and then how you split on different patches? Doing changes for one patch, commit, made a patch, then again changes, again commit, and next patch? It can be a bit confusing to patch patches and work with two repos at the same time (the adtools repo and the submodule in binutils/repo). But it's a pretty nice setup. Once you've done gild checkout binutils you can start working on the binutils/repo. After the checkout that repo will be in the middle of a merge session. You'll need to fix all conflicts and run git am --continue, then you'll get new conflicts, fix them, repeat until all conflicts are gone. If you look in the commit history when you're done, you'll see that all patches are there as separate commits. If you need to fix additional things after all patches are applied, just create a new commit. When the binutils repo is in good shape, run genpatch to regenerate the patches. If you did additional commits, patches for those will be created in the patches dir belonging to your new binutils version. Then you need to create a commit in the adtools repo containing all the new patches. That's the commit you make a PR out of. Quote: I want to remove morphos and amithlon for 2.24 for now. Are we ok with that? Yes, I see no reason to keep them. Quote: Do we need to make those "warning less" patches or are we just better use CFLAGS options to disable those warnings (as 99.9% they fixed in newer Binutils). Or we better keep those warning-remove patches? I don't think we should hide warnings with CFLAGS. They might be valuable and fixing them isn't much work. Quote: I also have questions about the needs of 0002-Fixed-errors-occuring-with-more-recent-versions-of-t.patch and 0003-Disabled-some-stuff-such-that-68k-vtarget-builds-aga.patch ,if they need it at all now There are some documentation fixes if I remember correctly and I think those are nice to have. Ideally it should be possible build a reasonably polished SDK from adtools IMO. I think we can skip 68k, it will still be possible to build older versions with 68k support using adtools. If we want up to date 68k support in adtools we should look into bebbos work anyway. These are just my opinions though. Sebastian has the final word. Creating a PR is a good way of getting feedback :)
|
|
|
|
Re: gcc 9 and 10
|
Posted on: 2022/2/17 20:25
#11
|
Just popping in 
|
I forgot... Quote: Or do I need to create some private repo for making patches, I think it's best if you just clone sba1/adtools, do your work on a branch there and then create a PR for sba1/adtools when it's done.
|
|
|
|
Re: gcc 9 and 10
|
Posted on: 2022/2/17 20:21
#12
|
Just popping in 
|
Quote: Of course! What i mean before, is patches for binutils (i.e. split the 0001 binutuil's patch on smaller ones). But i think that after removing morphos/amithlon and 68k the main big patch will be small enough to be kept as it is, so no worry about imho Indeed, keep it as it is. I just meant in the long run. Quote: What is more important: can you integrate the patch as I do it, or do all those "FROM/FROM/Subject" at the top is need it?
I mean, how we can now integrate new patches so to have test builds, etc.
Or do I need to create some private repo for making patches, and doing all that "diff --git" stuff? Maybe you have some "step by step" on how you generate patches for GCC ? I'm not sure how you're doing it, but the easiest way is to not explicitly deal with patches using diff and so on, but to do all the work using just git in binutils/repo, resolving conflicts and doing amends. Then when it's done, use genpatch as described in the github page to generate all patches. By doing so you keep all the individual patches in the patch sets (0000 being the biggest one, containing many many patches), including all headers (the FROM [...] part). The headers are valuable, that's the SVN (or CVS?) commit history. Those are needed if we want to split 0000 later on.
|
|
|
|
Re: gcc 9 and 10
|
Posted on: 2022/2/17 19:00
#13
|
Just popping in 
|
Quote: So it compiles! Tested on aos4 and it works ! horrray! Good work! The 0001-patches in binutils, coreutils and gcc ought to be split IMO.
|
|
|
|
Re: gcc 9 and 10
|
Posted on: 2022/2/17 9:25
#14
|
Just popping in 
|
Quote: Imho we can ease our work quite much if we will just remove everything not related to aos4 in the patches for Binutils. What you think ? Like you said, Morphos have their own SDK, Amithlon is long gone. For 68k there's bebbos repo. I think we can go for just the OS4 parts in other words.
|
|
|
|
Re: gcc 9 and 10
|
Posted on: 2022/2/15 20:01
#15
|
Just popping in 
|
@kas1e Quote: Is Binutils can be compiled by "small steps"? I was under the impression it's the same big beast as GCC, and compile everything at once. But if not, then sure, step by step, command by command Sorry, I was a bit fuzzy. What I meant with small steps was going from 1.24 to 1.25 first (just making numbers up here), and then 1.25 to 1.26 and so on, instead of going 1.24 to 1.35. When you compile you need to build the whole shebang.
|
|
|
|
Re: gcc 9 and 10
|
Posted on: 2022/2/15 18:52
#16
|
Just popping in 
|
@kas1e Quote: Btw, as a said note, do you have any idea what needs to be done to port newer Binutils? I mean, what should be done at all which can't be done to have new ones working? Patches? Some 3d party new libs? No new libs. It's "just" a matter of applying the old patches. Most of it is probably straight forward, but there's a risk that some digging is necessary. I would recommend doing it in very small steps, not going directly from what we have now to the bleeding edge. Going slow is likely the fastest way of doing it.
|
|
|
|
Re: gcc 9 and 10
|
Posted on: 2022/2/15 9:58
#17
|
Just popping in 
|
@walkero Quote: Is there a way to disable dlopen()? Or should we do something else to overcome the error in compiling process? My guess is that plugin support relies on dlopen. Since clib2 (and newlib?) implements dlopen it's probably a configuration problem. There could of course also be something missing or broken in clib2.
|
|
|
|
Re: gcc 9 and 10
|
Posted on: 2022/2/14 22:36
#18
|
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
#19
|
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
#20
|
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)
|
|
|
|