Re: C++ in jemalloc

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

Re: C++ in jemalloc

[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

Re: C++ in jemalloc

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.

Re: C++ in jemalloc

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

Re: C++ in jemalloc

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

Re: C++ in jemalloc

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

Re: C++ in jemalloc

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

Re: C++ in jemalloc

[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.

Re: C++ in jemalloc

[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

Re: C++ in jemalloc

[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

Re: C++ in jemalloc

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: >

Re: C++ in jemalloc

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

Re: C++ in jemalloc

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

Re: C++ in jemalloc

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++

Re: C++ in jemalloc

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

Re: C++ in jemalloc

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

Re: C++ in jemalloc

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

Re: C++ in jemalloc

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

Re: C++ in jemalloc

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

Re: C++ in jemalloc

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

Re: C++ in jemalloc

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

Re: C++ in jemalloc

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)

Re: C++ in jemalloc

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

Re: C++ in jemalloc

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

Re: C++ in jemalloc

(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

Re: C++ in jemalloc

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

Re: C++ in jemalloc

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 > >

Re: C++ in jemalloc

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

Re: C++ in jemalloc

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

Re: c 213323 breaks Sony Vaio P11Z w/o acpi

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

Re: c 213323 breaks Sony Vaio P11Z w/o acpi

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

Re: c 213323 breaks Sony Vaio P11Z w/o acpi

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

Re: c 213323 breaks Sony Vaio P11Z w/o acpi

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

Re: c 213323 breaks Sony Vaio P11Z w/o acpi

[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. The cpu is

Re: c 213323 breaks Sony Vaio P11Z w/o acpi

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

Re: c 213323 breaks Sony Vaio P11Z w/o acpi

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 the

Re: c 213323 breaks Sony Vaio P11Z w/o acpi

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 at all

Re: c++: Internal error: Killed: 9 (program ld)

On 2010-10-07 09:27, Dmitry Krivenok wrote: c++: Internal error: Killed: 9 (program ld) Please submit a full bug report. SeeURL:http://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

Re: c++: Internal error: Killed: 9 (program ld)

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

Re: c++: Internal error: Killed: 9 (program ld)

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

Re: c++: Internal error: Killed: 9 (program ld)

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

Re: C++ Exception handling with shared libs in current is brokenagain

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 in

Re: C++ Exception handling with shared libs in current is broken again

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 problem.

Re: C++ Exception handling with shared libs in current is brokenagain

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:

Re: C++ Exception handling with shared libs in current is broken again

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 with

Re: C conformance.

* De: Garrett Wollman [EMAIL PROTECTED] [ Data: 2003-02-11 ] [ Subjecte: C conformance. ] On Sun, 09 Feb 2003 19:43:38 +0100, Marcin Dalecki [EMAIL PROTECTED] said: Trying to use a compiler different from GCC I have found the folowing error /usr/include/sys/syslimits.h, line 42:

Re: C conformance.

At 7:01 PM -0500 2/11/03, Garrett Wollman wrote: On Sun, 09 Feb 2003, Marcin Dalecki [EMAIL PROTECTED] 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,

Re: C conformance.

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 system

Re: C conformance.

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 is an

Re: C conformance

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 attributes

Re: C conformance.

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 somthing like to

Re: C conformance.

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 appear in system

Re: C conformance.

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 compliant, not

Re: C++ Issue On -CURRENT

The following program builds and runs under 4.7-STABLE: #include iostream int main() { coutHello 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)

Re: C++ Issue On -CURRENT

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

Re: C++ Issue On -CURRENT

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 the

Re: C++ Issue On -CURRENT

In message [EMAIL PROTECTED] , Garret t Rooney writes: The following program builds and runs under 4.7-STABLE: #include iostream int main() { coutHello World\n; } ... but under 5.0-CURRENT it gives me the following errors: cwtest$ g++ -o foo foo.cc foo.cc: In

Re: C++ Issue On -CURRENT

In message [EMAIL PROTECTED] , Garret t Rooney writes: The following program builds and runs under 4.7-STABLE: #include iostream int main() { coutHello World\n; } ... but under 5.0-CURRENT it gives me the following errors: cwtest$ g++ -o foo foo.cc

Re: C++ Issue On -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 iostream int main() { coutHello World\n; }

Re: C++ Issue On -CURRENT

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

Re: C++ troubles continue

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

Re: C++ problems

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

Re: C++ problems

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 make

Re: C++ troubles continue

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

Re: C++ problems

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 know

Re: C++ problems

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 checking if

Re: C shell scripts (was: Re: which(1), rewritten in C?)

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

Re: C++ exceptions doesn't work in shared libraries

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

Re: C++ exceptions doesn't work in shared libraries

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

Re: C++ exceptions doesn't work in shared libraries

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). David, what

Re: C++ exceptions doesn't work in shared libraries

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

Re: C++ exceptions doesn't work in shared libraries

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

Re: C++ exceptions doesn't work in shared libraries

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.

Re: C++ exceptions doesn't work in shared libraries

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 patch would

Re: C++ exceptions doesn't work in shared libraries

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

Re: C++ exceptions doesn't work in shared libraries

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:

Re: C++ exceptions doesn't work in shared libraries

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

Re: C++ exceptions doesn't work in shared libraries

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 has

Re: C++ compiler not working in yesterdays current.

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

Re: c++ broken??

/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

Re: C++ cannot create executables ?

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

Re: C++ cannot create executables ?

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

RE: C++ with egcs - no go

On 05-Apr-99 Blaz Zupan wrote: /tmp/x c++ test.c /usr/lib/libstdc++.so: undefined reference to `filebuf virtual table' /usr/lib/libstdc++.so: undefined reference to `stdiobuf virtual table' /tmp/x Anybody else seeing this after the latest cvsup (as of 15 minutes ago)? Those errors are

Re: C++ with egcs - no go

Jeroen Ruigrok/Asmodai wrote: Those errors are still present. Wrong: [(dampurep)~/src]: cat hello.cc // begin program #include iostream using namespace std; int main(int argc, char** argv) { cout Hello World!!!\n endl;

Re: C++ with egcs - no go

Veldhouse ve...@visi.com -Original Message- From: Pierre Y. Dampure pierre.damp...@k2c.co.uk To: Jeroen Ruigrok/Asmodai asmo...@wxs.nl Cc: Blaz Zupan b...@gold.amis.net; freebsd-current@FreeBSD.ORG freebsd-current@FreeBSD.ORG Date: Monday, April 05, 1999 1:51 PM Subject: Re: C++ with egcs - no go

Re: C++ with egcs - no go

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 =) glad to

Re: C++ with egcs - no go

/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

Re: C++

configure:1333: c++ -o conftestconftest.C 15 /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 compiler

Re: C++

configure:1333: c++ -o conftestconftest.C 15 /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 the

Re: C++ compliler unable to produce excutables

Do you have egcs or gcc-2.8 or anything else installaed that installs /usr/local/bin/g++? yes, that's the one I really recently installed I was suspecious about it, but now you confirmed it. Such extra compilers from ports tend to break. Make sure you use /usr/bin/g++. Thanks -- -

Re: C++ compliler unable to produce excutables

In pine.bsf.4.05.9901191201190.22232-100...@access1_1.kuniv.edu.kw, Joss Roots wrote: Hi there, Some ports are complaining during early configuration phase using configure that c++ compiler is unable to produce excutables, and the options are -O -pipe is there anything I am missing here, as