[gccsdk] flex & recent !UnixLib, as

John Tytgat John.Tytgat at aaug.net
Tue Feb 13 23:07:59 GMT 2007


In message <b279b8b44e.admin at snowstone.org.uk>
          Adam <lists at snowstone.org.uk> wrote:

> I'm trying to compile WinEd using GCC (3.4.6 rel. 2) but have got stuck
> at the linking stage. WinEd uses the Castle flex library, which I don't
> have so I'm using Jason Tribbeck's flex library instead:
> http://rovlib.tribbeck.com/api/flex-frame.html
> 
> I get:
> 
> gcc      -o !RunImage  -Wl,-via @.Sourcery.Via
> Warning: Attributes of area 'C$$code' in '/home/john/gccsdk/gccsdk_svn/gcc/arm-riscos-aof/gcc-3_4/libgcc/stage2/apcs32/abs/unixlib/divsi3.o' conflict with those in 'o32.flex' 
>     /home/john/gccsdk/gccsdk_svn/gcc/arm-riscos-aof/gcc-3_4/libgcc/stage2/apcs32/abs/unixlib/divsi3.o:  Code, Read only, 32-bit APCS, Extended FP instructions 
>     o32.flex:  Code, Read only, 32-bit APCS 

See below.

> Error: The following symbols could not be found: 
>     '_kernel_register_slotextend' referenced in 'o32.flex' 
> Drlink: Link failed with 1 error 
> ld fatal error: program /gccpkg:bin/drlink returned exit status 3072:
> 
> ...which suggests maybe there's a clash between flex and gcc?

No this is not a compiler issue but a runtime issue. You are using UnixLib
as runtime library which does not have all SharedCLibrary _kernel_* calls
(like _kernel_register_slotextend), let alone that UnixLib is fully
compatible with binary libraries built with SharedCLibrary headers.

With other words: you can not use flex (which is a given binary library
using SharedCLibrary headers) and UnixLib together.  Solution: use the SCL
runtime library by specifying -mlibscl option in the compile and link line
used.

> I've not
> been able to find anything like o32.flex (or divsi3?) though. How can I
> tell what exactly is clashing?

The former is part of Castle flex library, the latter is part of UnixLib
library.  Both binaries are marked with the settings used during
compilation and/or specifics used in the source itself (pardon me, I'm a
bit simplifying this) and the difference here is "Extended FP instructions"
which is not something to really worry about now.

The linker is a bit too strong in its warnings here (and I have to blame
myself here as I've made it more pedantic over time). With other words:
you can ignore this but as soon as you're using SCL as runtime library
I don't think you will see this warning again.

> On a (mostly) separate note. In trying to solve this, I've downloaded a
> complete fresh copy of GCC from:
> http://www.riscos.info/index.php/GCC_for_RISC_OS
> 
> However, I've not been able to find replacements for my copy of !UnixLib
> or "as" (which is present in my existing copy of GCC).
> I've looked in:  http://www.riscos.info/downloads/gccsdk/latest/
> and:             http://www.riscos.info/downloads/gccsdk/sharedunixlib/

We've stopped supplying a separate !UnixLib distribution as there is no
need for this.  !GCC distribution contains an up-to-date UnixLib internally
and supplying !UnixLib separately only confuses people.

'as' is part of !GCC as well and you're can invoke it via "gcc" just like
you would compile a C file (like "gcc -o my_obj.o -c my_assember_file.s").
The file extension ".s" determines that only assembler needs to be used here.

Jo.
-- 
John Tytgat, in his comfy chair at home                                 BASS
John.Tytgat at aaug.net                             ARM powered, RISC OS driven



More information about the gcc mailing list