Using ARM GNU GCC with Cygwin

Using ARM GNU GCC with Cygwin

[Ben]

Hey all,

  I've never used Cygwin much in the past for compiling let alone cross-compiling to another arch.

I've been playing with ARM GNU GCC and some examples from nordic semiconductor for some of their demo boards (The Thingy)

The make file that comes with the project includes source files using the (abspath ../main.c) (as one example) which GCC really seems to hate.

The output from GCC is the full path (/home/bkamen/workspace-nordic/.....) right down to the file and gcc tells me it can't find the file.

if I change the mail file to use a relative path, gcc can find that... but ultimately I'm trying to understand the issue than just patch around it.

I'm using the arm-gcc from the developer.arm.com website.

Is there something else I'm missing? What files can I offer (like the makefile) that can help determine the issue?

Thanks,

  -Ben

Re: Using ARM GNU GCC with Cygwin

[Eliot Moss]

On 4/4/2020 5:00 AM, Ben wrote:

 > I've been playing with ARM GNU GCC and some examples from nordic semiconductor for some of their
 > demo boards (The Thingy)

Sounds as if that is a Windows program, not a Cygwin or Linux program.

 > The make file that comes with the project includes source files using the (abspath ../main.c) (as
 > one example) which GCC really seems to hate.

 > The output from GCC is the full path (/home/bkamen/workspace-nordic/.....) right down to the file
 > and gcc tells me it can't find the file.

If your gcc is a Windows gcc then it wants a Windows path.

 > if I change the mail file to use a relative path, gcc can find that... but ultimately I'm trying to
 > understand the issue than just patch around it.

This goes along with my theory.

 > I'm using the arm-gcc from the developer.arm.com website.
 >
 > Is there something else I'm missing? What files can I offer (like the makefile) that can help
 > determine the issue?

You can fix the Makefile to pass Windows paths.  The cygpath tool and make's
$(shell ...) command might be useful.

But I also wonder if maybe the mingw environment is more suited to this work,
or finding a Windows version of make.

Perhaps there are others here who can clarify or add to this ...   EM

Re: Using ARM GNU GCC with Cygwin

[Ben]

On 4/4/20 5:23 AM, Eliot Moss wrote:
> On 4/4/2020 5:00 AM, Ben wrote:
>
> > I've been playing with ARM GNU GCC and some examples from nordic semiconductor for some of their
> > demo boards (The Thingy)
>
> Sounds as if that is a Windows program, not a Cygwin or Linux program.
>
> > The make file that comes with the project includes source files using the (abspath ../main.c) (as
> > one example) which GCC really seems to hate.
>
> > The output from GCC is the full path (/home/bkamen/workspace-nordic/.....) right down to the file
> > and gcc tells me it can't find the file.
>
> If your gcc is a Windows gcc then it wants a Windows path.
>
> > if I change the mail file to use a relative path, gcc can find that... but ultimately I'm trying to
> > understand the issue than just patch around it.
>
> This goes along with my theory.
>
> > I'm using the arm-gcc from the developer.arm.com website.
> >
> > Is there something else I'm missing? What files can I offer (like the makefile) that can help
> > determine the issue?
>
> You can fix the Makefile to pass Windows paths.  The cygpath tool and make's
> $(shell ...) command might be useful.
>
> But I also wonder if maybe the mingw environment is more suited to this work,
> or finding a Windows version of make.

Yea, that's what I figured.

I thought I would try it and see how it worked out -- and it was so close... that I figured it'd be worth asking if anyone had worked with doing something similar.

Cheers,

  -Ben

Re: Using ARM GNU GCC with Cygwin

[Kaz Kylheku]

On 2020-04-04 02:00, Ben wrote:
> Is there something else I'm missing?

That by cross-compiling for your targets on Cygwin instead of a real 
POSIX OS, you will something like double your compile times, if not 
more.

Why would you involve Cygwin in a development activity whose target 
isn't POSIX on Windows.

Re: Using ARM GNU GCC with Cygwin

[Ben]

On 4/4/20 9:32 AM, Kaz Kylheku wrote:
> On 2020-04-04 02:00, Ben wrote:
>> Is there something else I'm missing?
>
> That by cross-compiling for your targets on Cygwin instead of a real POSIX OS, you will something like double your compile times, if not more.
>
> Why would you involve Cygwin in a development activity whose target isn't POSIX on Windows.
>
The make files do differentiate between windows and posix.

And the compiler is supplied by the GCC folks for Windows as well as Linux/Unix.

I just thought I'd try it out. It's so close to working, I thought that'd be neat.

My main linux  system is scheduled for a major upgrade (CentOS 6 to 8). So i thought I'd see how well gcc for arm on windows played with Cygwin.


  Cheers,

  -Ben

Re: Using ARM GNU GCC with Cygwin

[Åke Rehnman]

On 2020-04-04 16:32, Kaz Kylheku via Cygwin wrote:
> On 2020-04-04 02:00, Ben wrote:
>> Is there something else I'm missing?
>
> That by cross-compiling for your targets on Cygwin instead of a real 
> POSIX OS, you will something like double your compile times, if not more.
>
> Why would you involve Cygwin in a development activity whose target 
> isn't POSIX on Windows.

Most strange comment I have read... With your reasoning why bother with 
cygwin at all for any reason?

I do cross compiling all the time in cygwin and the reason is of course 
to not have to deal with windows paths and what not plus you have access 
to all the build tools like make binutils grep sed autotools.

Re: Using ARM GNU GCC with Cygwin

[Ben]

On 4/4/20 1:58 PM, Åke Rehnman via Cygwin wrote:
>
>
> I do cross compiling all the time in cygwin and the reason is of course to not have to deal with windows paths and what not plus you have access to all the build tools like make binutils grep sed autotools.


Are you doing any arm compilation?  I'd be amused to get this to work on Windows (under Cygwin).

Cheers,

  -Ben

Re: Using ARM GNU GCC with Cygwin

[Marco Atzeri]

Am 04.04.2020 um 21:10 schrieb Ben:
> On 4/4/20 1:58 PM, Åke Rehnman via Cygwin wrote:
>>
>>
>> I do cross compiling all the time in cygwin and the reason is of 
>> course to not have to deal with windows paths and what not plus you 
>> have access to all the build tools like make binutils grep sed autotools.
> 
> 
> Are you doing any arm compilation?  I'd be amused to get this to work on 
> Windows (under Cygwin).
> 
> Cheers,
> 
>   -Ben
> 

why ?
I did 15 years ago, and it worked fine.

Regards
Marco

Re: Using ARM GNU GCC with Cygwin

[Kaz Kylheku]

On 2020-04-04 11:58, Åke Rehnman via Cygwin wrote:
> On 2020-04-04 16:32, Kaz Kylheku via Cygwin wrote:
>> On 2020-04-04 02:00, Ben wrote:
>>> Is there something else I'm missing?
>> 
>> That by cross-compiling for your targets on Cygwin instead of a real 
>> POSIX OS, you will something like double your compile times, if not 
>> more.
>> 
>> Why would you involve Cygwin in a development activity whose target 
>> isn't POSIX on Windows.
> 
> Most strange comment I have read... With your reasoning why bother
> with cygwin at all for any reason?

There are excellent reasons, obviously:


Firstly: to have a familiar POSIX environment available on Windows,
for personal use, where Windows is dictated by a workplace.

For instance, one use case of mine for dropping into Cygwin is
to run ImageMagick's convert command to either convert a .pdf
file into multiple .png files or vice versa. This is in the
context of work e-mails (Outlook, Exchange, ...).

I have a major use case for Cygwin for providing remote access
to Windows. Using a non-Cygwin utility called "RunAsService.EXE",
I turned a Cygwin Bash script into a Windows service. This Bash
script loops around and makes a SSH connection to a host
in a domain that I control, setting up a tunnel for port 3389
(RDP). From that domain, I can then remote desktop into the
Windows system. Basically I can deploy this solution on any
Windows machine on any network where outbound SSH is allowed, and
have remote access to it.


Secondly: to port stuff to Windows that has to run on Windows for
reasons like the target users being tied to Windows, yet uses
lots of POSIX API's.

"A cross-compiling GNU toolchain" isn't an example of an application
that must run on Windows. It's not shipped to users. The system/device
being targeted by the cross-compiling is what is shipped to users.

Why wouldn't you use the best possible environment for that,
on a robust, fast OS.

OP has explained that he's just curious to get that working, and
there is certainly nothing wrong with that.

I certainly don't want to dictate to him what he should find
interesting and motivating; that was not the intent of my remark.

I also must acknowledge the following: there may be a situation
whereby the embedded system in question (quite stupidly, but
out of your control) requires communication with Windows for
some procedure like flashing part of the firmware or something
(say over USB). The people responsible for that developed a
utility which only runs on Windows. If you can build on Windows,
then the whole workflow is easily streamlined, including the part
where you have to kick off the FOOBAR.EXE to do that annoying step.
It nicely runs on just one machine without any extra copying of
images and whatnot.

