Monday, 18 August 2014

libhubbub: allow build with json-c 0.12

>From 13bd4b9cc2e311b43f49b0e6f002dc738a779cb9 Mon Sep 17 00:00:00 2001
From: David Tardon <dtardon@redhat.com>
Date: Mon, 18 Aug 2014 12:46:44 +0200
Subject: [PATCH] allow build with json-c 0.12

The library, the include dir and the .pc file were renamed from json to
json-c a few releases ago, but the old names were kept for backwards
compatibility. They were finally removed in version 0.12.
---
Makefile | 18 ++++++++++++++----
1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/Makefile b/Makefile
index 4ec03f3..afbbe46 100644
--- a/Makefile
+++ b/Makefile
@@ -46,13 +46,23 @@ include $(NSBUILD)/Makefile.top
ifeq ($(WANT_TEST),yes)
# We require the presence of libjson -- http://oss.metaparadigm.com/json-c/
ifneq ($(PKGCONFIG),)
+ # The pkgconfig file name has changed from json.pc to json-c.pc
+ JSONC_CFLAGS := $(shell $(PKGCONFIG) $(PKGCONFIGFLAGS) --cflags json-c)
+ JSONC_LIBS := $(shell $(PKGCONFIG) $(PKGCONFIGFLAGS) --libs json-c)
+ JSON_CFLAGS := $(shell $(PKGCONFIG) $(PKGCONFIGFLAGS) --cflags json)
+ JSON_LIBS := $(shell $(PKGCONFIG) $(PKGCONFIGFLAGS) --libs json)
TESTCFLAGS := $(TESTCFLAGS) \
- $(shell $(PKGCONFIG) $(PKGCONFIGFLAGS) --cflags json)
+ $(if $(strip $(JSONC_CFLAGS)),$(JSONC_CFLAGS),$(JSON_CFLAGS))
TESTLDFLAGS := $(TESTLDFLAGS) \
- $(shell $(PKGCONFIG) $(PKGCONFIGFLAGS) --libs json)
+ $(if $(strip $(JSONC_LIBS)),$(JSONC_LIBS),$(JSON_LIBS))
else
- TESTCFLAGS := $(TESTCFLAGS) -I$(PREFIX)/include/json
- TESTLDFLAGS := $(TESTLDFLAGS) -ljson
+ ifeq ($(wildcard $(PREFIX)/include/json-c/json.h),)
+ TESTCFLAGS := $(TESTCFLAGS) -I$(PREFIX)/include/json
+ TESTLDFLAGS := $(TESTLDFLAGS) -ljson
+ else
+ TESTCFLAGS := $(TESTCFLAGS) -I$(PREFIX)/include/json-c
+ TESTLDFLAGS := $(TESTLDFLAGS) -ljson-c
+ endif
endif

ifneq ($(GCCVER),2)
--
1.9.3

Hi,

the attached patch fixes ${SUBJECT}.

D.

Re: [gccsdk] C++ exceptions not working with GCCSDK 4.7

> On Sat, 16 Aug 2014 14:25:24 +0100 Lee Noar wrote:
>
> On 15/08/14 14:59, Alan Buckley wrote:
> > I seem to be having a problem with programs not catching C++ exceptions
> > when compiled with GCCSDK 4.7.
>
> [snip]
>
> > Can anyone else confirm this isn't working?
>
> I can't reproduce this. I've tried both the cross compiler and the
> native compiler running in RPCEmu which I also use to run the result.
>
> It looks like the same thing that Duncan reported in bug#256 (which I
> can't reproduce either).
>
> Are you running in VirtualRPC by any chance?

I'm running on RPCEmu (the latest release) with RISC OS 4.02 (from the nearly
free product from ROL) with the Castle 32 bit System installed.

Regards,
Alan

Saturday, 16 August 2014

Re: [gccsdk] C++ exceptions not working with GCCSDK 4.7

On 15/08/14 14:59, Alan Buckley wrote:
> I seem to be having a problem with programs not catching C++ exceptions
> when compiled with GCCSDK 4.7.

[snip]

> Can anyone else confirm this isn't working?

I can't reproduce this. I've tried both the cross compiler and the
native compiler running in RPCEmu which I also use to run the result.

It looks like the same thing that Duncan reported in bug#256 (which I
can't reproduce either).

Are you running in VirtualRPC by any chance?

Lee.


_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

Friday, 15 August 2014

[gccsdk] C++ exceptions not working with GCCSDK 4.7

I seem to be having a problem with programs not catching C++ exceptions
when compiled with GCCSDK 4.7.
Full version:
(GCCSDK GCC 4.7.4 Release 1 Development) 4.7.4 20140527 (
prerelease) [gcc-4_7-branch revision 210956]
 
