> On 9/9/14, Camm Maguire wrote:
> Could you gzip it and attach? i.e.
>
> cpp -Ih o/usig.c | gzip -9 >/tmp/out.gz
Have attached both files: error during make and the cpp output.
gNewSense is based on Debian Squeeze (6.0), quite outdated. May be
that is the reason. I wil be installing some other
On Tue, Sep 9, 2014 at 1:36 PM, Jerry James wrote:
> Oh, wait! I didn't notice that the previous recipe (calling the
> function from use_symbols) *worked*, and it is now complaining about
> __aeabi_unwind_cpp_pr0. That is, it's a different symbol, ending with
> a zero instead of a 1 now. Sorry
On Tue, Sep 9, 2014 at 11:42 AM, Camm Maguire wrote:
> Can you please post
>
> nm o/sfasl.o |grep __aeabi_unwind_cpp_pr1
Oh, wait! I didn't notice that the previous recipe (calling the
function from use_symbols) *worked*, and it is now complaining about
__aeabi_unwind_cpp_pr0. That is, it's a d
Greetings! One other note, if you edit use_symbols, you have to put the
call in so that it will not be optimized away. Specifically, if it
returns a value, you should use it. Or you can compile with -g to test.
Jerry James writes:
> On Tue, Sep 9, 2014 at 10:01 AM, Jerry James wrote:
>> On T
Greetings!
Jerry James writes:
> On Tue, Sep 9, 2014 at 10:01 AM, Jerry James wrote:
>> On Tue, Sep 9, 2014 at 9:09 AM, Camm Maguire wrote:
>>> Alternatively, you could edit the function use_symbols in sfasli.c and
>>> put in dummy calls to the functions you need.
>>
>> I will try this next.
>
Greetings, and thanks for your reply!
arnuld uttre writes:
>> On 9/9/14, Camm Maguire wrote:
>
>> Greetings! Thanks for your report -- nice to meet a gNewSense user!
>
> It is nice to see GCL developing too :)
>
>
>> This is a Debian based target. On my Debian machine, ucontext_t is
>> broght
On Tue, Sep 9, 2014 at 10:01 AM, Jerry James wrote:
> On Tue, Sep 9, 2014 at 9:09 AM, Camm Maguire wrote:
>> Alternatively, you could edit the function use_symbols in sfasli.c and
>> put in dummy calls to the functions you need.
>
> I will try this next.
That didn't work either. Still the same
> On 9/9/14, Camm Maguire wrote:
> Greetings! Thanks for your report -- nice to meet a gNewSense user!
It is nice to see GCL developing too :)
> This is a Debian based target. On my Debian machine, ucontext_t is
> broght in by signal.h. The output of the following will help:
>
> grep -r uco
On Tue, Sep 9, 2014 at 9:09 AM, Camm Maguire wrote:
> In truth, I am not sure if this work around is relying on an artifact of
> ld, but nevertheless, the latter is currently writing the needed symbols
> when thus invoked. If you modify configure.in to add TLIBS="$TLIBS
> -lgcc_s"; for your machi
Greetings! Thanks for your report -- nice to meet a gNewSense user!
This is a Debian based target. On my Debian machine, ucontext_t is
broght in by signal.h. The output of the following will help:
grep -r ucontext_t /usr/include
Presumably this structure was already correctly found in the pre
Greetings!
GCL parses its own elf symbol table when constructing the saved image
for subsequent use in linking. The general idea (in 2.6.x) is that
loaded compiled code will only refer directly to symbols in the base
image.
There are two machines, hppa and aarch64, which wind up needing helper
On Tue, Sep 9, 2014 at 2:03 AM, Will Newton wrote:
> It's possible that this patch might fix it:
>
> http://lists.gnu.org/archive/html/gcl-devel/2014-07/msg00030.html
Unfortunately, no, the build failed in exactly the same way after
applying that patch. On the other hand, I do not see the string
On 9 September 2014 04:12, Jerry James wrote:
> Hi,
>
> I attempted to build gcl 2.6.11 for Fedora tonight. The builds for
> i386 and x86_64 seem fine, but the 32-bit ARM build failed, like so:
>
> Finished compiling /builddir/build/BUILD/gcl/unixport/../pcl/gcl_pcl_pkg.o.
> Loading binary of GCL
13 matches
Mail list logo
