Properly building newlib to install spec files

Properly building newlib to install spec files

[Mojca Miklavec]

Hi,

I'm fixing some packages for a package manager. I think I have a bunch
of various working gcc crosscompilers, but if I try to test something
like

$ msp430-elf-gcc -mmcu=msp430g2211 -specs=nosys.specs -o test.elf test.c
msp430-elf-gcc: error: nosys.specs: No such file or directory

apparently the specs files are missing.

I'm creating a symlink from gcc to newlib and build gcc with
--with-newlib, but apparently the files don't get installed. I noticed
that random instructions suggest separately building:
- first gcc
- then newlib
- then gcc again
http://www.ifp.illinois.edu/~nakazato/tips/xgcc.html#gccagain

while other instructions say to use just --with-newlib.

Can you please advise me how to build newlib in a proper way, so that
the spec files will be installed? Where should they usually end up?

Thank you very much,
    Mojca

Re: Properly building newlib to install spec files

[Jeff Johnston]

If you build and install the various components to the same installation
directory, it should just work.

See: https://gist.github.com/resetnow/1b55beed32f3eb3f90513896565ef5c0

(your gcc compiler config options may vary)

If a spec file is installed somewhere else, you can use the -B option on
the compile to specify a location for gcc to look for it.

-- Jeff J.

On Sat, Jan 5, 2019 at 4:20 PM Mojca Miklavec <mojca@macports.org> wrote:

> Hi,
>
> I'm fixing some packages for a package manager. I think I have a bunch
> of various working gcc crosscompilers, but if I try to test something
> like
>
> $ msp430-elf-gcc -mmcu=msp430g2211 -specs=nosys.specs -o test.elf test.c
> msp430-elf-gcc: error: nosys.specs: No such file or directory
>
> apparently the specs files are missing.
>
> I'm creating a symlink from gcc to newlib and build gcc with
> --with-newlib, but apparently the files don't get installed. I noticed
> that random instructions suggest separately building:
> - first gcc
> - then newlib
> - then gcc again
> http://www.ifp.illinois.edu/~nakazato/tips/xgcc.html#gccagain
>
> while other instructions say to use just --with-newlib.
>
> Can you please advise me how to build newlib in a proper way, so that
> the spec files will be installed? Where should they usually end up?
>
> Thank you very much,
>     Mojca
>

Re: Properly building newlib to install spec files

[Orlando Arias]

On 1/5/19 4:19 PM, Mojca Miklavec wrote:
> $ msp430-elf-gcc -mmcu=msp430g2211 -specs=nosys.specs -o test.elf test.c
> msp430-elf-gcc: error: nosys.specs: No such file or directory

Greetings,

The nosys.specs file is not included with builds of newlib for the
msp430-elf target since 17 Dec 2015. The patch that removed it can be
found in [1]. As the commit message suggests, this is because I/O
hardware is handled through CIO which talks to the simulator.

Cheers,
Orlando.

[1] https://sourceware.org/ml/newlib/2015/msg00926.html

Re: Properly building newlib to install spec files

[Mojca Miklavec]

Hi,

I'm sorry for replying after such a long time, but I could not exactly
figure out what I was doing wrong until Joel today pointed out a dirty
simple little trick: I just had to make a symlink from gcc sources to
libgloss in order to install all the spec files ... and that solution
automatically worked, without the need to rebuild gcc the second time
(which would cause me a lot of headaches both in terms of
bootstrapping and compile times).

So basically just a matter of
    cd gcc-9.2.0
    ln -s ../newlib-3.1.0/libgloss .

We were already using
    ln -s ../newlib-3.1.0/newlib .
just not the libgloss thing.

It would be awesome if this was documented somewhere for complete newbies :)

I'll update all our cross-compilers to fix this.

Thank you very much,
    Mojca

On Mon, 7 Jan 2019 at 21:50, Jeff Johnston <jjohnstn@redhat.com> wrote:
>
> If you build and install the various components to the same installation directory, it should just work.
>
> See: https://gist.github.com/resetnow/1b55beed32f3eb3f90513896565ef5c0
>
> (your gcc compiler config options may vary)
>
> If a spec file is installed somewhere else, you can use the -B option on the compile to specify a location for gcc to look for it.
>
> -- Jeff J.
>
> On Sat, Jan 5, 2019 at 4:20 PM Mojca Miklavec <mojca@macports.org> wrote:
>>
>> Hi,
>>
>> I'm fixing some packages for a package manager. I think I have a bunch
>> of various working gcc crosscompilers, but if I try to test something
>> like
>>
>> $ msp430-elf-gcc -mmcu=msp430g2211 -specs=nosys.specs -o test.elf test.c
>> msp430-elf-gcc: error: nosys.specs: No such file or directory
>>
>> apparently the specs files are missing.
>>
>> I'm creating a symlink from gcc to newlib and build gcc with
>> --with-newlib, but apparently the files don't get installed. I noticed
>> that random instructions suggest separately building:
>> - first gcc
>> - then newlib
>> - then gcc again
>> http://www.ifp.illinois.edu/~nakazato/tips/xgcc.html#gccagain
>>
>> while other instructions say to use just --with-newlib.
>>
>> Can you please advise me how to build newlib in a proper way, so that
>> the spec files will be installed? Where should they usually end up?
>>
>> Thank you very much,
>>     Mojca

Re: Properly building newlib to install spec files

[Orlando Arias]

Greetings,

I was under the impression that the nosys.specs file was no longer provided for the msp430-elf target in light of the CIO interface being added [1][2]. Please correct me if I'm wrong on this.

Cheers,
Orlando.

[1] https://sourceware.org/ml/newlib/2015/msg00926.html
[2] https://sourceware.org/ml/newlib/2015/msg00923.html

On October 20, 2019 3:40:17 PM UTC, Mojca Miklavec <mojca@macports.org> wrote:
>Hi,
>
>I'm sorry for replying after such a long time, but I could not exactly
>figure out what I was doing wrong until Joel today pointed out a dirty
>simple little trick: I just had to make a symlink from gcc sources to
>libgloss in order to install all the spec files ... and that solution
>automatically worked, without the need to rebuild gcc the second time
>(which would cause me a lot of headaches both in terms of
>bootstrapping and compile times).
>
>So basically just a matter of
>    cd gcc-9.2.0
>    ln -s ../newlib-3.1.0/libgloss .
>
>We were already using
>    ln -s ../newlib-3.1.0/newlib .
>just not the libgloss thing.
>
>It would be awesome if this was documented somewhere for complete
>newbies :)
>
>I'll update all our cross-compilers to fix this.
>
>Thank you very much,
>    Mojca
>
>On Mon, 7 Jan 2019 at 21:50, Jeff Johnston <jjohnstn@redhat.com> wrote:
>>
>> If you build and install the various components to the same
>installation directory, it should just work.
>>
>> See:
>https://gist.github.com/resetnow/1b55beed32f3eb3f90513896565ef5c0
>>
>> (your gcc compiler config options may vary)
>>
>> If a spec file is installed somewhere else, you can use the -B option
>on the compile to specify a location for gcc to look for it.
>>
>> -- Jeff J.
>>
>> On Sat, Jan 5, 2019 at 4:20 PM Mojca Miklavec <mojca@macports.org>
>wrote:
>>>
>>> Hi,
>>>
>>> I'm fixing some packages for a package manager. I think I have a
>bunch
>>> of various working gcc crosscompilers, but if I try to test
>something
>>> like
>>>
>>> $ msp430-elf-gcc -mmcu=msp430g2211 -specs=nosys.specs -o test.elf
>test.c
>>> msp430-elf-gcc: error: nosys.specs: No such file or directory
>>>
>>> apparently the specs files are missing.
>>>
>>> I'm creating a symlink from gcc to newlib and build gcc with
>>> --with-newlib, but apparently the files don't get installed. I
>noticed
>>> that random instructions suggest separately building:
>>> - first gcc
>>> - then newlib
>>> - then gcc again
>>> http://www.ifp.illinois.edu/~nakazato/tips/xgcc.html#gccagain
>>>
>>> while other instructions say to use just --with-newlib.
>>>
>>> Can you please advise me how to build newlib in a proper way, so
>that
>>> the spec files will be installed? Where should they usually end up?
>>>
>>> Thank you very much,
>>>     Mojca

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Properly building newlib to install spec files

[Joel Sherrill]

I was lucky enough to see Mojca this weekend and spent a few minutes with
her. I can't speak to the msp430 directly but the build was not putting
libgloss under the gcc source directory with newlib. That is needed so the
one tree build can pick it up.

She was headed to the airport and the build didn't finish but hopefully
that was the biggest issue.

When I get home, I am sending her my simple shell scripts to build the bare
metal gcc targets that I use when testing the master.

--joel

On Sun, Oct 20, 2019, 9:21 PM Orlando Arias <orlandoarias@gmail.com> wrote:

> Greetings,
>
> I was under the impression that the nosys.specs file was no longer
> provided for the msp430-elf target in light of the CIO interface being
> added [1][2]. Please correct me if I'm wrong on this.
>
> Cheers,
> Orlando.
>
> [1] https://sourceware.org/ml/newlib/2015/msg00926.html
> [2] https://sourceware.org/ml/newlib/2015/msg00923.html
>
> On October 20, 2019 3:40:17 PM UTC, Mojca Miklavec <mojca@macports.org>
> wrote:
>>
>> Hi,
>>
>> I'm sorry for replying after such a long time, but I could not exactly
>> figure out what I was doing wrong until Joel today pointed out a dirty
>> simple little trick: I just had to make a symlink from gcc sources to
>> libgloss in order to install all the spec files ... and that solution
>> automatically worked, without the need to rebuild gcc the second time
>> (which would cause me a lot of headaches both in terms of
>> bootstrapping and compile times).
>>
>> So basically just a matter of
>>     cd gcc-9.2.0
>>     ln -s ../newlib-3.1.0/libgloss .
>>
>> We were already using
>>     ln -s ../newlib-3.1.0/newlib .
>> just not the libgloss thing.
>>
>> It would be awesome if this was documented somewhere for complete newbies :)
>>
>> I'll update all our cross-compilers to fix this.
>>
>> Thank you very much,
>>     Mojca
>>
>> On Mon, 7 Jan 2019 at 21:50, Jeff Johnston <jjohnstn@redhat.com> wrote:
>>
>>>
>>>  If you build and install the various components to the same installation directory, it should just work.
>>>
>>>  See: https://gist.github.com/resetnow/1b55beed32f3eb3f90513896565ef5c0
>>>
>>>  (your gcc compiler config options may vary)
>>>
>>>  If a spec file is installed somewhere else, you can use the -B option on the compile to specify a location for gcc to look for it.
>>>
>>>  -- Jeff J.
>>>
>>>  On Sat, Jan 5, 2019 at 4:20 PM Mojca Miklavec <mojca@macports.org> wrote:
>>>
>>>>
>>>>  Hi,
>>>>
>>>>  I'm fixing some packages for a package manager. I think I have a bunch
>>>>  of various working gcc crosscompilers, but if I try to test something
>>>>  like
>>>>
>>>>  $ msp430-elf-gcc -mmcu=msp430g2211 -specs=nosys.specs -o test.elf test.c
>>>>  msp430-elf-gcc: error: nosys.specs: No such file or directory
>>>>
>>>>  apparently the specs files are missing.
>>>>
>>>>  I'm creating a symlink from gcc to newlib and build gcc with
>>>>  --with-newlib, but apparently the files don't get installed. I noticed
>>>>  that random instructions suggest separately building:
>>>>  - first gcc
>>>>  - then newlib
>>>>  - then gcc again
>>>>  http://www.ifp.illinois.edu/~nakazato/tips/xgcc.html#gccagain
>>>>
>>>>  while other instructions say to use just --with-newlib.
>>>>
>>>>  Can you please advise me how to build newlib in a proper way, so that
>>>>  the spec files will be installed? Where should they usually end up?
>>>>
>>>>  Thank you very much,
>>>>      Mojca
>>>>
>>>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>

Re: Properly building newlib to install spec files

[Mojca Miklavec]

Dear Orlando,

I'm still waiting for the TI website to come back online to be able to
install some dependencies before building msp430-gcc:
    http://software-dl.ti.com/msp430/msp430_public_sw/mcu/msp430/MSPGCC/latest/exports/
so I'm not yet able to actually test msp430, but the change definitely
helped with getting those targets working for arm-none-eabi-gcc and a
couple of other cross-compilers where we were also missing them.

I've seen some people proposing using --with-libgloss, but the build
worked for me automatically even without providing that flag, so I'm
not exactly sure when that is needed. I'll add it "just in case".

You links seem to hint in fact that these files might not be installed
for msp430, but let's first see what I get ...

Thank you very much for all the hints and links,
    Mojca

[*] https://github.com/macports/macports-ports/pull/5584

On Sun, 20 Oct 2019 at 21:21, Orlando Arias <orlandoarias@gmail.com> wrote:
>
> Greetings,
>
> I was under the impression that the nosys.specs file was no longer provided for the msp430-elf target in light of the CIO interface being added [1][2]. Please correct me if I'm wrong on this.
>
> Cheers,
> Orlando.
>
> [1] https://sourceware.org/ml/newlib/2015/msg00926.html
> [2] https://sourceware.org/ml/newlib/2015/msg00923.html
>
> On October 20, 2019 3:40:17 PM UTC, Mojca Miklavec <mojca@macports.org> wrote:
>>
>> Hi,
>>
>> I'm sorry for replying after such a long time, but I could not exactly
>> figure out what I was doing wrong until Joel today pointed out a dirty
>> simple little trick: I just had to make a symlink from gcc sources to
>> libgloss in order to install all the spec files ... and that solution
>> automatically worked, without the need to rebuild gcc the second time
>> (which would cause me a lot of headaches both in terms of
>> bootstrapping and compile times).
>>
>> So basically just a matter of
>>     cd gcc-9.2.0
>>     ln -s ../newlib-3.1.0/libgloss .
>>
>> We were already using
>>     ln -s ../newlib-3.1.0/newlib .
>> just not the libgloss thing.
>>
>> It would be awesome if this was documented somewhere for complete newbies :)
>>
>> I'll update all our cross-compilers to fix this.
>>
>> Thank you very much,
>>     Mojca
>>
>> On Mon, 7 Jan 2019 at 21:50, Jeff Johnston <jjohnstn@redhat.com> wrote:
>>>
>>>
>>>  If you build and install the various components to the same installation directory, it should just work.
>>>
>>>  See: https://gist.github.com/resetnow/1b55beed32f3eb3f90513896565ef5c0
>>>
>>>  (your gcc compiler config options may vary)
>>>
>>>  If a spec file is installed somewhere else, you can use the -B option on the compile to specify a location for gcc to look for it.
>>>
>>>  -- Jeff J.
>>>
>>>  On Sat, Jan 5, 2019 at 4:20 PM Mojca Miklavec <mojca@macports.org> wrote:
>>>>
>>>>
>>>>  Hi,
>>>>
>>>>  I'm fixing some packages for a package manager. I think I have a bunch
>>>>  of various working gcc crosscompilers, but if I try to test something
>>>>  like
>>>>
>>>>  $ msp430-elf-gcc -mmcu=msp430g2211 -specs=nosys.specs -o test.elf test.c
>>>>  msp430-elf-gcc: error: nosys.specs: No such file or directory
>>>>
>>>>  apparently the specs files are missing.
>>>>
>>>>  I'm creating a symlink from gcc to newlib and build gcc with
>>>>  --with-newlib, but apparently the files don't get installed. I noticed
>>>>  that random instructions suggest separately building:
>>>>  - first gcc
>>>>  - then newlib
>>>>  - then gcc again
>>>>  http://www.ifp.illinois.edu/~nakazato/tips/xgcc.html#gccagain
>>>>
>>>>  while other instructions say to use just --with-newlib.
>>>>
>>>>  Can you please advise me how to build newlib in a proper way, so that
>>>>  the spec files will be installed? Where should they usually end up?
>>>>
>>>>  Thank you very much,
>>>>      Mojca
>
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Properly building newlib to install spec files

[Mojca Miklavec]

Dear Orlando,

On Sun, 20 Oct 2019 at 21:21, Orlando Arias wrote:
>
> Greetings,
>
> I was under the impression that the nosys.specs file was no longer provided for the msp430-elf target in light of the CIO interface being added [1][2]. Please correct me if I'm wrong on this.
>
> Cheers,
> Orlando.
>
> [1] https://sourceware.org/ml/newlib/2015/msg00926.html
> [2] https://sourceware.org/ml/newlib/2015/msg00923.html

In the meantime I figured out that I only had a link to an outdated
(and probably removed) file on TI's web server, the site
    http://software-dl.ti.com/msp430/msp430_public_sw/mcu/msp430/MSPGCC/latest/index_FDS.html
still works and provides working links to a newer version of gcc, so I
was able to proceed with testing msp430 as well.

After installing gcc 8.3.0 with newlib 2.4.0 (the ones for which they
provide patches inside msp430-gcc-8.3.0.16-source-patches.tar.bz2) in
the same way that got me the spec files installed for arm, those same
spec files in fact seem to be missing for msp430-elf-gcc.

I don't quite remember where I got these instructions from. I was
definitely following a few tutorials in the past to get me started
with msp430 and some arm chips, but I'm not sure if the requirement to
specify the spec file came from one of the tutorials for arm, or maybe
random notes from internet about how to test msp430 when I tried to
update the msp430 toolchain inside our package manager, like for
example:
    https://gist.github.com/0/631c9006a672458eaa48

Bottomline: I'm perfectly happy at the moment that I hopefully got the
arm toolchain fixed (which was both reported by two of our users, plus
me when I needed to do something with arm), while I'm not yet sure if
I actually need it for msp430, and it's unlikely that I'll soon have
time to play with msp430 boards again. In short: I'm probably happy
until the next user complains. (I don't know much about
cross-compilers or msp430, so I cannot argue whether the spec files
need to be added back or not.)

Mojca

Re: Properly building newlib to install spec files

[Orlando Arias]

[-- Attachment #1.1: Type: text/plain, Size: 3737 bytes --]

Greetings,

On 10/22/19 3:07 AM, Mojca Miklavec wrote:
> Dear Orlando,
> 
> On Sun, 20 Oct 2019 at 21:21, Orlando Arias wrote:
>>
>> Greetings,
>>
>> I was under the impression that the nosys.specs file was no longer provided for the msp430-elf target in light of the CIO interface being added [1][2]. Please correct me if I'm wrong on this.
>>
>> Cheers,
>> Orlando.
>>
>> [1] https://sourceware.org/ml/newlib/2015/msg00926.html
>> [2] https://sourceware.org/ml/newlib/2015/msg00923.html
> 
> In the meantime I figured out that I only had a link to an outdated
> (and probably removed) file on TI's web server, the site
>     http://software-dl.ti.com/msp430/msp430_public_sw/mcu/msp430/MSPGCC/latest/index_FDS.html
> still works and provides working links to a newer version of gcc, so I
> was able to proceed with testing msp430 as well.
> 
> After installing gcc 8.3.0 with newlib 2.4.0 (the ones for which they
> provide patches inside msp430-gcc-8.3.0.16-source-patches.tar.bz2) in
> the same way that got me the spec files installed for arm, those same
> spec files in fact seem to be missing for msp430-elf-gcc.
> 
> I don't quite remember where I got these instructions from. I was
> definitely following a few tutorials in the past to get me started
> with msp430 and some arm chips, but I'm not sure if the requirement to
> specify the spec file came from one of the tutorials for arm, or maybe
> random notes from internet about how to test msp430 when I tried to
> update the msp430 toolchain inside our package manager, like for
> example:
>     https://gist.github.com/0/631c9006a672458eaa48
> 
> Bottomline: I'm perfectly happy at the moment that I hopefully got the
> arm toolchain fixed (which was both reported by two of our users, plus
> me when I needed to do something with arm), while I'm not yet sure if
> I actually need it for msp430, and it's unlikely that I'll soon have
> time to play with msp430 boards again. In short: I'm probably happy
> until the next user complains. (I don't know much about
> cross-compilers or msp430, so I cannot argue whether the spec files
> need to be added back or not.)
> 
> Mojca
> 

Thank you for taking the time to look over this. I myself maintain the
[most of the] packages for the msp430-elf toolchain in the AUR [Arch
Linux User Repository]. I noted a while back that the nosys.specs file
was missing from the newlib package, tracing back to the patches I
pointed out in my earlier e-mail. That file did use to ship with newlib
for the msp430-elf target.

At the time, I had some users asking about what happened to the file in
question, but unfortunately the best I could tell them was that it was
removed, and gave them a different linker command to use in their
projects. That is, pass the linker -lnosys if necessary or provide own
implementations for the missing BSP functions, the latter of which
should generally be the course of action, given that -lnosys provides
the CIO routines which are mostly useless outside debugging [CIO,
Console I/O, implements something similar to ARM semihosting, adding
traps for the debugger to emulate certain operations]. I was wondering
if I had done something wrong.

I looked over the instructions in your GitHub link, and I noted that
they use newlib-2.2.0-1. Looking at the release directory [1] for
newlib, that particular release predates the patches that removed
nosys.specs from the distribution. That is why their linking command
seems to work. Otherwise, the procedure they outline is effectively the
same as the one I use in the packages I maintain.

Again, thank you.

Cheers,
Orlando.

[1] ftp://sourceware.org/pub/newlib/index.html


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Properly building newlib to install spec files

[Jozef Lawrynowicz]

On Tue, 22 Oct 2019 11:49:06 -0400
Orlando Arias <orlandoarias@gmail.com> wrote:

> Greetings,
> 
> On 10/22/19 3:07 AM, Mojca Miklavec wrote:
> > Dear Orlando,
> > 
> > On Sun, 20 Oct 2019 at 21:21, Orlando Arias wrote:  
> >>
> >> Greetings,
> >>
> >> I was under the impression that the nosys.specs file was no longer provided for the msp430-elf target in light of the CIO interface being added [1][2]. Please correct me if I'm wrong on this.
> >>
> >> Cheers,
> >> Orlando.
> >>
> >> [1] https://sourceware.org/ml/newlib/2015/msg00926.html
> >> [2] https://sourceware.org/ml/newlib/2015/msg00923.html  
> > 
> > In the meantime I figured out that I only had a link to an outdated
> > (and probably removed) file on TI's web server, the site
> >     http://software-dl.ti.com/msp430/msp430_public_sw/mcu/msp430/MSPGCC/latest/index_FDS.html
> > still works and provides working links to a newer version of gcc, so I
> > was able to proceed with testing msp430 as well.
> > 
> > After installing gcc 8.3.0 with newlib 2.4.0 (the ones for which they
> > provide patches inside msp430-gcc-8.3.0.16-source-patches.tar.bz2) in
> > the same way that got me the spec files installed for arm, those same
> > spec files in fact seem to be missing for msp430-elf-gcc.
> > 
> > I don't quite remember where I got these instructions from. I was
> > definitely following a few tutorials in the past to get me started
> > with msp430 and some arm chips, but I'm not sure if the requirement to
> > specify the spec file came from one of the tutorials for arm, or maybe
> > random notes from internet about how to test msp430 when I tried to
> > update the msp430 toolchain inside our package manager, like for
> > example:
> >     https://gist.github.com/0/631c9006a672458eaa48
> > 
> > Bottomline: I'm perfectly happy at the moment that I hopefully got the
> > arm toolchain fixed (which was both reported by two of our users, plus
> > me when I needed to do something with arm), while I'm not yet sure if
> > I actually need it for msp430, and it's unlikely that I'll soon have
> > time to play with msp430 boards again. In short: I'm probably happy
> > until the next user complains. (I don't know much about
> > cross-compilers or msp430, so I cannot argue whether the spec files
> > need to be added back or not.)
> > 
> > Mojca
> >   
> 
> Thank you for taking the time to look over this. I myself maintain the
> [most of the] packages for the msp430-elf toolchain in the AUR [Arch
> Linux User Repository]. I noted a while back that the nosys.specs file
> was missing from the newlib package, tracing back to the patches I
> pointed out in my earlier e-mail. That file did use to ship with newlib
> for the msp430-elf target.
> 
> At the time, I had some users asking about what happened to the file in
> question, but unfortunately the best I could tell them was that it was
> removed, and gave them a different linker command to use in their
> projects. That is, pass the linker -lnosys if necessary or provide own
> implementations for the missing BSP functions, the latter of which
> should generally be the course of action, given that -lnosys provides
> the CIO routines which are mostly useless outside debugging [CIO,
> Console I/O, implements something similar to ARM semihosting, adding
> traps for the debugger to emulate certain operations]. I was wondering
> if I had done something wrong.
> 
> I looked over the instructions in your GitHub link, and I noted that
> they use newlib-2.2.0-1. Looking at the release directory [1] for
> newlib, that particular release predates the patches that removed
> nosys.specs from the distribution. That is why their linking command
> seems to work. Otherwise, the procedure they outline is effectively the
> same as the one I use in the packages I maintain.

Hi,

I can only speculate why specs were removed, but I don't miss them.

Unlike ARM there's not too much relative variation in the size of MSP430
devices. The upper limit on the amount of usable memory is ~1MB.
ARM devices can be much, much larger, so being able to choose between Newlib
Nano configuration and the default is desirable, hence nano.specs.

For MSP430 we are always going to be size-constrained so it's best to always use
Newlib Nano.

As you discovered, nosys still exists but it is enabled by using the GCC -msim
option. The real use case for stubbing out system calls is when running programs
in the simulator.

In the default configuration which assumes the program will run on real
hardware, most system calls (except write() and unlink()) are stubbed out
and just loop forever. So there will be very little (if any) code size
bloat from using the default configuration over -msim.

When TI CIO functionality is added to the other syscalls, there could be a
use case to provide an option (--specs or otherwise) which enables them to be
stubbed out again.

Hope this helps,
Jozef

> 
> Again, thank you.
> 
> Cheers,
> Orlando.
> 
> [1] ftp://sourceware.org/pub/newlib/index.html
> 

Re: Properly building newlib to install spec files

[Jozef Lawrynowicz]

On Wed, 6 Nov 2019 11:07:53 +0000
Jozef Lawrynowicz <jozef.l@mittosystems.com> wrote:
.. snip ..
> 
> As you discovered, nosys still exists but it is enabled by using the GCC -msim
> option. The real use case for stubbing out system calls is when running programs
> in the simulator.

Whoops, that should actually say that nosys (libnosys.a) is used when running on
real hardware (the default), whilst a separate simulator library (libsim.a) is
used when -msim is passed to GCC.

Jozef

> 
> In the default configuration which assumes the program will run on real
> hardware, most system calls (except write() and unlink()) are stubbed out
> and just loop forever. So there will be very little (if any) code size
> bloat from using the default configuration over -msim.
> 
> When TI CIO functionality is added to the other syscalls, there could be a
> use case to provide an option (--specs or otherwise) which enables them to be
> stubbed out again.
> 
> Hope this helps,
> Jozef
> 
> > 
> > Again, thank you.
> > 
> > Cheers,
> > Orlando.
> > 
> > [1] ftp://sourceware.org/pub/newlib/index.html
> >   
>