Re: the risk of dependencies on the C++ runtime.
(apologies Konstantin, your email got trapped in a spam filter; "It is in
violation of Google's recommended email sender guidelines", according to
GMail).
Avoiding C++ runtime dependencies is fairly straightforward in practice
(e.g. a program that
[I should have checked for 3 digit numerals in r notation.]
On 2017-Oct-7, at 11:36 PM, Mark Millard wrote:
> With a fresh day after sleep and some pondering
> I finally am thinking straight for where things
> are in files for C++ scratch register usage and
> such:
>
> It is libgcc_s.so.1 that
With a fresh day after sleep and some pondering
I finally am thinking straight for where things
are in files for C++ scratch register usage and
such:
It is libgcc_s.so.1 that has all the extra use of
scratch registers for C++ exception handling --and
lots of other special stuff as well.
This note
It turns out that /usr/local/bin/gdb crashing
for the clang-built powerpc64 world is again
due to C++ exceptions being thrown, this time
in gdb80 itself.
This helps explain why for clang-based buildworld
experiments /usr/libexec/gdb is a better alternative
currently for the powerpc families.
Aga
On 2017-Oct-7, at 3:21 AM, Roman Divacky wrote:
> Answers inline.
>
> On Sat, Oct 07, 2017 at 03:13:43AM -0700, Mark Millard wrote:
>> Just a short top-post as this does not fit well with the
>> other material:
>>
>> I believe Roman only built his example program
>> with clang, not the world th
Answers inline.
On Sat, Oct 07, 2017 at 03:13:43AM -0700, Mark Millard wrote:
> Just a short top-post as this does not fit well with the
> other material:
>
> I believe Roman only built his example program
> with clang, not the world that the program was
> being run under.
I used a machine with
Just to clarify my not agreeing with Mark regarding EH on ppc64.
Last time I tried to fix ppc64 exceptions handling as generated by clang
it turned out that simply using gnu ld from ports fixes the issue.
For details see:
https://lists.freebsd.org/pipermail/freebsd-toolchain/2017-May/002961.html
Just a short top-post as this does not fit well with the
other material:
I believe Roman only built his example program
with clang, not the world that the program was
being run under.
The gcc 4.2.1 based code that is analogous to
__cxa_begin_catch (scratch register initialization)
in a clang base
[The last part of my note has a dumb mistake, not
that it messes up the other evidence. I should have
dwarfdump'd not a.out but the code in the libraries,
such as __cxa_begin_catch in /lib/libcxxrt.so.1 . I
made the same mistake initially back when Roman and
I were dealing with this long ago. Corre
[I'm separately listing backtrace information and related
information from one of core dumps and going back through
the details to see if they seem to be as they were back
then. Read only if you care. It does look the same as I
found back then if I remember right. I reach the same
conclusion I reac
[I'm adding examples with output from clang -v since it explicitly shows
the path used for ld and such.]
On 2017-Oct-7, at 12:58 AM, Mark Millard wrote:
> On 2017-Oct-6, at 11:42 PM, Roman Divacky wrote:
>
>> Just to clarify my not agreeing with Mark regarding EH on ppc64.
>>
>> Last time I t
On 2017-Oct-6, at 11:42 PM, Roman Divacky wrote:
> Just to clarify my not agreeing with Mark regarding EH on ppc64.
>
> Last time I tried to fix ppc64 exceptions handling as generated by clang
> it turned out that simply using gnu ld from ports fixes the issue.
>
> For details see:
> https://l
On 2017-Oct-6, at 9:58 AM, Conrad Meyer wrote:
> On Fri, Oct 6, 2017 at 9:17 AM, Ian Lepore wrote:
>> It isn't about "a broken port". All C++ code is broken if exceptions
>> don't work. That means devd is broken. Not to mention clang itself.
>> It may be that neither of those relies on excep
On Fri, Oct 6, 2017 at 9:17 AM, Ian Lepore wrote:
> It isn't about "a broken port". All C++ code is broken if exceptions
> don't work. That means devd is broken. Not to mention clang itself.
> It may be that neither of those relies on exceptions for routine
> operation and uses them only for e
On Fri, 2017-10-06 at 09:04 -0700, Conrad Meyer wrote:
> On Thu, Oct 5, 2017 at 9:58 PM, Mark Millard
> wrote:
> >
> > Luckily most kernel and world code that I actively use
> > does not throw C++ exceptions in my use.
> >
> > But devel/kyua is majorly broken by the C++ exception
> > issue: It m
On 2017-Oct-6, at 7:15 AM, Justin Hibbits wrote:
> Hi Mark,
>
> On Thu, Oct 5, 2017 at 11:58 PM, Mark Millard wrote:
>> Warner Losh imp at bsdimp.com wrote on
>> Thu Oct 5 21:01:26 UTC 2017 :
>>
>>> Starting in FreeBSD 11, arm and powerpc are supported by clang,
>>> but not super well. For Fre
On Fri, Oct 6, 2017 at 9:17 AM, Ian Lepore wrote:
> On Fri, 2017-10-06 at 09:04 -0700, Conrad Meyer wrote:
> > On Thu, Oct 5, 2017 at 9:58 PM, Mark Millard
> > wrote:
> > >
> > > Luckily most kernel and world code that I actively use
> > > does not throw C++ exceptions in my use.
> > >
> > > But
On Thu, Oct 5, 2017 at 9:58 PM, Mark Millard wrote:
> Luckily most kernel and world code that I actively use
> does not throw C++ exceptions in my use.
>
> But devel/kyua is majorly broken by the C++ exception
> issue: It makes extensive use of C++ exceptions. In my
> view that disqualifies clang
Hi Mark,
On Thu, Oct 5, 2017 at 11:58 PM, Mark Millard wrote:
> Warner Losh imp at bsdimp.com wrote on
> Thu Oct 5 21:01:26 UTC 2017 :
>
>> Starting in FreeBSD 11, arm and powerpc are supported by clang,
>> but not super well. For FreeBSD 12, we're getting close for everything
>> except sparc64 (
On Thu, Oct 05, 2017 at 11:59:03AM -0700, David Goldblatt wrote:
> Hi all,
>
> The jemalloc developers have wanted to start using C++ for a while, to
> enable some targeted refactorings of code we have trouble maintaining due
> to brittleness or complexity (e.g. moving thousand line macro definit
Warner Losh imp at bsdimp.com wrote on
Thu Oct 5 21:01:26 UTC 2017 :
> Starting in FreeBSD 11, arm and powerpc are supported by clang,
> but not super well. For FreeBSD 12, we're getting close for everything
> except sparc64 (whose fate has not yet been finally decided).
My understanding of the p
I'm guessing a realistic timeline for us would be on the order of 3 to 6
months. We've been dithering on this issue for a while, and your request
seems as good a time as any to get people off the fence...
So, if you are targeting FreeBSD 12, then in that time frame, there'd be no
issues with C++11
In particular, it is expected that FreeBSD 12 will not ship with GCC 4.2 and
that all supported architectures in FreeBSD 12 will be using a C++11-capable
toolchain (either external GCC or in-tree clang). However, older releases
will still be restricted to C++03 (or whatever GCC 4.2 supports) inclu
We can avoid it in the short term without a ton of pain. In the long run it
would be nice to have, but I wouldn't want to tie our release schedule to
FreeBSD's too tightly (our CI is improving to the point where the tip of
the dev branch gets tested about as well as releases would be, so we're
tryi
Today C++11 is a no-go generally due to the lagging architectures needing
gcc 4.2.
However, that answer might change soon. Would it be easy for you to avoid
C++11, or would that cause you significant pain? And what's the timeline
you'd be releasing a new jemalloc requiring this stuff? The answers
(apologies if you receive this twice; I subscribed to the list in order to
flip the needs-moderation bit for my posts).
So it sounds like C++03 (or rather, the version of C++ supported by g++
4.2) will be fine.
Is C++11 a no-go, without breaking libc on non-Clang architectures? (It
isn't clear to
On Thu, Oct 5, 2017 at 2:24 PM, Ian Lepore wrote:
> On Thu, 2017-10-05 at 14:01 -0700, Warner Losh wrote:
> > On Thu, Oct 5, 2017 at 11:59 AM, David Goldblatt
> > wrote:
> >
> > >
> > > Hi all,
> > >
> > > The jemalloc developers have wanted to start using C++ for a while, to
> > > enable some t
On Thu, 2017-10-05 at 14:01 -0700, Warner Losh wrote:
> On Thu, Oct 5, 2017 at 11:59 AM, David Goldblatt
> wrote:
>
> >
> > Hi all,
> >
> > The jemalloc developers have wanted to start using C++ for a while, to
> > enable some targeted refactorings of code we have trouble maintaining due
> > t
On Thu, Oct 5, 2017 at 3:01 PM, Warner Losh wrote:
> On Thu, Oct 5, 2017 at 11:59 AM, David Goldblatt
> wrote:
>
>> Hi all,
>>
>> The jemalloc developers have wanted to start using C++ for a while, to
>> enable some targeted refactorings of code we have trouble maintaining due
>> to brittleness
On Thu, Oct 5, 2017 at 11:59 AM, David Goldblatt
wrote:
> Hi all,
>
> The jemalloc developers have wanted to start using C++ for a while, to
> enable some targeted refactorings of code we have trouble maintaining due
> to brittleness or complexity (e.g. moving thousand line macro definitions
> t
on 25/10/2010 14:23 vol...@vwsoft.com said the following:
> the Vaio P11Z does not boot at all with ACPI enabled so it's disabled in
> loader.conf. The panic messages are various if I try.
I would be interested to look at that problem (or those problems) too.
And now I think that see what the imm
On 10/25/10 13:03, Andriy Gapon wrote:
on 25/10/2010 13:35 vol...@vwsoft.com said the following:
Dear Andriy,
sorry for the delay.
On 10/22/10 11:29, Andriy Gapon wrote:
thanks a lot!
Perhaps, meanwhile you can provide a verbose boot dmesg?
Sure! Please find it at
http://people.freebsd.org/
on 25/10/2010 13:35 vol...@vwsoft.com said the following:
> Dear Andriy,
>
> sorry for the delay.
>
> On 10/22/10 11:29, Andriy Gapon wrote:
>> thanks a lot!
>> Perhaps, meanwhile you can provide a verbose boot dmesg?
>
> Sure! Please find it at
> http://people.freebsd.org/~vwe/misc/Vaio_p11z/dm
Dear Andriy,
sorry for the delay.
On 10/22/10 11:29, Andriy Gapon wrote:
on 22/10/2010 12:09 vol...@vwsoft.com said the following:
On 10/22/10 10:53, Andriy Gapon wrote:
[ping]
Sorry, Andriy!
I haven't found the time to hack yesterday. The Intel website doesn't provide
the 20091221 tarbal
on 22/10/2010 12:09 vol...@vwsoft.com said the following:
> On 10/22/10 10:53, Andriy Gapon wrote:
>>
>> [ping]
>
> Sorry, Andriy!
>
> I haven't found the time to hack yesterday. The Intel website doesn't provide
> the 20091221 tarball anymore (but a more recent one) and I need to lay my
> hands
On 10/22/10 10:53, Andriy Gapon wrote:
[ping]
Sorry, Andriy!
I haven't found the time to hack yesterday. The Intel website doesn't
provide the 20091221 tarball anymore (but a more recent one) and I need
to lay my hands on the script and the code tarball to get it working. As
a result, I ho
[ping]
on 19/10/2010 07:56 Andriy Gapon said the following:
> on 19/10/2010 01:31 vol...@vwsoft.com said the following:
>> Hi Andriy & list!
>>
>> Since rev 213323 my Sony Vaio P11Z was unable to boot up. It broke with a
>> divide
>> by zero in topo_probe_0x4 at line 289 as cpu_logical is 0.
>>
on 19/10/2010 01:31 vol...@vwsoft.com said the following:
> Hi Andriy & list!
>
> Since rev 213323 my Sony Vaio P11Z was unable to boot up. It broke with a
> divide
> by zero in topo_probe_0x4 at line 289 as cpu_logical is 0.
>
> The cpu is an Intel Atom Z520 (single core). System doesn't boot a
Yes, you are right. I see a lot of messages like below in dmesg output:
swap_pager_getswapspace(5): failed
swap_pager_getswapspace(2): failed
swap_pager_getswapspace(2): failed
swap_pager_getswapspace(2): failed
swap_pager_getswapspace(2): failed
swap_pager_getswapspace(2): failed
swap_pager_getsw
On 2010-10-07 12:51, Dmitry Krivenok wrote:
I run ld under gdb and found the place where it fails:
...
Program received signal SIGKILL, Killed.
0x0042e093 in bfd_elf_final_link (abfd=0x800915140, info=0x66c900)
at
/usr/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/b
I run ld under gdb and found the place where it fails:
r...@csx-spb-freebsd9 14:34:22
/usr/src/obj/usr/src/usr.bin/clang/clang # [137] gdb --args
/usr/bin/ld --eh-frame-hdr -V -dynamic-linker /libexec/ld-elf.so.1 -o
clang /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib
-L/usr/lib cc
On 2010-10-07 09:27, Dmitry Krivenok wrote:
c++: Internal error: Killed: 9 (program ld)
Please submit a full bug report.
Seehttp://gcc.gnu.org/bugs.html> for instructions.
r...@csx-spb-freebsd9 11:12:52 /usr/src/obj/usr/src/usr.bin/clang/clang # [1]
Have anyone seen this problem before? Any wor
> Thank you even I have found that out myself too :) Using
> ld directly is a no-go for a gcc3.2 platform. Linking with
> the crt files fixes the problem.
OK, cool. BTW, in case you care, the exact reason why you now need
the startup file wrappers in the shared image with gcc3 style EH but
not wi
Hi,
> the gcc side of things, this is the only supported way to make a C++
> shared image with gcc3 on modern ELF platforms:
Thank you even I have found that out myself too :) Using
ld directly is a no-go for a gcc3.2 platform. Linking with
the crt files fixes the problem.
Martin
To Unsubscribe
>> I do know now why I have again problems with building openoffice.
>> It seems that exceptions over shared libraries are broken again in
>> CURRENT.
>> Alexander, do you have a idea why this got broken again ?
> rtld from 19.October has the same problem. I guess it must be gcc3.2
> which is the
Hi all,
> [EMAIL PROTECTED]:~/cxxtest$ export LD_LIBRARY_PATH=.
> [EMAIL PROTECTED]:~/cxxtest$ ./arf
> abort trap
rtld from 19.October has the same problem. I guess it must be gcc3.2
which is the problem.
Martin
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current"
At 7:01 PM -0500 2/11/03, Garrett Wollman wrote:
< said:
> Trying to use a compiler different from GCC I have found the
> folowing error:
> "/usr/include/sys/syslimits.h", line 42: Error:
> [ISO 6.8]: Unknown preprocessing directive, '#warning'.
It should probably be a #error instead.
* De: Garrett Wollman <[EMAIL PROTECTED]> [ Data: 2003-02-11 ]
[ Subjecte: C conformance. ]
> < said:
>
> > Trying to use a compiler different from GCC I have found the folowing error
> > "/usr/include/sys/syslimits.h", line 42: Error:
> >[ISO 6.8]: Unknown preprocessing directive, '#w
Munish Chopra wrote:
> >It is an ANSI compliant preprocessor directive. Please use an ANSI
> >compliant compiler.
>
> I'd also be curious to know in which version of the ANSI standard you
> have found #warning. I certainly doesn't appear in mine.
I said that the use of the directive was complian
Terry Lambert wrote:
>Marcin Dalecki wrote:
>> Trying to use a compiler different from GCC I have found the folowing
>error
>>
>> "/usr/include/sys/syslimits.h", line 42: Error:
>>[ISO 6.8]: Unknown preprocessing directive, '#warning'.
>>
>> I think that somthing like to above should not appe
On 2003-02-09 19:13 +, Terry Lambert wrote:
> Marcin Dalecki wrote:
> > Trying to use a compiler different from GCC I have found the folowing error
> >
> > "/usr/include/sys/syslimits.h", line 42: Error:
> >[ISO 6.8]: Unknown preprocessing directive, '#warning'.
> >
> > I think that somth
Marcin Dalecki wrote:
> The following ain't pretty as well:
>
> "/usr/include/machine/signal.h", line 130: Error:
>[Syntax]: Parse error before '__aligned'.
>[Syntax]: Can't recover from this error.
You need to add a compiler specific section to /sys/sys/cdefs.h,
which defined cdefs attri
Marcin Dalecki wrote:
> Trying to use a compiler different from GCC I have found the folowing error
>
> "/usr/include/sys/syslimits.h", line 42: Error:
>[ISO 6.8]: Unknown preprocessing directive, '#warning'.
>
> I think that somthing like to above should not appear in system
> headers.
It i
Marcin Dalecki <[EMAIL PROTECTED]> writes:
> Trying to use a compiler different from GCC I have found the folowing error
>
> "/usr/include/sys/syslimits.h", line 42: Error:
>[ISO 6.8]: Unknown preprocessing directive, '#warning'.
>
> I think that somthing like to above should not appear in sy
Cy Schubert - CITS Open Systems Group wrote:
> > does the problem still occur if you add in 'using namespace std'?
>
> Thanks. That also fixed it.
Yeah. Just remember that the "standard" namespace isn't.
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current
In message <002501c298d3$63c3c150$[EMAIL PROTECTED]>, "Matthew
Emmerton" w
rites:
> > In message <[EMAIL PROTECTED]>
> > , Garret
> > t Rooney writes:
> > > > The following program builds and runs under 4.7-STABLE:
> > > >
> > > > #include
> > > >
> > > > int main()
> > > > {
> > > > cout
> In message <[EMAIL PROTECTED]>
> , Garret
> t Rooney writes:
> > > The following program builds and runs under 4.7-STABLE:
> > >
> > > #include
> > >
> > > int main()
> > > {
> > > cout<<"Hello World\n";
> > > }
> > >
> > > ... but under 5.0-CURRENT it gives me the following errors:
> >
In message <[EMAIL PROTECTED]>
, Garret
t Rooney writes:
> > The following program builds and runs under 4.7-STABLE:
> >
> > #include
> >
> > int main()
> > {
> > cout<<"Hello World\n";
> > }
> >
> > ... but under 5.0-CURRENT it gives me the following errors:
> >
> > cwtest$ g++ -o foo foo
In message <[EMAIL PROTECTED]>, Craig Rodrigues writes:
> On Sat, Nov 30, 2002 at 03:48:00PM -0800, Cy Schubert - CITS Open Systems Gro
> up wrote:
> > I've been working on getting the tripwire port to build on -CURRENT.
> > Through this process I've stumbled across an issue. Searching through
>
On Sat, Nov 30, 2002 at 03:48:00PM -0800, Cy Schubert - CITS Open Systems Group wrote:
> I've been working on getting the tripwire port to build on -CURRENT.
> Through this process I've stumbled across an issue. Searching through
> the mailing lists, I haven't found a solution to this.
>
> The f
The following program builds and runs under 4.7-STABLE:
#include
int main()
{
cout<<"Hello World\n";
}
... but under 5.0-CURRENT it gives me the following errors:
cwtest$ g++ -o foo foo.cc
foo.cc: In function `int main()':
foo.cc:5: `cout' undeclared (first use this function)
foo.cc:5:
Do you have cleaned your /usr/include/g++ directory from old gcc files?
Jan
On Wed, 2002-06-19 at 04:12, Charlie Root wrote:
> Trying to build kdebase3 on the
> FreeBSD 5.0-CURRENT #7: Mon Jun 17 22:46:16 EDT 2002
>
> [...]
> gmake[4]: Nothing to be done for `all-am'.
> gmake[4]: Leaving
Charlie Root wrote:
> Trying to build kdebase3 on the
> FreeBSD 5.0-CURRENT #7: Mon Jun 17 22:46:16 EDT 2002
>
> [...]
> gmake[4]: Nothing to be done for `all-am'.
> gmake[4]: Leaving directory
>`/ccd/ports/x11/kdebase3/work/kdebase-3.0.1/kappfinder/apps'
> gmake[3]: Leaving directory
>`/
In the last episode (Jun 18), David O'Brien said:
> On Sun, Jun 16, 2002 at 07:31:56AM +0200, Michael Nottebrock wrote:
> > I just hit the same problem while trying to compile KDE stuff. In my
> > case it stems from bsd.kde.mk adding -I/usr/include to CPPFLAGS
>
> Why in the (*_#$ did someone ma
On Sun, Jun 16, 2002 at 07:31:56AM +0200, Michael Nottebrock wrote:
> I just hit the same problem while trying to compile KDE stuff. In my
> case it stems from bsd.kde.mk adding -I/usr/include to CPPFLAGS
Why in the (*_#$ did someone make bsd.kde.mk do that??
To Unsubscribe: send mail to [EMAIL
On Sun, Jun 16, 2002 at 07:31:56 +0200, Michael Nottebrock wrote:
>
> I just hit the same problem while trying to compile KDE stuff. In my
> case it stems from bsd.kde.mk adding -I/usr/include to CPPFLAGS, causing
> gcc to change its include search order. Lacking further insight, I don't
> kno
Wesley Morgan wrote:
> I cleaned up my /usr/lib and /usr/include file of stale headers/libs left
> after the libstdc++ upgrade (maybe this should be in src/UPDATING??), and
> now any port that uses C++ & autoconf fails to configure...
>
> checking if STL implementation is SGI like... no
> checkin
Assar Westerlund wrote:
>
> There's a real reason for not writing this in csh. Because the
> built-in function will return results for csh, which might not be the
> right ones for other shells.
>
I got bitten by this by HP-UX 10's csh-based "which". My solaris-hosted
NFS home directory had the d
< said:
> Sure, but there's a /usr/bin/which program. Do you suggest we should
> remove it? I don't have any problems with that...
The original `which' was a C shell script. Its purpose was
specifically to explain how the C shell would locate a particular
command. That's why the Korn shell i
Garrett Wollman <[EMAIL PROTECTED]> writes:
> The error is in using `which' with another shell. The correct command
> to use with POSIX-ish shells (sh, ksh, bash, etc.) is `type'.
Sure, but there's a /usr/bin/which program. Do you suggest we should
remove it? I don't have any problems with tha
< said:
> There's a real reason for not writing this in csh. Because the
> built-in function will return results for csh, which might not be the
> right ones for other shells.
The error is in using `which' with another shell. The correct command
to use with POSIX-ish shells (sh, ksh, bash, etc
"David O'Brien" <[EMAIL PROTECTED]> writes:
> I do know about this FAQ, however for a very simple script that is just
> passing arguments to a built-in function.
There's a real reason for not writing this in csh. Because the
built-in function will return results for csh, which might not be t
On Fri, Mar 03, 2000 at 10:09:17AM +0100, Patrick M. Hausen wrote:
> Most probably because C shell scripts should be avoided at any
> cost.
>
> See: http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/
I do know about this FAQ, however for a very simple script that is just
passing arguments to a
On Sat, Jan 22, 2000 at 08:21:21AM -0800, David O'Brien wrote:
> Good news, a fix has been imported and merged.
If I read the PR correctly, it states that ports like Mico were broken
on account of this?
And you just today fixed this? The reason I'm asking is because Mico
seems to break when I co
On Tue, Jan 11, 2000 at 01:37:39PM +0200, Maxim Sobolev wrote:
> It seems than long-standing problem (see PR dated May '97:
> http://www.FreeBSD.org/cgi/query-pr.cgi?pr=3441) with C++ exceptions in shared
Good news, a fix has been imported and merged.
--
-- David([EMAIL PROTECTED])
To Uns
Without -fsjlj-exception flag under Linux program bails out with SIGABRT and
dumps core - most likely because C++ runtime call terminate() somewhere. I do
not think this has any relation to the problem I fixed but rather it has
soething to do with faulty rtti exception type matching code. I believ
On Mon, Jan 17, 2000 at 09:07:28PM -0500, Alexander N. Kabaev wrote:
> Compiled without -fsjlj-exceptions, it dumps core.
Exactly same as FreeBSD, in the same place?
> I will be greatly surprised if OpenBSD will survive the test since
> their egcs looks like stock egcs 1.1.2 version which has n
> Why doesn't OpenBSD, Linux, or Solaris x86 need this patch?
I tried to compile and run attached program on dual-processor Compaq
Proliant server running RedHat Linux 6.1 at Compaq testdrive site (thanks,
Compaq!) and guess what? Compiled with -fsjlj-exceptions Linux bails out with
"Not enough m
Well,
I cannot comment on OpenBSD or Solaris, since I do not have access to them
right now. My guess is that OpenBSD and Solaris x86 either
1. do not use sjlj exception propagation, or
2. do not use _builtin_setjmp
Linux does not use sjlj exceptions for sure and as a result it is not affect
On Mon, Jan 17, 2000 at 02:51:00PM -0500, Alexander N. Kabaev wrote:
> As I already pointed out in private message, this bug is in fact i386
> specific and it was wrong to fix it in gcc/except.c file. The real
> problem is that default builtin_setjmp implementation does not restore
> any registers
As I already pointed out in private message, this bug is in fact i386 specific
and it was wrong to fix it in gcc/except.c file. The real problem is that
default builtin_setjmp implementation does not restore any registers except for
stack pointers when doing nonlocal jump. This means, that every p
On Mon, Jan 17, 2000 at 08:28:23PM +0200, Maxim Sobolev wrote:
> > Index: contrib/gcc/except.c
> > ===
> > RCS file: /home/ncvs/src/contrib/gcc/except.c,v
> > [Nice patch stripped]
>
> Yeah, it works! (at least at a first glance). Da
"Alexander N. Kabaev" wrote:
> As promised, I tried to look into the problem little futher. The following
> patch fixes all crashes for me and I was unable to reproduce the bug anymore. I
> would really like to hear if it works for you too. I am especially interested
> to know if it works on Alph
As promised, I tried to look into the problem little futher. The following
patch fixes all crashes for me and I was unable to reproduce the bug anymore. I
would really like to hear if it works for you too. I am especially interested
to know if it works on Alpha, because I cannot test it myself.
P
I am sorry, my previous letter was incorrect. Compiling libgcc{_r}.a
without optimisation stopped _my_ test program and the program from PR from
crashing, but any attempt to rethrow the exception from the catch block in
Foo() results in signal 11 crash.
--
E-Mail:
Well, I tried to investigate this problem and the following is what I've found
so far: It looks like we are dealing with gcc -O code generation bug. I
recompiled libgcc and libgcc_r without -O flag and everything works just fine,
including the sample from PR3441. Unfortunately, I was unable to loc
In article <[EMAIL PROTECTED]>,
David O'Brien <[EMAIL PROTECTED]> wrote:
> On Wed, Jan 12, 2000 at 10:01:42AM +0200, Maxim Sobolev wrote:
> > Is there are any compiler guys to address my question or not?
>
> There is, I'm the one. But there are a few things ahead in the queue.
> Of course a patc
David O'Brien wrote:
> On Wed, Jan 12, 2000 at 10:01:42AM +0200, Maxim Sobolev wrote:
> > Is there are any compiler guys to address my question or not?
>
> There is, I'm the one. But there are a few things ahead in the queue.
Please excuse me if I've offended you, but I just doubted that no one
On Wed, Jan 12, 2000 at 10:01:42AM +0200, Maxim Sobolev wrote:
> Is there are any compiler guys to address my question or not?
There is, I'm the one. But there are a few things ahead in the queue.
Of course a patch would make things go much faster.
--
-- David([EMAIL PROTECTED])
To Unsu
Maxim Sobolev wrote:
> Hi,
>
> It seems than long-standing problem (see PR dated May '97:
> http://www.FreeBSD.org/cgi/query-pr.cgi?pr=3441) with C++ exceptions in shared
> libraries is still here. It affects both -current and -stable branches and
> prevents some modern software (Mico for example
On Wed, 29 Sep 1999, Martin Nilsson wrote:
> mysql-3.23.3 cc1plus reports out of swap space and exits when
> compiling sql_yacc.cc
add mode swap space using swapfile parameter in /etc/rc.conf or manually,
with vnconfig/swapon commands. mysql will normally compile.
sincerely,
ilya naumov (at
> /usr/lib/libstdc++.so: undefined reference to `filebuf virtual table'
> /usr/lib/libstdc++.so: undefined reference to `stdiobuf virtual table'
> *** Error code 1
>
> That is the error I got when I tried to compile a program for my C++
> class.
You need to update your source. This was fixed last
> im having problems compiling the giCQ port under 4.0-current.
> configuration says my C++ compiler cannot create executables, any idea
> what's the problem ?
On the bootstrap `make world' to EGCS libstdc++ is broken. Do a second
`make world' and you will have a working system.
I know what the
Read the recent posts. Let me guess, you have probably done a fairly recent
cvsup (sunday evening?) and you built world. You now have egcs as your
compiler (gcc -v). The best thing to do, at least the easiest to tell you
to do, is to simply cvsup the sources again and make the world. You
probab
> > configure:1333: c++ -o conftestconftest.C 1>&5
> > /usr/lib/libstdc++.so: undefined reference to `filebuf virtual table'
> > /usr/lib/libstdc++.so: undefined reference to `stdiobuf virtual table'
> Some people are getting these errors, but I'm not sure why. It comes
Never mind, I fixed t
> configure:1333: c++ -o conftestconftest.C 1>&5
> /usr/lib/libstdc++.so: undefined reference to `filebuf virtual table'
> /usr/lib/libstdc++.so: undefined reference to `stdiobuf virtual table'
Some people are getting these errors, but I'm not sure why. It comes
from not compiling the compil
> /tmp/x> c++ test.c
The the list as a whole. For the next week or so, please use the "-v"
flag when reporting compiler problems.
--
-- David(obr...@nuxi.com -or- obr...@freebsd.org)
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the
On 05-Apr-99 Pierre Y. Dampure wrote:
> Jeroen Ruigrok/Asmodai wrote:
>>
>> Those errors are still present.
>>
>
> Wrong:
>
> [(dampurep)~/src]: c++ -Os -march=pentiumpro -o hello hello.cc
> [(dampurep)~/src]: ./hello
> Hello World!!!
>
> [(dampurep)~/src]:
OK, they were/are present here
Veldhouse
ve...@visi.com
-Original Message-
From: Pierre Y. Dampure
To: Jeroen Ruigrok/Asmodai
Cc: Blaz Zupan ; freebsd-current@FreeBSD.ORG
Date: Monday, April 05, 1999 1:51 PM
Subject: Re: C++ with egcs - no go
>Jeroen Ruigrok/Asmodai wrote:
>>
>> Those errors are still prese
Jeroen Ruigrok/Asmodai wrote:
>
> Those errors are still present.
>
Wrong:
[(dampurep)~/src]: cat
hello.cc // begin
program
#include
using namespace std;
int main(int argc, char** argv) {
cout << "Hello World!!!\n" << endl;
re
1 - 100 of 103 matches
Mail list logo