(Yes, I've dealt with stuff like that, but usually outside of the
regular dev cycle. Like say for flashing an low-level bootloader
not touched by regular rebuilds of the main image, or recovering
a totally "bricked" unit and such.)

Re: Using ARM GNU GCC with Cygwin

[David Rothenberger]

On 4/8/2020 1:50 PM, Kaz Kylheku via Cygwin wrote:
> On 2020-04-04 11:58, Åke Rehnman via Cygwin wrote:
> I have a major use case for Cygwin for providing remote access
> to Windows. Using a non-Cygwin utility called "RunAsService.EXE",
> I turned a Cygwin Bash script into a Windows service. This Bash
> script loops around and makes a SSH connection to a host
> in a domain that I control, setting up a tunnel for port 3389
> (RDP). From that domain, I can then remote desktop into the
> Windows system. Basically I can deploy this solution on any
> Windows machine on any network where outbound SSH is allowed, and
> have remote access to it.

You might want to look at the "autossh" Cygwin package. It handles 
exactly this use case and can be registered as a Windows service without 
any non-Cygwin utilities. Just look at

   /usr/share/doc/autossh/README.Cygwin

after you install the package for details about the service.

I've been using this for years for the purpose you've described and it's 
been working great.

-- 
David Rothenberger  ----  daveroth@acm.org

QOTD:
         "Overweight is when you step on your dog's tail and it dies."

Re: Using ARM GNU GCC with Cygwin

[Ben Kamen]

Well then.

This certainly turned out to be all sorts of interesting discussion. :)

I for one also can say it's nice to have a cygwin environment over DOS if I'm forced to a CLI on Windows.

Most of my days are spent on Linux  -- but it looks like I have some legit CLI time coming on Windows and cygwin was my first go-to thought for that.

It's already bad enough how many times I type 'ls -l' in DOS to get an error. HAhahaha.

(two thumbs up)

  -Ben

Re: Using ARM GNU GCC with Cygwin

[Kaz Kylheku]

On 2020-04-08 14:13, Ben Kamen wrote:
> Well then.
> 
> This certainly turned out to be all sorts of interesting discussion. :)
> 
> I for one also can say it's nice to have a cygwin environment over DOS
> if I'm forced to a CLI on Windows.
> 
> Most of my days are spent on Linux  -- but it looks like I have some
> legit CLI time coming on Windows and cygwin was my first go-to thought
> for that.
> 
> It's already bad enough how many times I type 'ls -l' in DOS to get an
> error. HAhahaha.
> 
> (two thumbs up)

I use Cygwin for porting a programming language (TXR) to Windows.
Previously, I used MinGW, which was terrible; it has no POSIX
support at all. The MinGW version didn't have a working REPL mode,
for instance. Cygwin has termios calls that translate to the Windows
Console API; you can put the TTY into raw mode and just spew ANSI/VT100
codes and it all works. Input side too.

In 2016(?), Cygwin announced that the DLL's were going to be LGPL
instead of GPL. That means they could be linked not only with
proprietary applications, but ones with *less* restrictive licensing
such as BSD, without GPL contagion, like my project. Terrific!

I immediately saw the implications for this, and
began work on a forked version of the Cygwin DLL which
is a little bit more suitable as a run-time for a Windows application.
I made just a few changes for more Windows-like behaviors.
For instance, the file system calls understand Windows paths with
letter names instead of /cygdrv, and the chdir() system call
understands the "logged drive" DOS/Windows concept. The PATH variable
is untranslated in Cygnal, and semicolon separated. The system()
function and popen() don't look for /bin/sh, they use the CMD
variable, defaulting on cmd.exe. Things like that.

That project is here:

https://www.kylheku.com/cygnal/

The beauty is that you can compile a program quite simply in Cygwin
as a Cygwin executable. Then just slide this modified library
under it, bundle them together, and ship it as a Windows program.
I do exactly that.

Cygnal is a little behind Cygwin; it's about time I did a rebase
to a newer Cygwin.

Re: Using ARM GNU GCC with Cygwin

[Kaz Kylheku]

