public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "unlvsur at live dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/100057] There are no freestanding C++
Date: Tue, 13 Apr 2021 10:01:05 +0000	[thread overview]
Message-ID: <bug-100057-4-BenlSWOFnq@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-100057-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100057

--- Comment #26 from cqwrteur <unlvsur at live dot com> ---
yes. i tried that first and Then report a bug here. whats wrong with it? wasn't
bugzilla designed for the stuff here? you asked me not to put you in the CC
list and i did. Whats the complain here?

1. i do build things with newlib and i know It works. However It was actually
you who said newlib is not standard compliant etc. That is why i would like to
have a try to see whether It works or not because i tried That before and It
didn't. i wasn't claiming something wrong.
2. i am not the first person who tried that. i believe a lot of people tried
that before and they failed. That is why newlib is very popular. However It
still does not change the fact using C++ to write OS kernel stuffs are
fruastrating.
3. newlib is a panacea to the issue. because There are still a lot of places
WHERE you cannot use newlib. like writing UEFI barebones or windows kernel
which require the Binary to be PE format Instead of elf format.
4. When people build stuffs with newlib they usually do not disable libstdcxx
verbose which leads to at least 60kb of Binary bloat of binutils (c++filt)+the
dependency of stdio which make exception handling much hard to use
5. Yes. I love to try All options because i want to solve problems. i want to
ensure My library works without operating system and on various platforms, not
just Linux or windows. i want to kill stdio. That is why i keep building All
sorts of cross toolchains or Even hosted cross toolchains in the first place.
People who do not use cross compilers are actually problem creators since they
do not know What is Going to happen with their own mess
6. Sure GCC`s implementation is not the only option. However We only have 3
options currently. libstdc++. libc++. msvc STL. msvc STL is windows only. every
other option is dead out. including famous STLPort.
7. The fruastation of using C++ is exactly why OSdevs like linus hate the
language because We do create issues for ourselves.

Get Outlook for Android<https://aka.ms/AAb9ysg>

________________________________
From: redi at gcc dot gnu.org <gcc-bugzilla@gcc.gnu.org>
Sent: Tuesday, April 13, 2021 5:24:53 AM
To: unlvsur@live.com <unlvsur@live.com>
Subject: [Bug libstdc++/100057] There are no freestanding C++

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgcc.gnu.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D100057&amp;data=04%7C01%7C%7C6b91e3ef37c449fdc96408d8fe5dff7b%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637539026953147227%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=LdwLt6enWUifwfT4Y05iDygnveuN8Y35bxAS0iAwO%2B0%3D&amp;reserved=0

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #23 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to cqwrteur from comment #0)
> There are no freestanding C++ :)

You are confused. The fact that libstdc++ has a freestanding mode which still
has certain requirements doesn't mean "there are no freestanding C++".

GCC is just one implementation, you can't make such a generalization about "no
freestanding C++" from one implementation.

> I am perfectly correct.

No, you are confused.





(In reply to cqwrteur from comment #10)
> I guess nobody ever tries to build freestanding before. It just does not
> work tbh.

Have you tried building the compiler first, without building libstdc++ at all,
then using that compiler to build the freestanding libstdc++?

Lots of people build with newlib, every day. Instead of assuming nobody ever
does it and it's broken until you come along, maybe assume you're doing it
wrong.



(In reply to cqwrteur from comment #19)
>That is why people are not using C++ for writing operating system.

There's a chicken and egg situation. Nobody is doing it, so the configuration
to do it is not widely used and not as smooth as the default hosted
configuration.

If you want it to work, try being constructive instead of an irratating prick.


(In reply to cqwrteur from comment #12)
> Then it is libquadmath's issue. no errno.h

So --disable-libquadmath



(In reply to cqwrteur from comment #20)
> The freestanding C++ is an absolute joke. Not just because of the reason of
> exception handling. The GCC team did a horrible job in the past.


I've told you before that your attitude makes people ignore you and dismiss you
as an irritating person that nobody wants to work with or help.

If you think GCC is so bad, create your own compiler and stop bothering us and
insulting people.

Your ability to communicate politely and reasonably is an absolute joke and
every time I see you've reported a new "bug" I die a little bit inside.

Instead of reporting a bug and then spamming it with new comments every  time
you try something different, spend some time trying things FIRST and then
report a focused, detailed bug about specific issues.

Nobody wants to read your stream of consciousness rants.

I'm closing this as invalid.

Report a separate bug for concrete issues like "please add a new option for a
freestanding build that implies --disable-hosted-libstdcxx
--disable-libquadmath and all other relevant options" (which will probably be
closed as INVALID or WONTFIX).

--
You are receiving this mail because:
You reported the bug.
You are on the CC list for the bug.

  parent reply	other threads:[~2021-04-13 10:01 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-13  0:22 [Bug libstdc++/100057] New: " unlvsur at live dot com
2021-04-13  0:26 ` [Bug libstdc++/100057] " unlvsur at live dot com
2021-04-13  0:29 ` unlvsur at live dot com
2021-04-13  0:44 ` unlvsur at live dot com
2021-04-13  0:58 ` unlvsur at live dot com
2021-04-13  1:34 ` phdofthehouse at gmail dot com
2021-04-13  1:36 ` phdofthehouse at gmail dot com
2021-04-13  1:53 ` unlvsur at live dot com
2021-04-13  1:57 ` unlvsur at live dot com
2021-04-13  2:20 ` unlvsur at live dot com
2021-04-13  2:21 ` unlvsur at live dot com
2021-04-13  2:49 ` unlvsur at live dot com
2021-04-13  3:58 ` unlvsur at live dot com
2021-04-13  4:36 ` unlvsur at live dot com
2021-04-13  5:12 ` unlvsur at live dot com
2021-04-13  7:50 ` unlvsur at live dot com
2021-04-13  8:12 ` unlvsur at live dot com
2021-04-13  8:14 ` unlvsur at live dot com
2021-04-13  8:46 ` rguenth at gcc dot gnu.org
2021-04-13  8:48 ` unlvsur at live dot com
2021-04-13  8:51 ` unlvsur at live dot com
2021-04-13  8:57 ` rguenth at gcc dot gnu.org
2021-04-13  9:06 ` unlvsur at live dot com
2021-04-13  9:24 ` redi at gcc dot gnu.org
2021-04-13  9:27 ` redi at gcc dot gnu.org
2021-04-13  9:41 ` redi at gcc dot gnu.org
2021-04-13 10:01 ` unlvsur at live dot com [this message]
2021-04-13 10:32 ` unlvsur at live dot com
2021-04-13 10:50 ` redi at gcc dot gnu.org
2021-08-21  8:50 ` unlvsur at live dot com
2021-08-23 10:08 ` redi at gcc dot gnu.org
2021-08-23 10:16 ` unlvsur at live dot com
2021-08-23 10:19 ` unlvsur at live dot com
2021-12-29 22:17 ` pixel@nobis-crew.org
2021-12-29 23:04 ` pixel@nobis-crew.org
2021-12-29 23:57 ` unlvsur at live dot com
2021-12-29 23:57 ` unlvsur at live dot com
2021-12-30 10:19 ` redi at gcc dot gnu.org
2021-12-30 10:25 ` redi at gcc dot gnu.org
2021-12-30 10:56 ` redi at gcc dot gnu.org
2021-12-30 11:31 ` redi at gcc dot gnu.org
2021-12-30 18:37 ` unlvsur at live dot com
2021-12-30 18:39 ` unlvsur at live dot com

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-100057-4-BenlSWOFnq@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).