-static-libgcc is not working #98
Comments
|
The second part (When used with clib2 and shared objects dl* functions cause a crash because the .so files try to open newlib in some way and of course everything crash) sounds like it might be the same crash I'm getting with newlib (but I might ge completely wrong, of course) |
|
I have the same problem with newlib too.. on address 4. Which compiler are you using? |
|
GCC 5.4.0 upto GCC 10.1.0 all produce the same crash with shared binaries for me. But of course I dont really know, it might be something completely different. |
|
i had same problem in the past and usually i remove libgcc.so and use the static one. This is the only solution. However dl* function with the actual clib2 doesn't work. Maybe they had worked with old Exec and gcc version. but no more. I've found a workaround in my actual clib2 version but i have some problems and i don't like the fix. I'm trying to patch gcc and clib2 to work like newlib. But is hard.. |
|
Indeed, it is very unlikely that clib2.so work. I don't remember a
change that addressed that and I also never tested it. It also makes
sense to use the thread-safe variant. It probably should be the default
anyway.
|
|
mmm.. no. clib2.so will not work. It doesn't exists. But creating .so files and load them with dlopen/dlsym should. The problem is that clib2 is linking crtbegin when creating .so files with -shared flags and this cause problems. I've created shcrtbegin that contains __shlib_call_constructors and __shlib_call_destructors are used by InitSHLibs (at least autodocs says so). But i'm trying to patch amigaos.h file under rs6000 but is hard. Because while with newlib there is only a library it use "shared" and "!shared" statements. With clib2 there is multi lib and also strange cases with soft-float.. |
|
Am 2021-01-30 19:02, schrieb Papersoft.it:
mmm.. no. clib2.so will not work. It doesn't exists.
I meant .so generated with the clib2 flavor. I think I have disabled the
generation of the clib2.so, this as it IMO makes no sense at the current
stage of development.
But creating .so
files and load them with dlopen/dlsym should. The problem is that
clib2 is linking crtbegin when creating .so files with -shared flags
and this cause problems. I've created shcrtbegin that contains
__shlib_call_constructors and __shlib_call_destructors are used by
InitSHLibs (at least autodocs says so). But i'm trying to patch
amigaos.h file under rs6000 but is hard. Because while with newlib
there is only a library it use "shared" and "!shared" statements. With
clib2 there is multi lib and also strange cases with soft-float..
As said, if clib2 so is wanted, then it makes sense to support only one
clib2 variant and this should be the thread-safe variant, because the
variants are not necessarily compatible to one another, and the
thread-safe is variant is probably a good common base. But even then, it
is complicated. A .so created with a clib2 favor is unlikely to work
with a .so created with newlib and I don't think that there are any
means to distinguish them yet. Providing clib2 variants of .so is thus
very confusing. Of course, this hold for both really dynamically loaded
objects (via dlopen()) and thus that are linked by the runtime at
startup time.
Honestly, I would try to avoid the usage of clib2 .so in its current
form as much as possible. I would discourage the usgae of .so
altogether.
|
Big projects will soon start to be only available through cross-compiling then I'm afraid :-( |
|
Not only. For example the current (ancient) version of GemRB use plugins as .so files and it works without any problem. The problem is not in the .so files but how they are loaded. I've found the problem in clib2 for example and i'm trying to fix them. |
|
Nice. I'll stand by for testing |
|
i don't know if it is related to newlib (and however i can't fix it since i'm not an os4 dev). However i have a small test case that show the problem. When i've something to test i'll tell you |
|
Am 2021-01-31 11:49, schrieb Papersoft.it:
Not only. For example the current (ancient) version of GemRB use
plugins as .so files and it works without any problem. The problem is
not in the .so files but how they are loaded. I've found the problem
in clib2 for example and i'm trying to fix them.
However this issue is not related to .so files. This issue is related
to a flag that is not working.
What I wanted to express is that you just generally cannot mix all the
variats of .so files as you cannot have a single binary that supports
clib2 and newlib either (it may work for few that are not using c
runtime features though), and it is currently hard to track what variant
of .so uses what flavour, if I'm not wrong. If you keep the files
isolated for a single distribution, then it should in principle work
(maybe after fixing the flag issue you mentioned and/or other problems),
but if you don't share the objects accross programs the advantage of
using them nearly is zero (dlopen and related functions still have some
advantages though if you want to keep the runtime image smaller and
don't always need all code "linked" into the memory image and need some
sort of plugin interface). But it must be ensured that the entirety of
the program must be compiled with the very same set of compiler options
that affect the flavour.
On top of that, clib2 is originally a static library. I'm not sure how
stable the "public" interfaces is. There are few cases that prevents a
full C++11 or later support of clib2 applications, i.e., some structs
need to be extended (IIRC regarding stat). Mixing both versions of clib2
will lead to crashes. What I think we lack is a system to track and
detect the situations.
|
|
Wait. I don't want a shared clib2. Clib2 can be static. And for clib2 i mean its libraries. lc lunix and lm. |
|
Am 2021-01-31 16:38, schrieb Papersoft.it:
Wait. I don't want a shared clib2. Clib2 can be static. And for clib2
i mean its libraries. lc lunix and lm.
But this doesn't means that i cannot generate a .so file and load it
via dlopen.
Well, the .so's that you will open with dlopen() need also to be linked
against a clib. So if you want that to be clib2 both the program and the
.so file must be linked against clib2 (whether it is statically or
dynamically doesn't matter that much here, though linking to it as a
shared object makes more sense here as this abstracts the internal
details of the implementation). And the clib2s used for linking need to
be compatible to one another. E.g., if the FILE struct will differ in
one clib2, then it cannot work, because each clib2 expects its struct
FILE (I'm not claiming that such a change will happenn frequently, but
there are few case where it makes sense to improve the structs in
clib2). That's the main reason why I would discourage the usage of
shared clib2 (and any .so that links against clib2). Note of course that
if the .so doesn't share a dependency with the main program it is fine
though, e.g., if the .so doesn't need a clib. But this is seldom the
case (I guess it is mostly handcrafted stuff, but then you probbaly
could also use true AmigaOS libraries). It is also okay if you supply
all .so dependenies and don't really share them with other tools.
Again: If you want .so you must ensure that all involved parties are
linked against a compatible version of all dependencies. We don't have a
system to ensure that (if I'm not mistaken). In that regard, it works
better with newlib because it is really only a wrapper to a proper
amigaos shared library. Thus, I generally discourage the usage of shared
objects in its current form (other than the mentioned exceptions and
perhaps few other ones).
In my branch i have a working example. The only problem is that the
stdout/stderr/stdin is not working on loaded object. For the rest it
is working correctly. I've tested it writing a file and works without
any problem.
dlopen/dlsym are just wrappers to DLOpen and DLSym of exec library.
And reading the autodoc it should map the loaded object in the main
program memory. So why it should not work?
At the level of DLOpen it works, but not at the level of the clibs, if
they differ.
However this is not a gcc problem. This is a clib2 problem.
This issue is just related to that switch in any case should not link
against libgcc.so but against libgcc.a
This is true.
|
|
well, yes. I'm speaking loading objects compiled with clib2. I know that if you try to open an .so compiled with newlib most probably will crash. But it is useful when opening plugins created with same clib. And sometime it happens if you port software from linux |
|
@sba1 @sba1 Because if we will continue to split stuff like this, then clib2 issue will be not only .so and things we discuss, but a fork-mess. Not the latest reason for this is the low speed of accepting pull-requests IMHO. For example, there is for almost 3 (!!) years pull request about a change to the proper, latest SDK link: #55 . Are there any reasons why you do not accept this pull request for 3 years?:) |
|
Am 2021-02-02 11:48, schrieb kas1e:
@sba1 [1]
There is some mess started: We have now 3 different versions of clib2.
One in adtools, another one is a fork from Sodero with fixes about
those "std:: not being a member blablalb". And the third one from
agfxgroup. It is obvious that we start creating a mess now, and that
is another reason why newlib is better: it has just one single owner,
and everything in.
For now, I see Sodero make a pull request to adtools repo, with gcc9
"std::" fixes, but it used his clib2 fork. Wasn't it better for you to
accept his clib2 changes to adtools, and then accept pull request to
adtools itself ? Then, changes from agfxgroup can be pull requested
one by one too.
I'm not the maintainer of the orginal repo
https://github.com/adtools/clib2
All development should happen against orginal repo, and the pull
requests should be issued against it.
@obarthel, it is okay for you to go through these changes and eventually
accept them if you are fine by them? I'm happy to do it as well, but I'm
not sure if I can follow your philiosophy as good as you can ;) (I guess
that 68k-compatibility matters). Alternatively, you further could extend
the group of developers.
Note that at least some of the changes are needed for improved libstdc++
experience with ppc gcc.
Because if we will continue to split stuff like this, then clib2 issue
will be not only .so and things we discuss, but a fork-mess. Not the
latest reason for this is the low speed of accepting pull-requests
IMHO.
|
|
Am 02.02.21 um 12:09 schrieb Sebastian Bauer:
Am 2021-02-02 11:48, schrieb kas1e:
> @sba1 [1]
> There is some mess started: We have now 3 different versions of clib2.
> One in adtools, another one is a fork from Sodero with fixes about
> those "std:: not being a member blablalb". And the third one from
> agfxgroup. It is obvious that we start creating a mess now, and that
> is another reason why newlib is better: it has just one single owner,
> and everything in.
>
> For now, I see Sodero make a pull request to adtools repo, with gcc9
> "std::" fixes, but it used his clib2 fork. Wasn't it better for you to
> accept his clib2 changes to adtools, and then accept pull request to
> adtools itself ? Then, changes from agfxgroup can be pull requested
> one by one too.
I'm not the maintainer of the orginal repo
https://github.com/adtools/clib2
All development should happen against orginal repo, and the pull
requests should be issued against it.
@obarthel, it is okay for you to go through these changes and eventually
accept them if you are fine by them? I'm happy to do it as well, but I'm
not sure if I can follow your philiosophy as good as you can ;) (I guess
that 68k-compatibility matters). Alternatively, you further could extend
the group of developers.
The 68k compatibility is most essential. clib2 was written so that I
could get code ported much more easily, and Roadshow (among other
cross-platform software) needs this feature.
I still need to review the submitted changes, didn't get around to do
this last week, I'm afraid :-( Also need to respond to the author's
e-mails, too.
Incidentally, there are still changes in the development branch which
need another look and testing: these changes affect performance of
buffered stdio and might make a real positive difference compared to how
I implemented these functions originally. The new code makes smarter use
of the buffer instead of funneling all accesses through getc()/putc(),
respectively.
Note that at least some of the changes are needed for improved libstdc++
experience with ppc gcc.
This is fine. I wish we had a 68k GCC to play with which supports
contemporary C++, but that might need more work if clib2 is the
foundation for everything.
> Because if we will continue to split stuff like this, then clib2 issue
> will be not only .so and things we discuss, but a fork-mess. Not the
> latest reason for this is the low speed of accepting pull-requests
> IMHO.
Yes, this is true. It is great that there are contributions now.
That is progress indeed :-)
…--
Home: Olaf Barthel, Gneisenaustrasse 43, D-31275 Lehrte
Net: [email protected] (Home), [email protected] (Work)
|
|
@sba1 Yes, I started small with a minor PR to not overwhelm @obarthel . We had an e-mail conversation where I got some feedback, leading to me updating the PR, but since then I haven't heard anything and I don't want to be too annoying. I also would like everything to end up upstream in Barthels repo, but whether that's realistic depends on what the scope of clib2 is. I understand that 68k and keeping it lean is key, but how lean, and if NG specific things are OK, is not clear to me. |
|
@obarthel Yep, the problem we're discussing here is a very good one to have :-). If you feel that C++ > 98 is within the scope of clib2 then I can start splitting things up to avoid monster reviews. The only major things really missing from C++11/17/2a (using my fork) are the wchar stubs. |
|
Clib2 use ancient code that on os4 is not a great solution. For example Seek that limits the files size to 32bit. The clib2 code is from 2005. So 4.0 era. It needs to be changed but if you want to maintain the os3 compatibility is hard and the code will be a mess. (imho of course). That's why i've started to erase all 68k code. Simply because no one is using it (except roadshow that however can be compiled with the original clib2). So, in the end. Forget my clib2 version. Use the original one in gcc but keep in mind that something doesn't work if you don't change it deeply |
And as seems, clib2 wasn't targeting at all to be "modern clib for os4" for everyone, but mostly for personal Olaf's needs, then it again proves our fear that only newlib is left (or, different forks of all kinds). I asked Hyperion's management about opening newlib, and has been told that will be considered later. But it also means chances are low, IMHO. @obarthel |
|
> Use the original one in gcc but keep in mind that something doesn't
> work if you don't change it deeply
And as seems, clib2 wasn't targeting at all to be "modern clib for
os4" for everyone, but mostly for personal Olaf's needs, then it again
proves our fear that only newlib is left (or, different forks of all
kinds). I asked Hyperion's management about opening newlib, and has
been told that will be considered later. But it also means chances are
low, IMHO.
@obarthel [1]
Are you want to keep clib2 be the same "old" without improvements, or
want to improve it further? If later, things need to be changed deeply
for sure. And 68k code in only stop it from progress.
I disagree. Keeping 68k compatibility doesn't imply the limitation of
progress for new features. I agree that using #ifdes is an ugly solution
but it is not the only solution. And I agree that a properly developed
solution will demand more resources.
As is stands, this project should support all existent platforms, even
if it appears more PPC/OS4 centric. Personally, I even appreciate the
existence of 68k clib2 such that I tried to make a newer 68k version of
gcc available (at least one that cross compiles) in the past. Since the
gcc's 68k backend has been modernized in the meantime it may be worthy
to look at it again. Whether modern C++ applications can run on a 68k is
different question though ;)
|
|
I don't really see 68k as a big problem. There's an upside to it as well, keeping 68k means more users and users are the best testers. Of course this depends on the code base being kept together as much as possible. There's just three options here, relying on newlib (where we can't fix anything at all), forking clib2, making it a pure OS4 lib, which makes things easier short-term but might lead to cherry-picking and confusion in the long run, and improving clib2 as it is now (if @obarthel thinks that's ok). I don't just think that the last option is the least bad one, I actually think it's a good one. |
|
Am 02.02.21 um 16:50 schrieb kas1e:
Use the original one in gcc but keep in mind that something doesn't
work if you don't change it deeply
And as seems, clib2 wasn't targeting at all to be "modern clib for os4"
for everyone, but mostly for personal Olaf's needs, then it again proves
our fear that only newlib is left (or, different forks of all kinds). I
asked Hyperion's management about opening newlib, and has been told that
will be considered later. But it also means chances are low, IMHO.
@obarthel <https://github.com/obarthel>
Are you want to keep clib2 be the same "old" without improvements, or
want to improve it further? If later, things need to be changed deeply
for sure. And 68k code in only stop it from progress.
As I mentioned, 68k support is essential. You can write code which
supports more than one flavour of target system, and it doesn't have to
devolve into stacks of #ifdefs on top of other #ifdefs. I've seen that
kind of code in AmigaOS4 and, frankly, it looked like it was a
workaround rather than a proper integration. This isn't how it's
supposed to be. It's supposed to stay readable and documented.
clib2 was designed to be a static link library which the developer could
change and override if needed. This was sorely missing in the SAS/C 'C'
runtime library, and it made porting Unix-hosted code much harder.
As it happened, we didn't have a 'C' runtime library ready when OS4
development started and we adopted clib2 for the time being. Then,
because of performance issues and implementation bugs in clib2 which
were still a long way of getting found and fixed, Jörg Strohmayer
adapted newlib, which was then given a prominent place in the OS4
architecture. The upside was more robust code, shorter executables
(shared library), but the downside included an additional dependency
(how do you run your shell commands if the library is missing?) and no
options for the developer to override anything.
I believe that clib2 still satisfies needs beyond my own work. For one
thing, the flexibility built into the library design allows you to
override things if you have to or need to. Also, source code's open ;-)
…--
Home: Olaf Barthel, Gneisenaustrasse 43, D-31275 Lehrte
Net: [email protected] (Home), [email protected] (Work)
|
|
Am 02.02.21 um 17:58 schrieb Ola Söder:
I don't really see 68k as a big problem. There's an upside to it as
well, keeping 68k means more users and users are the best testers. Of
course this depends on the code base being kept together as much as
possible. There's just three options here, relying on newlib (where we
can't fix anything at all), forking clib2, making it a pure OS4 lib,
which makes things easier short-term but might lead to cherry-picking
and confusion in the long run, and improving clib2 as it is now (if
@obarthel <https://github.com/obarthel> thinks that's ok). I don't just
think that the last option is the least bad one, I actually think it's a
good one.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#98 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAEALHAKUIAFQPQ6YUG4CQ3S5AVLBANCNFSM4WYUSPQA>.
Forking seems to me to be the choice of last resort if the code
maintainer's terminally uncooperative, has walked away from the project
or you just don't even care about the original developer at all. Chances
are your fork will be small, one of many and it will take a giant effort
to push all those djinnies back into the same lamp again.
Fixing things by forking, then breaking, then glueing it back together
again is a miserable process.
As always, I advocate for building upon what exists, without sacrificing
complexity and readability along the way. The library was designed to be
understandable and open to customization, too, since I got bitten by the
lack thereof before.
…--
Home: Olaf Barthel, Gneisenaustrasse 43, D-31275 Lehrte
Net: [email protected] (Home), [email protected] (Work)
|
|
Am 02.02.21 um 13:51 schrieb Ola Söder:
@obarthel <https://github.com/obarthel> Yep, the problem we're
discussing here is a very good one to have :-). If you feel that C++ >
98 is within the scope of clib2 then I can start splitting things up to
avoid monster reviews. The only major things really missing from
C++11/17/2a (using my fork) are the wchar stubs.
The wide character stubs should be helpful, but I was worried about
getting them wrong, so I chose not to tinker with them. The 'C'
documentation I had access to posed more questions as to how to
implement them than it answered :-/
Time's ripe to do something about this, now that you mention it :-)
…--
Home: Olaf Barthel, Gneisenaustrasse 43, D-31275 Lehrte
Net: [email protected] (Home), [email protected] (Work)
|
|
@obarthel I also feel a bit uneasy when I see wchar* (especially if Amiga shows up in the same sentence). I have no clue how to test the clib plumbing in a comfortable way. As it is now, the stubs don't affect libstdc++ since there's not enough of them :-) (which means we don't trick autotools into enabling features that aren't there). |
@sba1 |
|
There are really too many changes to keep both 68k and os4 and maintain the code readable. Another change was to replace old Seek calls with new OS4 functions that supports 64bit. Again you could use some #define to support both platforms but is hard because also return values are changed. It is no so easy. really. Also shared objects, for example, cannot be used on OS3 and needs two different begin/end files and not crtbegin/crtend. Remember that on OS4 you have ixemul that is perfect to port software from *nix. That's why i still prefer to remove 68k code. But nothing prevent to get my code where possible and put it into Olaf's clib2 |
|
@afxgroup You can always #ifdef an entire function (within reason of course) if it becomes to complex. It might also be worth it to look at how these type of 'transitional' problems are solved on other platforms. In this case, 32/64 bit problems, fseek, fseek64 and so on. But take this with a shovel of salt, I haven't seen the code so it's very easy for me to pretend that it's doable ;) |
|
One way of managing variability could be to use a well thought out directory structure. It's very flat as it is now, there are pros and cons to this of course. |
|
@everyone |
|
@kas1e |
This means separate code.. and have the same result. It is always possible use code from one clib2 to the other one (and viceversa). But i don't like mess code. Is just my way to do things. |
|
@afxgroup Sure, it's open source, forking is an option. But the spark in this discussion was kas1e:s fear that forks will create confusion and I agree with him. It's just a matter of opinion though. And about the directory structure; I didn't mean that we should just throw everything in a bucket, that would be pointless, just like you said. |
|
Am 02.02.21 um 20:37 schrieb kas1e:
@everyone <https://github.com/everyone>
And can anyone explain why we need to keep those "thread-safe" and
"usual" versions of libs? Why it all just not "thread-safe" by default
of a single version and that it?
Because of the overhead which comes with thread-safety: locking
protocols. This may be a small price to pay, but in my opinion if you
don't need the thread-safe feature because you don't have multiple
Processes interacting with the same data structures and APIs, then you
shouldn't have to pay the toll.
Please keep in mind that clib2 is a statically linked library with the
option to override and replace library code, giving you more control
over what you are going to get out of it. The thread-safe variant is a
part of that philosophy.
…--
Home: Olaf Barthel, Gneisenaustrasse 43, D-31275 Lehrte
Net: [email protected] (Home), [email protected] (Work)
|
|
Am 02.02.21 um 21:42 schrieb Ola Söder:
No point in being thread safe when you're not doing any threading :) The
thread safe builds use semaphores low level stdlib functions like malloc
and so on. I have no idea how expensive that is. But it's in places
where cost matters.
The overhead is small, but then you also need to be aware of what APIs
and data structures you are using. If the default is thread-safety, and
you don't know what this entails, you might be surprised by the effects
and not necessarily in a good way.
…--
Home: Olaf Barthel, Gneisenaustrasse 43, D-31275 Lehrte
Net: [email protected] (Home), [email protected] (Work)
|
|
Am 02.02.21 um 19:30 schrieb Ola Söder:
Since the gcc's 68k backend has been modernized in the meantime it
may be worthy to look at it again. Whether modern C++ applications
can run on a 68k is different question though ;)
@sba1 <https://github.com/sba1>
Indeed, in gcc10 things that affect our 68k backend have happened.
OS4 is not a problem, but I think I need your help with one of the
68k patches :-) (once we've resolved the clib2 issue)
This may sound quaint, but the 68k AmigaOS platform needs a native
modern 'C' compiler and a runtime library which is designed to work with
the actual operating system instead of pretending that it's actually a
1990'ies BSD Unix.
Furthermore, that 'C' compiler should be a 68k native 'C' compiler, and
not a cross-compiler. This is where clib2 can help.
68k AmigaOS development currently uses the old tool stack (SAS/C) and it
can't do so forever.
…--
Home: Olaf Barthel, Gneisenaustrasse 43, D-31275 Lehrte
Net: [email protected] (Home), [email protected] (Work)
|
Luckily 68k wasn't killed of in g cc10, but it was a close call. I don't know who did the work but there's still hope for a fresh native compiler. Someone also started the work on a LLVM backend for 68k which is nice. That code base is a lot easier to understand so in the long run it might be interesting. If upstream are willing to accept a new legacy backend is another question, but even if they don't, it should be easier for us to maintain an out of tree 68k backend. I've been thinking of doing some experiments but 68k is not my cup of tea to be honest and I know nothing about the hunk format. It would be fun though, but probably a lot of work. |
|
@obarthel I opened two more PRs by the way, bugfixes that should be useful to everyone. |
|
Am 02.02.21 um 19:20 schrieb Ola Söder:
@obarthel <https://github.com/obarthel> I also feel a bit uneasy when I
see wchar* (especially if Amiga shows up in the same sentence). I have
no clue how to test the clib plumbing in a comfortable way. As it is
now, the stubs don't affect libstdc++ since there's not enough of them
:-) (which means we don't trick autotools into enabling features that
aren't there).
Last year I took the plunge and bought a used copy of Plauger's "The
standard C library". It seems like most of the 'C' books which venture
into the deep end of the pool are now out of print!.
This book describes the C90 (ANSI 'C') library and provides a sample
implementation. 'wchar_t' and friends were already part of that standard
(https://begriffs.com/posts/2019-01-19-inside-c-standard-lib.html), so
this might be worth a look just to see what Mr Plauger came up with.
I read part of the book last year and found one aspect particularly
chilling: the 'C' standard defined the locale data structures but failed
to provide functions for accessing it and making use of the data itself.
In his book Mr Plauger describes how he implemented the missing pieces.
…--
Home: Olaf Barthel, Gneisenaustrasse 43, D-31275 Lehrte
Net: [email protected] (Home), [email protected] (Work)
|
|
Am 02.02.21 um 19:43 schrieb Papersoft.it:
There are really too many changes to keep both 68k and os4 and maintain
the code readable.
One change i've made is to use *ExamineData* instead of *FileInfoBlock*.
This because the old functions now on OS4 are deprecated. It was a pain.
And, yes, you could wrap everything around #ifdefs but it is really
unreadable also with modern editors and it is hard to fix also problems.
It does not have to be unreadable :-)
I maintained Roadshow, the FFS, smbfs and the new Disk Doctor for a
while now, and all of these build for AmigaOS 4 and AmigaOS 2.04+
without triggering migraine attacks.
Another change was to replace old Seek calls with new OS4 functions that
supports 64bit. Again you could use some #define to support both
platforms but is hard because also return values are changed. It is no
so easy. really.
But then it's rarely easy to do something worthwhile, is it? ;-)
That's why i told you to continue to support classic clib2 version but
keep in mind that is really hard to fix things with both platforms in mind.
Also shared objects, for example, cannot be used on OS3 and needs two
different begin/end files and not crtbegin/crtend.
This was never part of the plan to begin with. Shared objects are an
AmigaOS4 feature. clib2 is a 'C' runtime library first which you can use
to build things without dragging in too many dependencies, and a
platform a very distant second.
Remember that on OS4 you have ixemul that is perfect to port software
from *nix. That's why i still prefer to remove 68k code. But nothing
prevent to get my code where possible and put it into Olaf's clib2
I disagree on the usefulness of ixemul.library in general.
ixemul.library leans (true to its name) more towards emulating a
POSIX-ish (in practice: 4.4BSD as it was in 1993/1994) environment. This
has specific uses, but then (when it was new) as now you may not be
well-served by how much baggage it carries with itself if you want to
use it as a convenient 'C' runtime library (you know the joke of wanting
a banana, but getting the entire jungle and the gorilla holding the
banana instead). Also, the handling of Task exceptions is still
somewhere in limbo between how Unix signals work and how they don't
really work in exec (you can delay signal delivery on Unix but there is
no such mechanism in exec).
Part of why clib2 exists is because I didn't want to wrestle with the
gorilla, the banana he was clutching (the banana peel lying around
somewhere, waiting for you to slip on it) and the jungle he had attached
himself to just so that I could run Samba 2.0.4. I wanted to port that
code, not just hope that it would somehow limp along and not crash for
reasons hard to fathom (lack of stack space? ran out of memory? called
alloca() too often?).
clib2 is designed for a specific use case, and the overlap between it
and what ixemul.library delivers is much, much smaller than might
suggest itself.
…--
Home: Olaf Barthel, Gneisenaustrasse 43, D-31275 Lehrte
Net: [email protected] (Home), [email protected] (Work)
|
|
Am 02.02.21 um 20:34 schrieb Ola Söder:
One way of managing variability could be to use a well thought out
directory structure. It's very flat as it is now, there are pros and
cons to this of course.
After almost 20 years, I think that the positives aspects are very few.
All the files are in plain sight and the build process is simple & dull
(a single makefile is sufficient).
It seems natural to split this up and organize it by file name prefix,
sticking all the related source files into a common subdirectory. I
never got around to doing that because it would have involved rewriting
the smakefile, too, which is essential to debugging clib2 code on the
68k platform :-(
…--
Home: Olaf Barthel, Gneisenaustrasse 43, D-31275 Lehrte
Net: [email protected] (Home), [email protected] (Work)
|
|
Am 03.02.21 um 08:47 schrieb Ola Söder:
Am 02.02.21 um 19:30 schrieb Ola Söder:
Since the gcc's 68k backend has been modernized in the meantime it
may be worthy to look at it again. Whether modern C++ applications
can run on a 68k is different question though ;) @sba1
<https://github.com/sba1> https://github.com/sba1
<https://github.com/sba1> Indeed, in gcc10 things that affect our
68k backend have happened. OS4 is not a problem, but I think I need
your help with one of the 68k patches :-) (once we've resolved the
clib2 issue)
This may sound quaint, but the 68k AmigaOS platform needs a native
modern 'C' compiler and a runtime library which is designed to work
with the actual operating system instead of pretending that it's
actually a 1990'ies BSD Unix. Furthermore, that 'C' compiler should
be a 68k native 'C' compiler, and not a cross-compiler. This is
where clib2 can help. 68k AmigaOS development currently uses the old
tool stack (SAS/C) and it can't do so forever.
… <#>
-- Home: Olaf Barthel, Gneisenaustrasse 43, D-31275 Lehrte Net:
***@***.*** ***@***.***> (Home),
***@***.*** ***@***.***> (Work)
Luckily 68k wasn't killed of in g cc10, but it was a close call. I don't
know who did the work but there's still hope for a fresh native
compiler. Someone also started the work on a LLVM backend for 68k which
is nice. That code base is a lot easier to understand so in the long run
it might be interesting. If upstream are willing to accept a new legacy
backend is another question, but even if they don't, it should be easier
for us to maintain an out of tree 68k backend. I've been thinking of
doing some experiments but 68k is not my cup of tea to be honest and I
know nothing about the hunk format. It would be fun though, but probably
a lot of work.
The modern GCC still uses binutils for binary file wrangling, doesn't
it? The Amiga-aware binutils are still being maintained, albeit not
necessarily in the context of adtools. Gunter Nikl still maintains his
binutils, specifically the Amiga-hunk support.
…--
Home: Olaf Barthel, Gneisenaustrasse 43, D-31275 Lehrte
Net: [email protected] (Home), [email protected] (Work)
|
|
How about moving this discussion to somewhere else? Github discussions at our adtools group comes into my mind. This would be visible then to @adtools/developers as well. I would be glad to also add others to that organization. |
|
@sba1 Btw, is there any reason why you didn't accept for few years fixed SDK URL to download the latest one from Hyperion? Maybe there were some bugs because of which you revert to older SDK while it has strangely 53.30 name, but download instead older one? |
Fair point. I'd really to join if that's OK. Just one last comment to @obarthel , then I'm out :-) (I feel like a child saying that).
Yes, binutils is still used, good to know that it's still maintained. I was refering to LLVM though. I know very little about what happens behind the frontend, most books focus on that (which is understandable). The Plauger book looks nice BTW, pdf downloaded (seems a bit hard to come by a real one). |
|
Am 03.02.21 um 20:27 schrieb Ola Söder:
@sba1 <https://github.com/sba1>
How about moving this discussion to somewhere else? Github
discussions at our adtools group comes into my mind. This would be
visible then to @adtools/developers as well. I would be glad to also
add others to that organization.
Fair point. I'd really to join if that's OK.
Just one last comment to @obarthel <https://github.com/obarthel> , then
I'm out :-) (I feel like a child saying that).
The modern GCC still uses binutils for binary file wrangling, doesn't
it? The Amiga-aware binutils are still being maintained, albeit not
necessarily in the context of adtools. Gunter Nikl still maintains his
binutils, specifically the Amiga-hunk support.
Yes, binutils is still used. I was refering to LLVM. I know very little
about what happens behind the frontend, most books focus on that (which
is understandable). The Plauger book looks fantastic BTW, pdf downloaded
(seems a bit hard to come by a real one).
I recommend the book, it's just a shame that the 'C' language
literature, especially for the library and its design, has become so
shallow :-(
Careful about Mr Plauger's library example implementation: this stuff is
still copyrighted and you'd need a license to reproduce and use it in
your own implementation. Lucky me, when I started out with clib2 I built
it largely in the image of the BSD libc code ;-)
Also, the Manx Software Systems folks made the source code of the Aztec
'C' 5.0 Amiga compiler's runtime library available (which, of course,
cost good money), which included documentation for each and every
library function in context when (in 1990) you couldn't get hold of the
corresponding ANSI X3.159-1989 and ISO/IEC 9899:1990 documentation
unless you knew a) where to order it from and b) had a lot of memory to
spend.
That documentation and how the functions were implemented was a great
reference to start with. Also extremely helpful: "'C' - A reference
manual" by Guy Steele, etc. However, the most recent edition seems to be
out of print today and there appears to be no update for C99 or (for
that matter) C11/C17 in the wings.
I'm in the market for books which cover the C99-C11 standards in detail,
but there seems to be very little to go around.
I bought "Effective C" by Robert Seacord and came away disappointed (the
parts which I didn't already know were too short for my liking).
"Extreme C" by Kamran Amini looks much better, although more than half
of it is concerned with platform-specific implementation details. This
makes sense, for example, with regard to multithreading and
synchronization primitives which became part of the C11 specification.
…--
Home: Olaf Barthel, Gneisenaustrasse 43, D-31275 Lehrte
Net: [email protected] (Home), [email protected] (Work)
|
|
@obarthel So, as I result, how we can be in hope that clib2 will replace anything ?:) Of course, it may, but will not if we continue like this. Probably the best we can do now, it only improves GCC for newlib then (As I told you from the beginning), because and clib2 is not in the scope of change anything, and Olaf has no time for it. And it just looks mostly like a library for Olaf's needs. So... But then, even with "just" GCC fixes, it also means Sebastian need to find time on accepting/review request. If there is no time on Sebastian's side, then probably better to made a fork for our local needs, indeed. And maybe later we can ask Hyperion to include to official SDK our fork, and ask all developers to use this one instead. Because no progress sucks hard and kills all motivation. It's now all the same as with newlib : we wait for someone to find time to accept/review changes, the same as we want from Hyperion to release updated newlib (on which at least Frederik works quite heavy all the time and updating it). I mean, we lucky to have interest from Sodero now, who actually do something on that front, why we should kill all his motivation with such an unacceptable speed of just pure reviewing/accepting/rejecting patches? @sodero |
|
Am 07.02.21 um 09:37 schrieb kas1e:
@obarthel <https://github.com/obarthel>
@sba1 <https://github.com/sba1>
Giving the VERY unacceptable and slow pool request reviews and accepting
or rejecting them, you of course kill all sodero's motivation to
continue with it :( Waiting weeks to accept simple patches is
unacceptable and of course, no one can works fast when
accepting/reviewing/rejecting pool requests taking months. He many times
repeat what he waiting for, and even push-request his changes few times,
but nothing.
Hold your horses, please...
Yes, progress is slow, so slow that you don't see it happening. At the
moment I'm stuck with a ton of work on my shoulders (both Amiga-related
and work-related) for which I'm making barely any progress on account of
it being so much, and every bit screams for immediate attention.
Please tolerate that persons such as myself are not always able to
quickly respond to e-mail or pull requests. And by "quickly" I mean
within the span of a week. I'm sorry, but this is how it is for me at
the moment.
Every day I wake up and hope that stuff I've built, contributed to and
feel responsible for hasn't tilted and toppled over. Being constantly in
firefighting mode for months on end is taking its toll, I'm afraid.
…--
Home: Olaf Barthel, Gneisenaustrasse 43, D-31275 Lehrte
Net: [email protected] (Home), [email protected] (Work)
|
|
@obarthel |
|
Am 2021-02-07 09:37, schrieb kas1e:
Giving the VERY unacceptable and slow pool request reviews and
accepting or rejecting them, you of course kill all sodero's
motivation to continue with it :( Waiting weeks to accept simple
patches is unacceptable and of course, no one can works fast when
accepting/reviewing/rejecting pool requests taking months. He many
times repeat what he waiting for, and even push-request his changes
few times, but nothing.
Please calm down a little bit.
I don't have an impression that anyone is demotivated (except perhaps
yourself as you have shown). As it stands for adtools, I added a request
in my review a short time after the PR. I find your pressure unfair and
tone unacceptable, especially given all the circumstances. I didn't get
an answer yet, but I fully understand this. As soon as this is resolved,
I think it is ready to be merged. I would be even more happy if the
clib2 changes would already be already in. But this will take also some
time.
Note that I also commented on the clib2 PR regarding sqrt(). These are
definitively not relevant of gcc support anyway but also need some
careful investigation, I suppose (it is a change in the behaviour and
both behaviours make sense, changing will risk in breaking programs
relying on the old behaviour, not easy to be honest).
Please reconsider your wording when you post next time and try to make
your investigations more effective.
@sodero [3]
Just to now have lost interest and motivation, maybe forget about
adtools for now, and keep working on a local fork with gcc9/gcc10? I
can help with all tests, etc, and later we can ask Hyperion to include
this one instead. Or that all will never end.
Everybody is free to do that of course. In this case, it doesn't make
any sense, to me at least.
|
|
I think the whole point of having a hobby is to do something that is as far away from work as possible and doesn't involve stress. When I wrote on amigans.net that I'll halt work on gcc for now (and I really meant for now, not forever), or atleast slow down, that was what I had in mind, I really didn't want to stir up any drama. Having a heap of PR:s waiting for review is stressful, and having a fork repo so full of branches that it starts to look like the London subway map is unpleasant, so I think it's in the interest of everyone, me included, to slow down. Please don't interpret this as a symptom of frustration, it's about finding a balance that's ok for everyone. A short-term pragmatic approach would be to have a branch in adtools where we could use a clib2 fork. In that way I could keep on trucking with gcc without generating a ton of pr:s while at the same time having the gcc patches in one place. |
-static-libgcc used with -shared doesn't produce a file with libgcc linked statically and instead produce a file linked always with libgcc.so
Not only. When used with clib2 and shared objects dl* functions cause a crash because the .so files try to open newlib in some way and of course everything crash. If remove libgcc.so from gcc lib cure the problem
The text was updated successfully, but these errors were encountered: