C:\sdcc\bin\make.exe[1]: *** [../lib/libfltk_jpeg.a] Error 2

[che]

Hi all,

I'm new to this forum and new to C++, so I hope this isn't a duplicate. 

I'm making my way through Stroustrup's "Principles and Practices" 2nd Ed. I'm getting stuck in Chapter 12 where he starts using FLTK.

I'd like to install this library so I can include it in my code. My environment is cygwin/g++ because I like the feel of command-line linux/vi/white-on-black text. I'm running cygwin on Windows7. If needed I'm also running Codeblocks, Eclipse, and Visual C++ 20210 Express, in that order.

It looks like I'm not getting past 'make'. Here's the error 'make' gives:

>make

process_begin: CreateProcess((null), /usr/bin/ar cr ../lib/libfltk_jpeg.a jaricom.o jcapimin.o jcapistd.o jcarith.o jccoefct.o jccolor.o jcdctmgr.o jchuff.o jcinit.o jcmainct.o jcmarker.o jcmaster.o jcomapi.o jcparam.o jcprepct.o jcsample.o jctrans.o jdapimin.o jdapistd.o jdarith.o jdatadst.o jdatasrc.o jdcoefct.o jdcolor.o jddctmgr.o jdhuff.o jdinput.o jdmainct.o jdmarker.o jdmaster.o jdmerge.o jdpostct.o jdsample.o jdtrans.o jerror.o jfdctflt.o jfdctfst.o jfdctint.o jidctflt.o jidctfst.o jidctint.o jmemmgr.o jmemnobs.o jquant1.o jquant2.o jutils.o, ...) failed.

make (e=2): The system cannot find the file specified.

C:\sdcc\bin\make.exe[1]: *** [../lib/libfltk_jpeg.a] Error 2

C:\sdcc\bin\make.exe: *** [all] Error 1

I've attached my config.log and make.log.

I'm running:

>./configure

>make

Can you give me a suggestion?

thank you,

Che

[Ian MacArthur]

I’m not a big fan of cygwin; if you like the “unix shell” approach, use mingw/Msys instead. It does fewer unexpected things on Win32 and is more “native”.
I think the fltk devs (that do not use VS) tend to use mingw these days. I know I do!

As to your specific issue; don’t know, not seen that. Looks like it is failing to build the archive perhaps? Not sure why that would be...

Looking through the config log, nothing struck me in particular, other than to suggest you clean some of the cruft out of your path, as you can’t possibly be needing all that in a cygwin shell (though I very doubt that is pertinent here!)


One other point, if you are looking at Dr S’s fltk code, I’d caution that it is quite, um... idiosyncratic... in places; last time I looked he was doing some things in slightly odd ways in his support framework. I had patches, but I never quite got around to sending them on...

I’m not entirely sure his code even builds against recent fltk snapshots; I know there used to be some issue with the current OSX port, for example, though that may not matter much for your usage.

[che]

Thanks for checking out my log files. I'll give mingw/Msys a try. 

