Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
28 user(s) are online (25 user(s) are browsing Forums)

Members: 0
Guests: 28

more...

Headlines

Forum Index


Board index » All Posts (sTix)




Re: getcwd() issue or bad usage ?
Just popping in
Just popping in


@salass00

Ah, it's just that it was the only source of ENAMETOOLONG that I could find.

Go to top


Re: getcwd() issue or bad usage ?
Just popping in
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

Go to top


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


@Raziel

Nice!

@trgswe

It looks like it will take a couple of months before gcc 12 is released: https://gcc.gnu.org/develop.html#timeline

Go to top


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


@kas1e

FYI: I bumped gcc to the latest release, 11.3.0 (pending PR and test build).

Go to top


Re: No std::to_string(float) in GCC 11
Just popping in
Just popping in


@Raziel
I need to correct myself if I understand ksdhans on Github correctly. The answer to your question is yes :)

Go to top


Re: No std::to_string(float) in GCC 11
Just popping in
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.

Go to top


Re: No std::to_string(float) in GCC 11
Just popping in
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?

Go to top


Re: How to build AmigaOS4 cross-compiler (Binutils 2.23.2 & GCC 8.3.0) on CYGWIN
Just popping in
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 :)

Go to top


Re: gcc 9 and 10
Just popping in
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?

Go to top


Re: gcc 9 and 10
Just popping in
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 :)

Go to top


Re: gcc 9 and 10
Just popping in
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.

Go to top


Re: gcc 9 and 10
Just popping in
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.

Go to top


Re: gcc 9 and 10
Just popping in
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.

Go to top


Re: gcc 9 and 10
Just popping in
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.

Go to top


Re: gcc 9 and 10
Just popping in
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.

Go to top


Re: gcc 9 and 10
Just popping in
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.

Go to top


Re: gcc 9 and 10
Just popping in
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.

Go to top


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



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




Powered by XOOPS 2.0 © 2001-2016 The XOOPS Project