[gccsdk] -lOSLlib and -static no go

Ron beeb at woosh.co.nz
Sun Oct 6 17:32:17 PDT 2013


In message <6f27929653.beeb at ron1954.woosh.co.nz>
          Ron <beeb at woosh.co.nz> wrote:


> Just using plain libOSLib32.a in the command worked fine with a copy
> in the source (CSD) directory, so I new it /would/ work once it could
> be found.
> I followed up the use of -LOSLib:, and found that I had previously
> put the supplied OSLib setvars commands in my !GCC.!Run.
>
> Once I changed the path to
> Set OSLib$Path <SharedLibs$Dir>.lib.
> now
>  -LOSLib: -lOSLib32
> works fine with -static
> Yes, -LOSLib: /is/ needed when static linking, I was lazely thinking
> that because non-static was finding the lib then all was well.
> I also started off thinking native gcc defaulted to -static so
> was slow getting here.
>

I now think that putting a lib such as libOSLib.a in SharedLibs is only
appropriate if nonstatic output is required. A better place for added
libraries seems to be in !GCC.arm-unknown-riscos.lib and then there is
no need for -LOSLib: and setvars at all.
A nice touch would be to have a !StaticLibs app (Sprite etc) inside
!GCC that simply filer_open 's  the dir so there is no future confusion
to placement and as a reminder to take them forward when renewing !GCC.
I think this was the attraction to  use !SharedLibs in the first place,
(one familiar place for libraries)

Libraries are also found in !GCC.libs, but on the same level,
!GCC.include is no good for finding oslib/xxx.h so I'm going with
!GCC.arm_unknown_riscos.
By putting the oslib directory of h/HDR's in
!GCC.arm-unknown-riscos.include
They are found either with <oslib/xx.h> or "oslib/xx.h" and once again,
no setvars required. Some oslib .h files reference other oslib files
with "oslib/xxh" so it is necessary for that form to work also, but
there wont be an error from using <oslib/xx.h> either so its a win win.

I'm not saying that the packaged method for installing oslib wont work,
I just think what I have described will be simpler across the board
and there is less to do/go wrong in the Makefile or gcc commands.

Cheers Ron M.




More information about the gcc mailing list