And thanks for your comments. I think you're right, it's not building the archive (I can't find a libfltk.a anywhere). I thought perhaps I have an environment variable set incorrectly. 

[che]

Hi all,

I thought I'd post a status of my progress. Maybe someone give me a few hints.

I haven't been able to compile fltk, but I feel I'm close. The previous suggestion was to try mingW/MSys. I have not tried mingw/MSys yet, thought I'd go the Windows route first. 

Here are the steps I've done so far:

The first thing I did was to download fltk-1.3.3.tar.gz. Then, in cygwin, I gunzip/untarred it into a folder in my Windows "Desktop". 

My first question is: does windows do gunzip/tar? When I see a tar.gz I think "oh, this is for unix". 

Next, back in a Windows cmd interpreter, I issued the "make" command. Suprsiingly, windows understand this command. I did this because the Article #370 "How do I compile under Windows?" says:

code

copy makefiles\Makefile.<env> Makefile
make

/code

However, I do not see a "makefiles" dir. So I just issued the make command. But it gives (paraphrasing here because I can't cut/paste from cmd.exe):

makefile: 19: makeinclude: No such file or directory

if test -f config.status: then \

...etc

make: *** [makeinclude] Error 255.

So, I guess the make include file is missing. Can someone tell me where I should get this from?

thanks for any help.

[MacArthur, Ian (Selex ES, UK)]

> I haven't been able to compile fltk, but I feel I'm close. The previous
> suggestion was to try mingW/MSys. I have not tried mingw/MSys yet,
> thought I'd go the Windows route first.

I have no idea what you mean by "the Windows route" here; I'd imagine the "Windows route" would be to download the free version of VS from Microsoft and then use the VisualC2010 project from our IDE folder to build fltk.

But below you seem to be using Cygwin... If you are wanting to use a "posix like" user environment, then Msys/Mingw is simpler to get right, I think, but Cygwin does work fine too.

> Here are the steps I've done so far:

> The first thing I did was to download fltk-1.3.3.tar.gz. Then, in
> cygwin, I gunzip/untarred it into a folder in my Windows "Desktop".

OK, so you are in a cygwin shell, and you have packed the tarball; "tar -zxf fltk-1.3.3.tar.gz", that all seems fine so far.

> My first question is: does windows do gunzip/tar? When I see a tar.gz I
> think "oh, this is for unix".

Why? It's just a file storage format. It will work anywhere you have the tools to hand, so yes, tar, gzip, et al all work much as you'd expect in a Cygwin (or indeed Msys) shell.

> Next, back in a Windows cmd interpreter, I issued the "make" command.
> Suprsiingly, windows understand this command.

If you are still in the Cygwin shell, then it is providing these tools (make et al) for you.

If you are in a DOS cmd shell, then it is probable that (at least some of) the Cygwin tools have been added to your PATH.

> I did this because the
> Article #370 "How do I compile under Windows?" says:

That howto is ancient (2005) and should probably be pulled as it describes a process we no longer support. You likely want to be following:

http://www.fltk.org/articles.php?L598

Which is slightly less ancient (2006) but *is* still broadly correct.

Anyway, long story short, in your Cygwin or Msys shell (not DOS cmd shell) do:

./configure
make

And that should be all that is needed.

> makefile: 19: makeinclude: No such file or directory
> if test -f config.status: then \
> ...etc
> make: *** [makeinclude] Error 255.

Hmm, it should have tried to run configure for you at that point. I wonder why it did not?

Are you in the Cygwin shell or a DOS cmd shell at this point?

> So, I guess the make include file is missing. Can someone tell me where
> I should get this from?
> thanks for any help.

You should be generating it using configure, much as you would do on any other Makefile based system.



Selex ES Ltd
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL
A company registered in England & Wales. Company no. 02426132
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

[Greg Ercolano]

On 05/12/15 05:40, MacArthur, Ian (Selex ES, UK) wrote:
>> My first question is: does windows do gunzip/tar? When I see a tar.gz I
>> think "oh, this is for unix".
>
> Why? It's just a file storage format. It will work anywhere you
> have the tools to hand, so yes, tar, gzip, et al all work much
> as you'd expect in a Cygwin (or indeed Msys) shell.

Also, winzip understands .tar.gz

[che]

I got fltk to run under Visual2013. thank you and I posted some comments below.

On Tuesday, May 12, 2015 at 8:40:44 AM UTC-4, MacArthur, Ian (Selex ES, UK) wrote:

> I haven't been able to compile fltk, but I feel I'm close. The previous
> suggestion was to try mingW/MSys. I have not tried mingw/MSys yet,
> thought I'd go the Windows route first.

I have no idea what you mean by "the Windows route" here; I'd imagine the "Windows route" would be to download the free version of VS from Microsoft and then use the VisualC2010 project from our IDE folder to build fltk.

I didn't mean using Microsoft VS but I'm glad you mentioned it because that's exactly what I did. And it works! thank you.

But below you seem to be using Cygwin... If you are wanting to use a "posix like" user environment, then Msys/Mingw is simpler to get right, I think, but Cygwin does work fine too.

Yes I do like the posix-like environment. I prefer grepping and redirecting over cut-and-paste.  I'll still give Msys a try it looks interesting.

> Here are the steps I've done so far:

> The first thing I did was to download fltk-1.3.3.tar.gz. Then, in
> cygwin, I gunzip/untarred it into a folder in my Windows "Desktop".

OK, so you are in a cygwin shell, and you have packed the tarball; "tar -zxf fltk-1.3.3.tar.gz", that all seems fine so far.

> My first question is: does windows do gunzip/tar? When I see a tar.gz I
> think "oh, this is for unix".

Why? It's just a file storage format. It will work anywhere you have the tools to hand, so yes, tar, gzip, et al all work much as you'd expect in a Cygwin (or indeed Msys) shell.

 

Oh, I did not know that. Seems like once I double-clicked on a tar.gz in windows and didn't know what to do with it.  

> Next, back in a Windows cmd interpreter, I issued the "make" command.
> Suprsiingly, windows understand this command.

If you are still in the Cygwin shell, then it is providing these tools (make et al) for you.

If you are in a DOS cmd shell, then it is probable that (at least some of) the Cygwin tools have been added to your PATH.

Oh, ok.  

> I did this because the
> Article #370 "How do I compile under Windows?" says:

That howto is ancient (2005) and should probably be pulled as it describes a process we no longer support. You likely want to be following:

http://www.fltk.org/articles.php?L598

Which is slightly less ancient (2006) but *is* still broadly correct.

Anyway, long story short, in your Cygwin or Msys shell (not DOS cmd shell) do:

     ./configure
      make

And that should be all that is needed.

> makefile: 19: makeinclude: No such file or directory
> if test -f config.status: then \
> ...etc
> make: *** [makeinclude] Error 255.

Hmm, it should have tried to run configure for you at that point. I wonder why it did not?

Are you in the Cygwin shell or a DOS cmd shell at this point?


> So, I guess the make include file is missing. Can someone tell me where
> I should get this from?
> thanks for any help.

You should be generating it using configure, much as you would do on any other Makefile based system.

In summary: thank you again for all your help. I have tested fltk using the "hello world" test in VS2013. 

I would still like to get fltk going in cygwin/Msys, but at least I have a solution. My latest attempt was to run "ar" and g++ standalone with all the options in fltk-config. I was able to create archives and compile the source code. I now have the problem when I run the executable I get "unable to display". So I think at this point it's some kind of X11 problem and not an fltk issue. 

Thanks again for all your help!

[Ian MacArthur]

On Tue May 12 2015 22:04:39, che wrote:

I would still like to get fltk going in cygwin/Msys, but at least I have a solution. My latest attempt was to run "ar" and g++ standalone with all the options in fltk-config. I was able to create archives and compile the source code. I now have the problem when I run the executable I get "unable to display". So I think at this point it's some kind of X11 problem and not an fltk issue. 

X11 - on the Windows build?

Are you using the cygwin setup for this?

If so, note that it seems like the cygwin folks, in their wisdom, have decided that everyone wants X11, on all platforms. Cygwin didn’t always do that, but it seems it does now...

This is not what you really want if you are trying to build native Win32 GDI applications of course; the Vs2013 tools ought to build Win32 GDI code independent of X11, and the Msys/mingw toolchain does too.

I think there is something you can do to make the cygwin toolchain build the Win GDI way too, but do not know what that is.

[Albrecht Schlosser]

On 12.05.2015 23:33 Ian MacArthur wrote:
> On Tue May 12 2015 22:04:39, che wrote:
>>
>> I would still like to get fltk going in cygwin/Msys, but at least I
>> have a solution. My latest attempt was to run "ar" and g++ standalone
>> with all the options in fltk-config. I was able to create archives and
>> compile the source code. I now have the problem when I run the
>> executable I get "unable to display". So I think at this point it's
>> some kind of X11 problem and not an fltk issue.

It's probably "unable to _open_ display". This is likely not what you want.

> X11 - on the Windows build?
>
> Are you using the cygwin setup for this?
>
> If so, note that it seems like the cygwin folks, in their wisdom, have
> decided that everyone wants X11, on all platforms. Cygwin didn’t always
> do that, but it seems it does now...
>
> This is not what you really want if you are trying to build native Win32
> GDI applications of course; the Vs2013 tools ought to build Win32 GDI
> code independent of X11, and the Msys/mingw toolchain does too.
>
> I think there is something you can do to make the cygwin toolchain build
> the Win GDI way too, but do not know what that is.

Install the mingw64 cross compiler toolchain [1] and then do something
like this for a 64-bit build:

$ cat conf_win64
#! /bin/bash
#
# Configure FLTK with MinGW 64-bit cross compiler

LDFLAGS="-static-libgcc -static-libstdc++" \
./configure \
--host=x86_64-w64-mingw32

or for a 32-bit build:

$ cat conf_win32
#! /bin/bash
#
# Configure FLTK with MinGW 32-bit cross compiler

LDFLAGS="-static-libgcc -static-libstdc++" \
./configure \
--host=i686-w64-mingw32


[1] Look for mingw64-i686-* (32-bit toolchain) and/or mingw64-x86_64-*
(64-bit toolchain) in Cygwin's setup utility.


Note: I'm frequently doing this to verify the FLTK build, and it works
(usually). I don't recommend it though for users that only want to build
and use (native) Windows executables. As Ian mentioned, MinGW is the
tool we recommend. It's much easier to set up, but provides the Unix
feeling on the command line as well (although with restricted capabilities).

[che]

Thank you both, very helpful!

[che]

Just wanted to give an update on why I wasn't able to run fltk on cygwin. I think there were two problems:

1. For the "unable to open display" problem: this is because I wasn't running the X server on Cygwin. Once I figured out that I need to run "startxwin", then my problems went away. Then I was able to run my "hello world" fltk executable Probably anyone reading this assumed I already knew that :)

2. For the ../lib/libfltk_jpeg.a not found problem, this is still a mystery. If I cd into the jpeg dir, then execute the "ar" command, then it works. So it seems that the "cd" command in the make file doesn't persist while it runs the "ar" command immediatley following it. Not sure why this is happening. Workaround was to cd into each  dir (jpeg, src, etc) and run the ar command manually. But then it choked on some other compilation problems while trying to compile fluid, so I'm still not able to build the library.

In the meantime, I have two ways that work:

1. I'm using Cygwin/Xserver with the header files from the fltk download along with the fltk library (*.a) provided with cygwin (I'm not building these myself). Seems to work so far.

2. Microsoft Visual Studio 2013.

I'm learning a lot and I'm mostly doing this because debugging in unix/cygwin/make is fun. Debugging in Windows not fun because of all that cut-and-paste stuff and you're never quite sure what's going on (although it does works).

thanks again I appreciate your help!

[MacArthur, Ian (Selex ES, UK)]

> Just wanted to give an update on why I wasn't able to run fltk on
> cygwin. I think there were two problems:
> 1. For the "unable to open display" problem: this is because I wasn't
> running the X server on Cygwin. Once I figured out that I need to run
> "startxwin", then my problems went away. Then I was able to run my
> "hello world" fltk executable Probably anyone reading this assumed I
> already knew that :)

Note that the preferred way to build and use fltk on Win32 is to use the Win GDI interface, not the X11 interface.

Rather than running an Xserver on windows, you'd be better to persuade Cygwin to do a native (i.e. mingw) build using the Win GDI rather than to persist with the X11 interface; running X11 on top of Windows is not a particularly portable solution...

[che]

Hi,

I finally installed minGW/msys and tried building the fltk library from there. I still get a similar error which seems to fail at the same place (during archiving):

$make

===making jpeg===

Compiling jaricom.c...

...

Compling jutils.c...

Archiving ../lib/libfltk_jpeg.a...

/bin/sh: -c: line 0: syntax error near unexpected token '('

/bin/sh: -c: line 0: '/c/Program Files (x86)/CodeBlocks/minGW/bin/ar cr ../lib/libfltk_jpeg.a jaricom.o jcapimin.o jcapistd.o jcarith.o jccoefct.o jccolor.o jcdctmgr.o jchuff.o jcinit.o jcmainct.o jcmarker.o jcmaster.o jcomapi.o jcparam.o jcprepct.o jcsample.o jctrans.o jdapimin.o jdapistd.o jdarith.o jdatadst.o jdatasrc.o jdcoefct.o jdcolor.o jddctmgr.o jdhuff.o jdinput.o jdmainct.o jdmarker.o jdmaster.o jdmerge.o jdpostct.o jdsample.o jdtrans.o jerror.o jfdctflt.o jfdctfst.o jfdctint.o jidctflt.o jidctfst.o jidctint.o jmemmgr.o jmemnobs.o jquant1.o jquant2.o jutils.o'

make[1]: *** [../lib/libfltk_jpeg.a] Error 2

make: *** [all] Error 1

I see I'm pointing to my minGW in codeblocks. Can you advise me how to fix this?

thank you,

Che

[che]

Hi,

I finally installed minGW/msys and tried building the fltk library from there. I still get a similar error which seems to fail at the same place (during archiving):

$make

===making jpeg===

Compiling jaricom.c...

...

Compling jutils.c...

Archiving ../lib/libfltk_jpeg.a...

/bin/sh: -c: line 0: syntax error near unexpected token '('

/bin/sh: -c: line 0: '/c/Program Files (x86)/CodeBlocks/minGW/bin/ar cr ../lib/libfltk_jpeg.a jaricom.o jcapimin.o jcapistd.o jcarith.o jccoefct.o jccolor.o jcdctmgr.o jchuff.o jcinit.o jcmainct.o jcmarker.o jcmaster.o jcomapi.o jcparam.o jcprepct.o jcsample.o jctrans.o jdapimin.o jdapistd.o jdarith.o jdatadst.o jdatasrc.o jdcoefct.o jdcolor.o jddctmgr.o jdhuff.o jdinput.o jdmainct.o jdmarker.o jdmaster.o jdmerge.o jdpostct.o jdsample.o jdtrans.o jerror.o jfdctflt.o jfdctfst.o jfdctint.o jidctflt.o jidctfst.o jidctint.o jmemmgr.o jmemnobs.o jquant1.o jquant2.o jutils.o'

make[1]: *** [../lib/libfltk_jpeg.a] Error 2

make: *** [all] Error 1

I see I'm pointing to my minGW in codeblocks. Can you advise me how to fix this?

thank you,

Che

[Albrecht Schlosser]

Short answer: install codeblocks and/or mingw in a path(name) without
spaces and other "special" characters like '(' and ')'.

Your command above chokes because the pathname '/c/Program Files
(x86)/CodeBlocks/' contains spaces and '(' and ')'. The shell does not
recognize the full string correctly as the path.

The usual recommendation for MinGW is NOT to install it in a path with
spaces. The same is obviously true for codeblocks.

I don't know if or how you can fix this. If there is a place inside
codeblocks where you specified the MinGW path then it could be worth a
try to surround this path name with single quotes, i.e.

'/c/Program Files (x86)/CodeBlocks/minGW'

or something like that. Another choice would be to escape the space and
the brackets like this (w/o single quotes):

/c/Program\ Files\ \(x86\)/CodeBlocks/minGW

Since this is not guaranteed to work everywhere the path of least
resistance might be to reinstall your codeblocks and mingw environment.

It is certainly a good idea to install the FLTK sources in a path
without special characters as well.

[che]

Oh, good tip, that makes perfect sense, thank you. I'll try installing everything without the spaces and parenthesis. 

[che]

Hi again, I'm a little confused about why I would want to edit the path in Codeblocks (to point to the non-space MinGW). I'm not using Codeblocks. I have MinGW (standalone...not the one that ships with Codeblocks)  installed in a good path...one without spaces (C:/MinGW). 

The problem (I think) is that the FLTK config script (rightly) is grabbing the gnu utils (g++, ar, etc)  from my Codeblocks install instead of MinGW dir. So, I removed the Codeblocks path from my Windows PATH variable, hoping that would fix it. The problem is mow MSys needs to somehow update it's path variable to reflect the new windows PATH. I did some searches but couldn't find anything.

I'm  guessing FLTK config gets it's path from MSys. So it looks like I either have to find a way to update MSys or reinstall MinGW... this time with the windows PATH that doesn't include that nasty path to Codeblocks.

I'll let you know how it turns out.

thank you!

On Sunday, May 10, 2015 at 5:39:42 PM UTC-4, che wrote:

[che]

Problem solved. I uninstalled Codeblocks and MinGW. Then reinstalled MinGW. This time I made sure configure/make were grabbing the correct executables:

$ which g++

/c/MinGW/bin/g++.exe

thank you for the final (I hope) time.

On Sunday, May 10, 2015 at 5:39:42 PM UTC-4, che wrote:

[Greg Ercolano]

On 07/07/15 06:25, Albrecht Schlosser wrote:
>> /bin/sh: -c: line 0: syntax error near unexpected token '('

>> /bin/sh: -c: line 0: '/c/Program Files (x86)/CodeBlocks/minGW/bin/ar ....
>> [..]

>
> Short answer: install codeblocks and/or mingw in a path(name) without
> spaces and other "special" characters like '(' and ')'.
>
> Your command above chokes because the pathname '/c/Program Files
> (x86)/CodeBlocks/' contains spaces and '(' and ')'. The shell does not
> recognize the full string correctly as the path.

Hmm, I have a question about this.

Are we (as part of configure) using absolute paths to invoke tools
like "/absolute/path/to/ar" and "/absolute/path/to/g++"
instead of just depending on the current PATH and invoking "ar" and "g++"?

Certainly spaces and special characters are challenging to get into
command lines, esp. in DOS where the rules are really kooky.

But I think everything works OK as long as the spaces and special
characters are in the PATH.

Anyway, just thinking aloud.. We probably use absolute paths
for a reason, perhaps so that compiles will work even if the
user's PATH has changed..

[Hannu Vuolasaho]

2015-07-08 2:34 GMT+03:00 Greg Ercolano :
> On 07/07/15 06:25, Albrecht Schlosser wrote:
>>> /bin/sh: -c: line 0: syntax error near unexpected token '('
>>> /bin/sh: -c: line 0: '/c/Program Files (x86)/CodeBlocks/minGW/bin/ar ....
>>> [..]
>>
>> Short answer: install codeblocks and/or mingw in a path(name) without
>> spaces and other "special" characters like '(' and ')'.
>>
>> Your command above chokes because the pathname '/c/Program Files
>> (x86)/CodeBlocks/' contains spaces and '(' and ')'. The shell does not
>> recognize the full string correctly as the path.
>
> Hmm, I have a question about this.
>
> Are we (as part of configure) using absolute paths to invoke tools
> like "/absolute/path/to/ar" and "/absolute/path/to/g++"
> instead of just depending on the current PATH and invoking "ar" and "g++"?

That would be bad. What if there is several tool chains? In my work computer
I have two different ARM chains and one X86 chain. and every gcc is named gcc.

> Certainly spaces and special characters are challenging to get into
> command lines, esp. in DOS where the rules are really kooky.

Escaping should work and there should be no wars. I'll have my tools installed
spaced paths when there is peace on Earth.