The following simple program (main.cc) will crash rather than catch
the exception as expected.
 
#include <iostream>
#include <stdexcept>
 
int main(int argc, char *argv[])
{
    try
    {
        std::cout << "Before throw" << std::endl;
        throw std::runtime_error("Test throw and catch");
    } catch(...)
    {
        std::cout << "Caught thrown exception as expected\n" << std::endl;
    }
    std::cout << "After try/catch block" << std::endl;
}
 
I'm compiling it using the following makefile.
 
# Makefile for exceptcrash
 
SRC=main.cc
CXX=~/gccsdk/cross/bin/arm-unknown-riscos-g++
CXXFLAGS= -O2 -mthrowback
TARGET=exceptnotcaught
 
 
all:    $(TARGET)
 
$(TARGET):    $(SRC:.cc=.o)
    $(CXX)  -static $(SRC:.cc=.o) -o $(TARGET)ELF,e1f
    ~/gccsdk/cross/bin/elf2aif $(TARGET)ELF,e1f $(TARGET),ff8
 
 
The ELF version crashes as well at the aif version.
 
The output from the program is:
 
Before throw
terminate called after throwing an instance of 'std::runtime_error'
terminate called recursively
 
Fatal signal received: Aborted
 
Stack backtrace:
 
Running thread 0x84968
  (  c56e84) pc:    6c774 lr:    6cc18 sp:   c56e88  __write_backtrace()
  (  c56ef4) pc:    6c890 lr:    6cf7c sp:   c56ef8  __unixlib_raise_signal()
  (  c56f04) pc:    6cf60 lr:    536cc sp:   c56f08  raise()
  (  c56f18) pc:    53690 lr:    3d1e4 sp:   c56f1c  abort()
  (  c56f38) pc:    3d118 lr:    34b08 sp:   c56f3c  __gnu_cxx::__verbose_terminate_handler()()
  (  c56f48) pc:    34afc lr:    34b60 sp:   c56f4c  __cxxabiv1::__terminate(void (*)())()
  (  c56f8c) pc:    3d114 lr:    34b08 sp:   c56f90  __gnu_cxx::__verbose_terminate_handler()()
  (  c56f9c) pc:    34af8 lr:    34b60 sp:   c56fa0  __cxxabiv1::__terminate(void (*)())()
  (  c56fec) pc:     84f0 lr:    5828c sp:   c56ff0  main()
 
 
Can anyone else confirm this isn't working?
 
Regards,
Alan
 

Friday, 8 August 2014

[gccsdk] New riscos.info directions and prospective disruption

As some of you may have noticed, riscos.info has been suffering some
unreliability problems: usually what happens is that SpamAssassin causes it
to exhaust its memory and become wedged.

I've recently taken over administration of riscos.info from Peter Naulls,
and my first job is to fix this. As part of this process I also intend to
move hosts, as part of a longer-term plan to partition services over
different servers so this becomes less of an issue.

I intend to do most of this work in the background, but it will entail a
certain amount of disruption so various databases (SVN, wiki etc) are kept
consistent. Due to limited time on my part, I may have to schedule some
downtime at relatively short notice.

I'm intending to start this process this weekend, and riscos.info should be
assumed to be vulnerable over that period. There's currently no external
server status page, but I'll update:
http://www.markettos.org.uk/riscos.info/
as I go.

If there's any problems, do email me.
(This mailing list may not work during disruption, for obvious reasons)

Theo

_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

Monday, 4 August 2014

Re: [gccsdk] Pthreads barrier

In message <53DF700A.9060506@mesham.com>
Nick Brown <nick@mesham.com> wrote:

> I'm trying to compile a Linux code which uses pthreads, it all seems
> fine apart from not being able to find barrier support (
> pthread_barrier_t and associated functions.) I've had a look in the
> pthreads.h include file that ships with the RISC OS version of GCC and
> it seems like barriers are missing from it. I can work around this by
> implementing my own barrier in the code but before I do this, to avoid
> any duplication, was wondering if it has been implemented and is just
> somewhere else?

I'm not aware of pthread barrier support in UnixLib. Awaiting
contributions ;-)

John.
--
John Tytgat, in his comfy chair at home
John.Tytgat@aaug.net

_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

[gccsdk] Pthreads barrier

Hi all,

I'm trying to compile a Linux code which uses pthreads, it all seems
fine apart from not being able to find barrier support (
pthread_barrier_t and associated functions.) I've had a look in the
pthreads.h include file that ships with the RISC OS version of GCC and
it seems like barriers are missing from it. I can work around this by
implementing my own barrier in the code but before I do this, to avoid
any duplication, was wondering if it has been implemented and is just
somewhere else?

Cheers,
Nick

_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK