public inbox for libstdc++@gcc.gnu.org
 help / color / mirror / Atom feed
From: Vladimir V <vv.os.swe@gmail.com>
To: Jonathan Wakely <jwakely@redhat.com>
Cc: libstdc++@gcc.gnu.org
Subject: Re: Problem building libstdc++ for the avr target
Date: Wed, 9 Dec 2020 13:32:33 +0100	[thread overview]
Message-ID: <CA+=iAip_JN164_kZhDsd-+ET12Atve7F3aJcnmKCikFteVdDDg@mail.gmail.com> (raw)
In-Reply-To: <CA+=iAiqh1c9hUO45XUMuffNgZWhWuZOz+1cDhLGbPrXPVMPw0A@mail.gmail.com>

Hello.

While testing with the current upstream I encountered a compilation issue.
Although I build with "--disable-threads" flag the following error occurs:

../../../../../libstdc++-v3/src/c++11/thread.cc:39:4: error: #error "No
sleep function known for this target"

Previously the check was inside the  #ifdef _GLIBCXX_HAS_GTHREADS that
prevented the error from happening (in my case with gcc v10.1),
So I would like to ask if the thread.cc should be involved in the build if
the threads support is configured to be disabled?
And if it should, then can the condition be reworked to cover the described
case?

Thank you.

Vladimir

ср, 9 дек. 2020 г. в 01:28, Vladimir V <vv.os.swe@gmail.com>:

> Thank you.
> I am verifying my patch with the upstream version now.
>
> пн, 7 дек. 2020 г. в 21:32, Jonathan Wakely <jwakely@redhat.com>:
>
>> On 07/12/20 20:30 +0000, Jonathan Wakely wrote:
>> >On 07/12/20 18:32 +0100, Vladimir V via Libstdc++ wrote:
>> >>Dear libstdc++ developers,
>> >>
>> >>I have recently experimented with building 'hosted' variant of the
>> >>libstdc++ for the avr target.
>> >>Practically, it looks like, after minor extension of the avr-libc, it
>> can
>> >>be built.
>> >>Unfortunately, as a temporary workaround I had to disable dlopen test in
>> >>the configure script as I encountered the error:
>> >>
>> >>'checking for shl_load... configure: error: Link tests are not allowed
>> >>after GCC_NO_EXECUTABLES'
>> >>
>> >>while building with '--with-avrlibc' flag. The issue is described in
>> >>https://gcc.gnu.org/legacy-ml/gcc/2008-03/msg00515.html
>> >>and was resolved for the newlib. The fix was not applied for the
>> avr-libc
>> >>targets although the rationale behind the solution
>> >>seems to be applicable there as well. I would like to ask what do you
>> think
>> >>about extending the scope of the solution to work
>> >>with avr-libc based builds as well?
>> >
>> >Yes, I think it makes sense.
>>
>> I forgot to add that be95b3555aa82872565a1e1ea85ff826a20c8e2e was the
>> commit that added the check for ${with_newlib}.
>>
>>
>>

  reply	other threads:[~2020-12-09 12:32 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-07 17:32 Vladimir V
2020-12-07 20:30 ` Jonathan Wakely
2020-12-07 20:32   ` Jonathan Wakely
2020-12-09  0:28     ` Vladimir V
2020-12-09 12:32       ` Vladimir V [this message]
2020-12-09 12:49         ` Jonathan Wakely
2020-12-09 17:01           ` Jonathan Wakely
2020-12-09 23:00             ` Vladimir V
2020-12-10 17:39               ` Vladimir V
2020-12-10 20:15                 ` Jonathan Wakely
2020-12-10 20:31                   ` Vladimir V
2020-12-15 11:48                 ` Jonathan Wakely
2020-12-16  7:33                   ` Vladimir V
2020-12-07 20:41   ` Keith Packard
2020-12-07 21:06     ` Jonathan Wakely
2021-01-04 11:28       ` Vladimir V
2021-01-08 18:21         ` Jonathan Wakely
2021-01-22 14:46           ` Vladimir V
2021-02-07 13:55             ` Vladimir V
2021-02-07 18:22               ` Vladimir V
2021-02-07 18:23               ` Keith Packard
2021-02-07 22:33                 ` Vladimir V
2021-02-07 23:06                   ` Keith Packard
2021-02-08 12:58                     ` Vladimir V
2021-02-08 17:38                 ` Jonathan Wakely
2021-02-08 17:45               ` Jonathan Wakely
2021-02-08 17:47                 ` Jonathan Wakely
2021-02-08 22:25                   ` Vladimir V
2021-02-09 10:47                     ` Jonathan Wakely
2021-02-09 10:54                       ` Vladimir V
2021-03-25  9:27                         ` Vladimir V
2021-03-25 12:36                           ` Jonathan Wakely
2021-03-25 18:27                             ` Jonathan Wakely
2021-03-25 21:37                               ` Vladimir V
2021-03-25 23:02                                 ` Jonathan Wakely
2021-03-26  8:25                                   ` Vladimir V
2020-12-07 21:51     ` Vladimir V
2020-12-07 23:00       ` Keith Packard
2020-12-08  8:12         ` Vladimir V

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='CA+=iAip_JN164_kZhDsd-+ET12Atve7F3aJcnmKCikFteVdDDg@mail.gmail.com' \
    --to=vv.os.swe@gmail.com \
    --cc=jwakely@redhat.com \
    --cc=libstdc++@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).