Best regards,
Hannu Vuolasaho

[Greg Ercolano]

On 07/07/15 17:39, Hannu Vuolasaho wrote:
> 2015-07-08 2:34 GMT+03:00 Greg Ercolano :
>> On 07/07/15 06:25, Albrecht Schlosser wrote:
>>>> /bin/sh: -c: line 0: syntax error near unexpected token '('
>>>> /bin/sh: -c: line 0: '/c/Program Files (x86)/CodeBlocks/minGW/bin/ar ....
>>>> [..]
>>>
>>> Short answer: install codeblocks and/or mingw in a path(name) without
>>> spaces and other "special" characters like '(' and ')'.
>>>
>>> Your command above chokes because the pathname '/c/Program Files
>>> (x86)/CodeBlocks/' contains spaces and '(' and ')'. The shell does not
>>> recognize the full string correctly as the path.
>>
>> Hmm, I have a question about this.
>>
>> Are we (as part of configure) using absolute paths to invoke tools
>> like "/absolute/path/to/ar" and "/absolute/path/to/g++"
>> instead of just depending on the current PATH and invoking "ar" and "g++"?
>
> That would be bad. What if there is several tool chains?

The PATH would reflect the desired toolchain.

If the PATH were set in the Makefile to e.g.

PATH=/some/toolchain-A/bin;...

..then invoking g++ would only involve toolchain-B's compiler.

To use toolchain-B, the PATH would be set differently:

PATH=/some/toolchain-B/bin;...

With this, invoking "g++" would only invoke one of the toolchains
at any time.

>> Certainly spaces and special characters are challenging to get into
>> command lines, esp. in DOS where the rules are really kooky.
>
> Escaping should work and there should be no wars. I'll have my tools installed
> spaced paths when there is peace on Earth.

Heh, well, some compilers like Visual Studio seem to insist on installing
in c:\Program Files\, so perhaps it's something we should be able to deal with.

I've had varying luck with escaping and quoting in the context of DOS;
esp. when it comes to backslashed paths.

But it's a casual suggestion to use the PATH to determine the executables
and leave the executable names to just be the command name without the
absolute path qualifier. If nothing else, it also makes the command lines
shorter..

[Albrecht Schlosser]

On 08.07.2015 01:34 Greg Ercolano wrote:
> On 07/07/15 06:25, Albrecht Schlosser wrote:
>>> /bin/sh: -c: line 0: syntax error near unexpected token '('
>>> /bin/sh: -c: line 0: '/c/Program Files (x86)/CodeBlocks/minGW/bin/ar ....
>>> [..]
>>
>> Short answer: install codeblocks and/or mingw in a path(name) without
>> spaces and other "special" characters like '(' and ')'.
>>
>> Your command above chokes because the pathname '/c/Program Files
>> (x86)/CodeBlocks/' contains spaces and '(' and ')'. The shell does not
>> recognize the full string correctly as the path.
>
> Hmm, I have a question about this.
>
> Are we (as part of configure) using absolute paths to invoke tools
> like "/absolute/path/to/ar" and "/absolute/path/to/g++"
> instead of just depending on the current PATH and invoking "ar" and "g++"?

We use whatever configure gives us. Look at your makeinclude file -
there are some command definitions that are to be used in the Makefiles,
and some or all are with complete paths. See below for more (cross
compiling).

Particularly 'ar' is defined in LIBCOMMAND. In my case on Linux this is:

LIBCOMMAND = /usr/bin/ar cr

Note there is a complete path.

> Certainly spaces and special characters are challenging to get into
> command lines, esp. in DOS where the rules are really kooky.
>
> But I think everything works OK as long as the spaces and special
> characters are in the PATH.

Maybe. I never thought about that.

> Anyway, just thinking aloud.. We probably use absolute paths
> for a reason, perhaps so that compiles will work even if the
> user's PATH has changed..