On 2020-04-08 13:58, David Rothenberger wrote:
> On 4/8/2020 1:50 PM, Kaz Kylheku via Cygwin wrote:
>> On 2020-04-04 11:58, Åke Rehnman via Cygwin wrote:
>> I have a major use case for Cygwin for providing remote access
>> to Windows. Using a non-Cygwin utility called "RunAsService.EXE",
>> I turned a Cygwin Bash script into a Windows service. This Bash
>> script loops around and makes a SSH connection to a host
>> in a domain that I control, setting up a tunnel for port 3389
>> (RDP). From that domain, I can then remote desktop into the
>> Windows system. Basically I can deploy this solution on any
>> Windows machine on any network where outbound SSH is allowed, and
>> have remote access to it.
> 
> You might want to look at the "autossh" Cygwin package. It handles
> exactly this use case and can be registered as a Windows service
> without any non-Cygwin utilities.

Hi David, thanks for bringing this to my attention.

That seems to use something called cygrunsrv, which is
what I should have used for that script (and will be sure
to do upon the next opportunity of using it again).

> Just look at
> 
>   /usr/share/doc/autossh/README.Cygwin
> 
> after you install the package for details about the service.
> 
> I've been using this for years for the purpose you've described and
> it's been working great.

I'm reading the documentation and basically my 25
line script has all the features, including exponential
backoff for restarting a failed connection.

I'm not terribly in favor of formal packages that can be
replaced by a shell scripts that fit into an 80x25 window.

Here it is:

#!/bin/bash

PATH=/bin:/usr/bin
THISDIR=/cygdrive/C/Cygwin/.ssh
DEST=xxxx@xxxx
sleep_exp=0

while true ; do
   time_before=$(date +%s)
   ssh -i $THISDIR/id_rsa -vv -R :3389:127.0.0.2:3389 \
     -o UserKnownHostsFile=$THISDIR/known_hosts \
     -o PasswordAuthentication=no \
     -o ServerAliveInterval=60 \
     -o ServerAliveCountMax=3 \
     $DEST rdp 2> /.ssh/log
   time_now=$(date +%s)

   if [ $(( time_now - time_before )) -le 600 ] ; then
     sleep_exp=$(( sleep_exp >= 9 ? sleep_exp : sleep_exp + 1 ))
   else
     sleep_exp=0
   fi

   sleep $(( ((1 << sleep_exp) + 15) / 16 ))
done

Why do we execute a command called "rdp" on the remote host?
Because the home directory of the account that is used has
the following shell script as its login shell:

#!/bin/bash

if [ $# -ne 2 ] || [ "$1" != "-c" ] ; then
   echo interactive login not permitted
   echo "$@" >> ~/.log
   exit 1
fi

case "$2" in
   rdp )
     while true ; do sleep 3600 ; done
     ;;
   * )
     echo that command is not allowed
     exit 1
     ;;
esac

This is necessary because the Windows machine has a password-unprotected
private key that it uses to log in to this.  The service automatically
starts if the Windows is rebooted, without requiring any password.
Anyone with access to the Windows machine (such as an IT admin)
who finds this stuff could use that key to SSH to that account on
that host.

Re: Using ARM GNU GCC with Cygwin

[Andrey Repin]

Greetings, Kaz Kylheku!

> On 2020-04-04 02:00, Ben wrote:
>> Is there something else I'm missing?

> That by cross-compiling for your targets on Cygwin instead of a real 
> POSIX OS, you will something like double your compile times, if not 
> more.

Proof, please.


-- 
With best regards,
Andrey Repin
Sunday, April 5, 2020 0:39:57

Sorry for my terrible english...

Re: Using ARM GNU GCC with Cygwin

[Eliot Moss]

On 4/4/2020 5:40 PM, Andrey Repin wrote:
> Greetings, Kaz Kylheku!
> 
>> On 2020-04-04 02:00, Ben wrote:
>>> Is there something else I'm missing?
> 
>> That by cross-compiling for your targets on Cygwin instead of a real
>> POSIX OS, you will something like double your compile times, if not
>> more.
> 
> Proof, please.

I would agree with the statement, at least subjectively.  There are various
things that I build on Linux, even in Linux virtual machines running on the
same Windows laptop, and Cygwin builds take perceptibly longer.  Some of
this is down to the cost of fork() no doubt -- configure, and perhaps gcc
itself, tend to spin off lots of short jobs, which tends to expose the
fork overhead.  Not sure if anything else is slower.  Obviously the main
part of the computation in the compiler is the same.

Regards - Eliot Moss

Re: Using ARM GNU GCC with Cygwin

[Csaba Raduly]

On Sat, Apr 4, 2020 at 11:50 PM Andrey Repin <anrdaemon@yandex.ru> wrote:

> Greetings, Kaz Kylheku!
>
> > On 2020-04-04 02:00, Ben wrote:
> >> Is there something else I'm missing?
>
> > That by cross-compiling for your targets on Cygwin instead of a real
> > POSIX OS, you will something like double your compile times, if not
> > more.
>
> Proof, please.
>
>
This is not cross-compiling, but...

git clone https://github.com/eclipse/titan.core.git
cd titan.core
time make -j8

On Cygwin:

real    7m46.830s
user    22m3.272s
sys     3m33.598s

On WSL Ubuntu:

real    2m12.984s
user    5m11.656s
sys     2m16.875s

Csaba
-- 
You can get very substantial performance improvements
by not doing the right thing. - Scott Meyers, An Effective C++11/14 Sampler
So if you're looking for a completely portable, 100% standards-conformant
way
to get the wrong information: this is what you want. - Scott Meyers
(C++TDaWYK)

Re: Using ARM GNU GCC with Cygwin

[Ben]

Thanks for everyone's comments...

I ended up getting the stock arm-gcc working just find if I got rid of absolute paths and just worked with relatives.

I'm amused. :D

Cygwin saves me once again from working in the DOS prompt environment. :P


  -Ben


-- 
Ben Kamen - O.D.T., S.P.
----------------------------------------------------------------------
eMail: ben AT benjammin DOT net               http://www.benjammin.net
Fortune says:
Hailing frequencies open, Captain.
-                                                              -
NOTICE: All legal disclaimers sent to benjammin.net/benkamen.net
or any of it's affiliated domains are rendered null and void on
receipt of communications and will be handled/considered as such.

Re: Using ARM GNU GCC with Cygwin

[Åke Rehnman]

On 2020-04-04 11:00, Ben wrote:
> Hey all,
>
>  I've never used Cygwin much in the past for compiling let alone 
> cross-compiling to another arch.
>
> I've been playing with ARM GNU GCC and some examples from nordic 
> semiconductor for some of their demo boards (The Thingy)
>
> The make file that comes with the project includes source files using 
> the (abspath ../main.c) (as one example) which GCC really seems to hate.
>
> The output from GCC is the full path 
> (/home/bkamen/workspace-nordic/.....) right down to the file and gcc 
> tells me it can't find the file.
>
> if I change the mail file to use a relative path, gcc can find that... 
> but ultimately I'm trying to understand the issue than just patch 
> around it.

Without know how your make file looks it seems the paths are absolute 
and wrong... gcc usually don't have any problems with full absolute paths.

The reason I think the paths are wrong is it does not start with 
/cygdrive/c/your_dir/

>
> I'm using the arm-gcc from the developer.arm.com website.
It is the same I use.
>
> Is there something else I'm missing? What files can I offer (like the 
> makefile) that can help determine the issue?
>
Look at the failing command and make sure what ever paths and files are 
used are correct.

/Ake

Re: Using ARM GNU GCC with Cygwin

[Åke Rehnman]

On 2020-04-04 21:11, Åke Rehnman wrote:
>
> On 2020-04-04 11:00, Ben wrote:
>> Hey all,
>>
>>  I've never used Cygwin much in the past for compiling let alone 
>> cross-compiling to another arch.
>>
>> I've been playing with ARM GNU GCC and some examples from nordic 
>> semiconductor for some of their demo boards (The Thingy)
>>
>> The make file that comes with the project includes source files using 
>> the (abspath ../main.c) (as one example) which GCC really seems to hate.
>>
>> The output from GCC is the full path 
>> (/home/bkamen/workspace-nordic/.....) right down to the file and gcc 
>> tells me it can't find the file.
>>
>> if I change the mail file to use a relative path, gcc can find 
>> that... but ultimately I'm trying to understand the issue than just 
>> patch around it.
>
> Without know how your make file looks it seems the paths are absolute 
> and wrong... gcc usually don't have any problems with full absolute 
> paths.
>
> The reason I think the paths are wrong is it does not start with 
> /cygdrive/c/your_dir/
>
>>
>> I'm using the arm-gcc from the developer.arm.com website.
> It is the same I use.

I have to correct my self here. That compiler is a Windows PE executable 
and it will not take any posix paths...

The one I used in the end was I compiled the arm-gcc from the sources my 
self....

>>
>> Is there something else I'm missing? What files can I offer (like the 
>> makefile) that can help determine the issue?
>>
> Look at the failing command and make sure what ever paths and files 
> are used are correct.
>
> /Ake
>