There is another reason. Configure can be used for cross compiling, and
although the cross compiler toolchain is /not/ in the user's path the
tools must be found by make etc.. Hence such commands are defined by
configure and included in makeinclude.

Here is an example for cross-compiling for Windows (64-bit) on Linux:

$ ./configure --host=x86_64-w64-mingw32
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-w64-mingw32
checking for x86_64-w64-mingw32-gcc... x86_64-w64-mingw32-gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.exe
checking for suffix of executables... .exe
checking whether we are cross compiling... yes
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether x86_64-w64-mingw32-gcc accepts -g... yes
checking for x86_64-w64-mingw32-gcc option to accept ISO C89... none needed
checking for x86_64-w64-mingw32-g++... x86_64-w64-mingw32-g++
checking whether we are using the GNU C++ compiler... yes
checking whether x86_64-w64-mingw32-g++ accepts -g... yes
checking for a BSD-compatible install... /usr/bin/install -c
checking for nroff... /usr/bin/nroff
checking for doxygen... /usr/bin/doxygen
checking for x86_64-w64-mingw32-ranlib... x86_64-w64-mingw32-ranlib
checking for x86_64-w64-mingw32-ar... /usr/bin/x86_64-w64-mingw32-ar
checking for x86_64-w64-mingw32-windres...
/usr/bin/x86_64-w64-mingw32-windres
checking how to run the C preprocessor... x86_64-w64-mingw32-gcc -E
...

This results in the following definitions in makeinclude:

$ grep x86 makeinclude
CXX = x86_64-w64-mingw32-g++
CC = x86_64-w64-mingw32-gcc
RC = /usr/bin/x86_64-w64-mingw32-windres
LIBCOMMAND = /usr/bin/x86_64-w64-mingw32-ar cr
RANLIB = x86_64-w64-mingw32-ranlib

I don't know the rules, but there are some commands with full paths (RC,
LIBCOMMAND) and others w/o the path (CXX, CC, RANLIB).

[Albrecht Schlosser]

On 07.07.2015 23:13 che wrote:
> Hi again, I'm a little confused about why I would want to edit the path
> in Codeblocks (to point to the non-space MinGW). I'm not using
> Codeblocks.

Ahh, I got the impression that you used Codeblocks, just because the
command line mentioned it.

> I have MinGW (standalone...not the one that ships with
> Codeblocks) installed in a good path...one without spaces (C:/MinGW).

That's fine.

> The problem (I think) is that the FLTK config script (rightly) is
> grabbing the gnu utils (g++, ar, etc) from my Codeblocks install
> instead of MinGW dir. So, I removed the Codeblocks path from my Windows
> PATH variable, hoping that would fix it. The problem is mow MSys needs
> to somehow update it's path variable to reflect the new windows PATH. I
> did some searches but couldn't find anything.

I suggest /not/ to include the MinGW tools in the Windows PATH variable.
This is likely an installation option you can choose, and that's what I do.

> I'm guessing FLTK config gets it's path from MSys. So it looks like I
> either have to find a way to update MSys or reinstall MinGW... this time
> with the windows PATH that doesn't include that nasty path to Codeblocks.

I set my PATH in my ~/.bashrc (or ~/.profile or whatever) and I always
strip off all unnecessary Windows path components. This way I'm sure
that I only use MinGW tools in a MinGW (MSYS) shell.

$ echo $PATH
/usr/local/bin:/mingw/bin:/bin:/c/WINDOWS/system32

Whenever I set up a new system with MinGW I use the default setup and
take a look at the PATH. Then I edit my .bashrc file and include only
those parts that are really needed. This was always a good decision from
my POV.

On the same system I have also installed Cygwin, and the way to set up
the PATH is the same and results in:

$ echo $PATH
/usr/local/bin:/usr/bin:/c/WINDOWS/system32

So whatever shell (MinGW, Cygwin, Windows CMD) I use I always have the
correct PATH set up.

> I'll let you know how it turns out.

I saw that you got it in your other post.

> thank you!

You're welcome.