mingw-users

[Mingw-users] Binutils make failure

[Kim <sol...@gm...>]

I'm attempting to build binutils 2.23.1 (downloaded here: 
http://sourceforge.net/projects/mingw/files/MinGW/Base/binutils/) from 
the mingw shell on windows.

I installed the mgwport package (after autoconf and automake) and tried 
that first.

Kim@Kim-PC /c/binutils-2.23.1-1-mingw32-src
$ mgwport binutils-2.23.1-1.mgwport all
 >>> Preparing binutils-2.23.1-1
 >>> Unpacking source binutils-2.23.1.tar.bz2
 >>> Preparing working source directory
*** Info: applying patch binutils-2.23.1-1.mgw.patch:
patching file MINGW-PATCHES/binutils.README
*** Info: applying patch binutils-2.23.1-1.src.patch:
patching file config.rpath
 >>> Compiling binutils-2.23.1-1

It seems to freeze up at that point. Here is the mwgport log:

mgwport 0.10.6

PF = binutils-2.23.1-1
S = /c/binutils-2.23.1-1-mingw32-src/binutils-2.23.1-1/src/binutils-2.23.1
B = /c/binutils-2.23.1-1-mingw32-src/binutils-2.23.1-1/build
D = /c/binutils-2.23.1-1-mingw32-src/binutils-2.23.1-1/inst
C =
T = /c/binutils-2.23.1-1-mingw32-src/binutils-2.23.1-1/temp
CBUILD = i686-pc-mingw32
CHOST = i686-pc-mingw32
CTARGET = i686-pc-mingw32
CC = gcc
CFLAGS = -g -O2 -pipe -mms-bitfields
CPPFLAGS =
CXX = g++
CXXFLAGS = -g -O2 -pipe -mms-bitfields
F77 = gfortran
FFLAGS = -g -O2 -pipe
FC = gfortran
FCFLAGS = -g -O2 -pipe -mms-bitfields
GCJ = gcj
GCJFLAGS = -g -O2 -pipe -mms-bitfields
OBJC = gcc
OBJCFLAGS = -g -O2 -pipe -mms-bitfields
OBJCXX = g++
OBJCXXFLAGS = -g -O2 -pipe -mms-bitfields
LDFLAGS =
LIBS =
MAKEOPTS = -j1

So after that I gave up on mgwport and headed into the binutils origsrc 
directory created by mgwport and tried a manual configure and make. The 
configuration process is successful but make fails here:

C:/MinGW/msys/1.0/bin/sh.exe ./libtool --tag=CC   --mode=compile gcc 
-DHAVE_CONF
IG_H -I. -D__USE_MINGW_FSEEK    -I. -I. -I./../include -DHAVE_i386pe_vec 
-DHAVE
_i386pei_vec -DHAVE_bfd_elf32_i386_vec 
-DHAVE_bfd_elf32_little_generic_vec -DHAV
E_bfd_elf32_big_generic_vec  -DBINDIR='"C;C:MinGWbin"'  -W -Wall 
-Wstrict-protot
ypes -Wmissing-prototypes -Wshadow -Wno-format -Werror -g -O2 
-D__USE_MINGW_ACCE
SS -MT archive.lo -MD -MP -MF .deps/archive.Tpo -c -o archive.lo archive.c
Xarchive.Tpo -c -o archive.lo archive.lo
libtool: compile: warning: libobj name `archive.Tpo -c -o archive.lo 
archive.lo'
  may not contain shell special characters.
rm: invalid option -- c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -D__USE_MINGW_FSEEK -I. -I. 
-I./../in
clude -DHAVE_i386pe_vec -DHAVE_i386pei_vec -DHAVE_bfd_elf32_i386_vec 
-DHAVE_bfd_
elf32_little_generic_vec -DHAVE_bfd_elf32_big_generic_vec 
"-DBINDIR=\\C;C:MinGWb
in\" -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow 
-Wno-format -Wer
ror -g -O2 -D__USE_MINGW_ACCESS -MT archive.lo -MD -MP -MF 
.deps/archive.Tpo -c
-o archive.lo archive.c" -o archive.Tpo -c -o archive.lo archive.o
gcc.exe: Error: archive.o: No such file or directory
gcc.exe: There is no input file: fatal error
rm: invalid option -- c
Try `rm --help' for more information.
make[4]: *** [archive.lo] Error 1
make[4]: Leaving directory 
`c:/binutils-2.23.1-1-mingw32-src/binutils-2.23.1-1/o
rigsrc/binutils-2.23.1/bfd'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory 
`c:/binutils-2.23.1-1-mingw32-src/binutils-2.23.1-1/o
rigsrc/binutils-2.23.1/bfd'
make[2]: *** [all] Error 2
make[2]: Leaving directory 
`c:/binutils-2.23.1-1-mingw32-src/binutils-2.23.1-1/o
rigsrc/binutils-2.23.1/bfd'
make[1]: *** [all-bfd] Error 2
make[1]: Leaving directory 
`c:/binutils-2.23.1-1-mingw32-src/binutils-2.23.1-1/o
rigsrc/binutils-2.23.1'
make: *** [all] Error 2

It looks like a problem with forward slashes not being handled correctly 
on a switch (the "Xarchive.Tpo" part). I investigated the makefile in 
the bfd directory and this seems to be the problem part:

.c.o:
     $(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
     $(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
#    source='$<' object='$@' libtool=no \
#    DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) \
#    $(COMPILE) -c $<

.c.obj:
     $(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ 
`$(CYGPATH_W) '$<'`
     $(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
#    source='$<' object='$@' libtool=no \
#    DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) \
#    $(COMPILE) -c `$(CYGPATH_W) '$<'`

.c.lo:
     $(LTCOMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
     $(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Plo
#    source='$<' object='$@' libtool=yes \
#    DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) \
#    $(LTCOMPILE) -c -o $@ $<

But I don't know how to fix it.

This is my first time using mingw/make so any help is greatly appreciated.

Re: [Mingw-users] Binutils make failure

[Earnie B. <ea...@us...>]

On Tue, Jul 2, 2013 at 3:07 PM, Kim wrote:
> I'm attempting to build binutils 2.23.1 (downloaded here:
> http://sourceforge.net/projects/mingw/files/MinGW/Base/binutils/) from
> the mingw shell on windows.
>

Brave soul.

> I installed the mgwport package (after autoconf and automake) and tried
> that first.
>

Even braver still.

> Kim@Kim-PC /c/binutils-2.23.1-1-mingw32-src
> $ mgwport binutils-2.23.1-1.mgwport all
>  >>> Preparing binutils-2.23.1-1
>  >>> Unpacking source binutils-2.23.1.tar.bz2
>  >>> Preparing working source directory
> *** Info: applying patch binutils-2.23.1-1.mgw.patch:
> patching file MINGW-PATCHES/binutils.README
> *** Info: applying patch binutils-2.23.1-1.src.patch:
> patching file config.rpath
>  >>> Compiling binutils-2.23.1-1
>
> It seems to freeze up at that point. Here is the mwgport log:
>

Don't know why.

> mgwport 0.10.6
>
> PF = binutils-2.23.1-1
> S = /c/binutils-2.23.1-1-mingw32-src/binutils-2.23.1-1/src/binutils-2.23.1
> B = /c/binutils-2.23.1-1-mingw32-src/binutils-2.23.1-1/build
> D = /c/binutils-2.23.1-1-mingw32-src/binutils-2.23.1-1/inst
> C =
> T = /c/binutils-2.23.1-1-mingw32-src/binutils-2.23.1-1/temp
> CBUILD = i686-pc-mingw32
> CHOST = i686-pc-mingw32
> CTARGET = i686-pc-mingw32
> CC = gcc
> CFLAGS = -g -O2 -pipe -mms-bitfields
> CPPFLAGS =
> CXX = g++
> CXXFLAGS = -g -O2 -pipe -mms-bitfields
> F77 = gfortran
> FFLAGS = -g -O2 -pipe
> FC = gfortran
> FCFLAGS = -g -O2 -pipe -mms-bitfields
> GCJ = gcj
> GCJFLAGS = -g -O2 -pipe -mms-bitfields
> OBJC = gcc
> OBJCFLAGS = -g -O2 -pipe -mms-bitfields
> OBJCXX = g++
> OBJCXXFLAGS = -g -O2 -pipe -mms-bitfields
> LDFLAGS =
> LIBS =
> MAKEOPTS = -j1
>
> So after that I gave up on mgwport and headed into the binutils origsrc
> directory created by mgwport and tried a manual configure and make. The
> configuration process is successful but make fails here:
>

Ah, so this is somewhat what I would've done from the start after
realizing the patch file was just adding a README file.  One word of
caution, use a build directory outside of the source directory to
execute the configure file.  Some packages do not like being
configured within the source.  Some packages do not like being
configured outside the source.  It is always best to try first
configuring outside the source.

> C:/MinGW/msys/1.0/bin/sh.exe ./libtool --tag=CC   --mode=compile gcc
> -DHAVE_CONF
> IG_H -I. -D__USE_MINGW_FSEEK    -I. -I. -I./../include -DHAVE_i386pe_vec
> -DHAVE
> _i386pei_vec -DHAVE_bfd_elf32_i386_vec
> -DHAVE_bfd_elf32_little_generic_vec -DHAV
> E_bfd_elf32_big_generic_vec  -DBINDIR='"C;C:MinGWbin"'  -W -Wall

The BINDIR value is strange; it should be C:/MinGW/bin.

> -Wstrict-protot
> ypes -Wmissing-prototypes -Wshadow -Wno-format -Werror -g -O2
> -D__USE_MINGW_ACCE
> SS -MT archive.lo -MD -MP -MF .deps/archive.Tpo -c -o archive.lo archive.c
> Xarchive.Tpo -c -o archive.lo archive.lo
> libtool: compile: warning: libobj name `archive.Tpo -c -o archive.lo
> archive.lo'
>   may not contain shell special characters.
> rm: invalid option -- c

libtool is hiding something.  Why is it giving this issue about rm?

> libtool: compile:  gcc -DHAVE_CONFIG_H -I. -D__USE_MINGW_FSEEK -I. -I.
> -I./../in
> clude -DHAVE_i386pe_vec -DHAVE_i386pei_vec -DHAVE_bfd_elf32_i386_vec
> -DHAVE_bfd_
> elf32_little_generic_vec -DHAVE_bfd_elf32_big_generic_vec
> "-DBINDIR=\\C;C:MinGWb
> in\" -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow

Again the BINDIR is strange.

> -Wno-format -Wer
> ror -g -O2 -D__USE_MINGW_ACCESS -MT archive.lo -MD -MP -MF
> .deps/archive.Tpo -c
> -o archive.lo archive.c" -o archive.Tpo -c -o archive.lo archive.o
> gcc.exe: Error: archive.o: No such file or directory
> gcc.exe: There is no input file: fatal error
> rm: invalid option -- c
> Try `rm --help' for more information.
> make[4]: *** [archive.lo] Error 1
> make[4]: Leaving directory
> `c:/binutils-2.23.1-1-mingw32-src/binutils-2.23.1-1/o
> rigsrc/binutils-2.23.1/bfd'
> make[3]: *** [all-recursive] Error 1
> make[3]: Leaving directory
> `c:/binutils-2.23.1-1-mingw32-src/binutils-2.23.1-1/o
> rigsrc/binutils-2.23.1/bfd'
> make[2]: *** [all] Error 2
> make[2]: Leaving directory
> `c:/binutils-2.23.1-1-mingw32-src/binutils-2.23.1-1/o
> rigsrc/binutils-2.23.1/bfd'
> make[1]: *** [all-bfd] Error 2
> make[1]: Leaving directory
> `c:/binutils-2.23.1-1-mingw32-src/binutils-2.23.1-1/o
> rigsrc/binutils-2.23.1'
> make: *** [all] Error 2
>
> It looks like a problem with forward slashes not being handled correctly
> on a switch (the "Xarchive.Tpo" part). I investigated the makefile in
> the bfd directory and this seems to be the problem part:

I think you mean back slashes; BINDIR in the Makfile appears to be wrong.

>
> .c.o:
>      $(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
>      $(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
> #    source='$<' object='$@' libtool=no \
> #    DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) \
> #    $(COMPILE) -c $<
>
> .c.obj:
>      $(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@
> `$(CYGPATH_W) '$<'`
>      $(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
> #    source='$<' object='$@' libtool=no \
> #    DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) \
> #    $(COMPILE) -c `$(CYGPATH_W) '$<'`
>

What is the value of COMPILE?

> .c.lo:
>      $(LTCOMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
>      $(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Plo
> #    source='$<' object='$@' libtool=yes \
> #    DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) \
> #    $(LTCOMPILE) -c -o $@ $<
>

What is the value of LTCOMPILE?


Also give us what you gave to configure as arguments.  We cannot
determine from what you've given us the issue.

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

Re: [Mingw-users] Binutils make failure

[Kim <sol...@gm...>]

Thanks very much for your response.

Here is the complete process I'm using starting from a freshly unpacked 
binutils src dir:
http://pastebin.com/9Pur8WhA

The binutils readme suggests that it should be fine to run configure 
from the same directory.

You're right about DBINDIR, after checking where these directories are 
being assigned in the makefile I found

-DBINDIR='"$(bindir)"'
bindir = ${exec_prefix}/bin
exec_prefix = ${prefix}
prefix = C:/MinGW

As far as I can tell that should work properly but the slashes seem to 
be ignored for some reason.

Hardcoding DBINDIR to 'C:/MinGW/bin/ gets me further in the build but 
more errors related to the incorrectly handled slashes pop up later.



On 2013/07/03 19:24, Earnie Boyd wrote:
> On Tue, Jul 2, 2013 at 3:07 PM, Kim wrote:
>> I'm attempting to build binutils 2.23.1 (downloaded here:
>> http://sourceforge.net/projects/mingw/files/MinGW/Base/binutils/) from
>> the mingw shell on windows.
>>
> Brave soul.
>
>> I installed the mgwport package (after autoconf and automake) and tried
>> that first.
>>
> Even braver still.
>
>> Kim@Kim-PC /c/binutils-2.23.1-1-mingw32-src
>> $ mgwport binutils-2.23.1-1.mgwport all
>>   >>> Preparing binutils-2.23.1-1
>>   >>> Unpacking source binutils-2.23.1.tar.bz2
>>   >>> Preparing working source directory
>> *** Info: applying patch binutils-2.23.1-1.mgw.patch:
>> patching file MINGW-PATCHES/binutils.README
>> *** Info: applying patch binutils-2.23.1-1.src.patch:
>> patching file config.rpath
>>   >>> Compiling binutils-2.23.1-1
>>
>> It seems to freeze up at that point. Here is the mwgport log:
>>
> Don't know why.
>
>> mgwport 0.10.6
>>
>> PF = binutils-2.23.1-1
>> S = /c/binutils-2.23.1-1-mingw32-src/binutils-2.23.1-1/src/binutils-2.23.1
>> B = /c/binutils-2.23.1-1-mingw32-src/binutils-2.23.1-1/build
>> D = /c/binutils-2.23.1-1-mingw32-src/binutils-2.23.1-1/inst
>> C =
>> T = /c/binutils-2.23.1-1-mingw32-src/binutils-2.23.1-1/temp
>> CBUILD = i686-pc-mingw32
>> CHOST = i686-pc-mingw32
>> CTARGET = i686-pc-mingw32
>> CC = gcc
>> CFLAGS = -g -O2 -pipe -mms-bitfields
>> CPPFLAGS =
>> CXX = g++
>> CXXFLAGS = -g -O2 -pipe -mms-bitfields
>> F77 = gfortran
>> FFLAGS = -g -O2 -pipe
>> FC = gfortran
>> FCFLAGS = -g -O2 -pipe -mms-bitfields
>> GCJ = gcj
>> GCJFLAGS = -g -O2 -pipe -mms-bitfields
>> OBJC = gcc
>> OBJCFLAGS = -g -O2 -pipe -mms-bitfields
>> OBJCXX = g++
>> OBJCXXFLAGS = -g -O2 -pipe -mms-bitfields
>> LDFLAGS =
>> LIBS =
>> MAKEOPTS = -j1
>>
>> So after that I gave up on mgwport and headed into the binutils origsrc
>> directory created by mgwport and tried a manual configure and make. The
>> configuration process is successful but make fails here:
>>
> Ah, so this is somewhat what I would've done from the start after
> realizing the patch file was just adding a README file.  One word of
> caution, use a build directory outside of the source directory to
> execute the configure file.  Some packages do not like being
> configured within the source.  Some packages do not like being
> configured outside the source.  It is always best to try first
> configuring outside the source.
>
>> C:/MinGW/msys/1.0/bin/sh.exe ./libtool --tag=CC   --mode=compile gcc
>> -DHAVE_CONF
>> IG_H -I. -D__USE_MINGW_FSEEK    -I. -I. -I./../include -DHAVE_i386pe_vec
>> -DHAVE
>> _i386pei_vec -DHAVE_bfd_elf32_i386_vec
>> -DHAVE_bfd_elf32_little_generic_vec -DHAV
>> E_bfd_elf32_big_generic_vec  -DBINDIR='"C;C:MinGWbin"'  -W -Wall
> The BINDIR value is strange; it should be C:/MinGW/bin.
>
>> -Wstrict-protot
>> ypes -Wmissing-prototypes -Wshadow -Wno-format -Werror -g -O2
>> -D__USE_MINGW_ACCE
>> SS -MT archive.lo -MD -MP -MF .deps/archive.Tpo -c -o archive.lo archive.c
>> Xarchive.Tpo -c -o archive.lo archive.lo
>> libtool: compile: warning: libobj name `archive.Tpo -c -o archive.lo
>> archive.lo'
>>    may not contain shell special characters.
>> rm: invalid option -- c
> libtool is hiding something.  Why is it giving this issue about rm?
>
>> libtool: compile:  gcc -DHAVE_CONFIG_H -I. -D__USE_MINGW_FSEEK -I. -I.
>> -I./../in
>> clude -DHAVE_i386pe_vec -DHAVE_i386pei_vec -DHAVE_bfd_elf32_i386_vec
>> -DHAVE_bfd_
>> elf32_little_generic_vec -DHAVE_bfd_elf32_big_generic_vec
>> "-DBINDIR=\\C;C:MinGWb
>> in\" -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow
> Again the BINDIR is strange.
>
>> -Wno-format -Wer
>> ror -g -O2 -D__USE_MINGW_ACCESS -MT archive.lo -MD -MP -MF
>> .deps/archive.Tpo -c
>> -o archive.lo archive.c" -o archive.Tpo -c -o archive.lo archive.o
>> gcc.exe: Error: archive.o: No such file or directory
>> gcc.exe: There is no input file: fatal error
>> rm: invalid option -- c
>> Try `rm --help' for more information.
>> make[4]: *** [archive.lo] Error 1
>> make[4]: Leaving directory
>> `c:/binutils-2.23.1-1-mingw32-src/binutils-2.23.1-1/o
>> rigsrc/binutils-2.23.1/bfd'
>> make[3]: *** [all-recursive] Error 1
>> make[3]: Leaving directory
>> `c:/binutils-2.23.1-1-mingw32-src/binutils-2.23.1-1/o
>> rigsrc/binutils-2.23.1/bfd'
>> make[2]: *** [all] Error 2
>> make[2]: Leaving directory
>> `c:/binutils-2.23.1-1-mingw32-src/binutils-2.23.1-1/o
>> rigsrc/binutils-2.23.1/bfd'
>> make[1]: *** [all-bfd] Error 2
>> make[1]: Leaving directory
>> `c:/binutils-2.23.1-1-mingw32-src/binutils-2.23.1-1/o
>> rigsrc/binutils-2.23.1'
>> make: *** [all] Error 2
>>
>> It looks like a problem with forward slashes not being handled correctly
>> on a switch (the "Xarchive.Tpo" part). I investigated the makefile in
>> the bfd directory and this seems to be the problem part:
> I think you mean back slashes; BINDIR in the Makfile appears to be wrong.
>
>> .c.o:
>>       $(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
>>       $(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
>> #    source='$<' object='$@' libtool=no \
>> #    DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) \
>> #    $(COMPILE) -c $<
>>
>> .c.obj:
>>       $(COMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@
>> `$(CYGPATH_W) '$<'`
>>       $(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Po
>> #    source='$<' object='$@' libtool=no \
>> #    DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) \
>> #    $(COMPILE) -c `$(CYGPATH_W) '$<'`
>>
> What is the value of COMPILE?
>
>> .c.lo:
>>       $(LTCOMPILE) -MT $@ -MD -MP -MF $(DEPDIR)/$*.Tpo -c -o $@ $<
>>       $(am__mv) $(DEPDIR)/$*.Tpo $(DEPDIR)/$*.Plo
>> #    source='$<' object='$@' libtool=yes \
>> #    DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) \
>> #    $(LTCOMPILE) -c -o $@ $<
>>
> What is the value of LTCOMPILE?
>
>
> Also give us what you gave to configure as arguments.  We cannot
> determine from what you've given us the issue.
>

Re: [Mingw-users] Binutils make failure

[Earnie B. <ea...@us...>]

On Wed, Jul 3, 2013 at 10:02 AM, Kim wrote:

Please read the Etiquette section of http://mingw.org/lists.shtml.

> Thanks very much for your response.
>
> Here is the complete process I'm using starting from a freshly unpacked
> binutils src dir:
> http://pastebin.com/9Pur8WhA
>

It chugs along until it gets to libtool where again BINDIR has the wrong value.

What version of MSYS are you using?  Provide the output of ``uname -a''.

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

Re: [Mingw-users] Binutils make failure

[Kim <sol...@gm...>]

> It chugs along until it gets to libtool where again BINDIR has the wrong value.
>
> What version of MSYS are you using?  Provide the output of ``uname -a''.

$ uname -a
MINGW32_NT-6.1 KIM-PC 1.0.18(0.48/3/2) 2012-11-21 22:34 i686 Msys

Re: [Mingw-users] Binutils make failure

[Earnie B. <ea...@us...>]

On Wed, Jul 3, 2013 at 5:33 PM, Kim wrote:
>> It chugs along until it gets to libtool where again BINDIR has the wrong value.
>>
>> What version of MSYS are you using?  Provide the output of ``uname -a''.
>
> $ uname -a
> MINGW32_NT-6.1 KIM-PC 1.0.18(0.48/3/2) 2012-11-21 22:34 i686 Msys

Hmm..  From the MSYS shell give me the output of the ``set'' command.
Something is in your environment that is causing this BINDIR issue.

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

Re: [Mingw-users] Binutils make failure

[Kim <sol...@gm...>]

On 2013/07/05 0:42, Earnie Boyd wrote:
> On Wed, Jul 3, 2013 at 5:33 PM, Kim wrote:
>>> It chugs along until it gets to libtool where again BINDIR has the wrong value.
>>>
>>> What version of MSYS are you using?  Provide the output of ``uname -a''.
>> $ uname -a
>> MINGW32_NT-6.1 KIM-PC 1.0.18(0.48/3/2) 2012-11-21 22:34 i686 Msys
> Hmm..  From the MSYS shell give me the output of the ``set'' command.
> Something is in your environment that is causing this BINDIR issue.
>

Kim@Kim-PC /c
$ set
!::='::\'
!C:='C:\MinGW\msys\1.0\bin'
ADSK_3DSMAX_X64_2012='C:\Program Files\Autodesk\3ds Max 2012\;H:\Program 
Files\A
utodesk\3ds Max 2012\'
ADSK_3DSMAX_X64_2013='C:\Program Files\Autodesk\3ds Max 2013\'
ALLUSERSPROFILE='C:\ProgramData'
AMDAPPSDKROOT='C:\Program Files (x86)\AMD APP\'
APPDATA='C:\Users\Kim\AppData\Roaming'
ASL.LOG=Destination=file
AWE_DIR='C:\Program Files (x86)\Awesomium Technologies LLC\Awesomium 
SDK\1.7.0.5
\'
BASH=/usr/bin/sh
BASH_ARGC=()
BASH_ARGV=()
BASH_LINENO=()
BASH_SOURCE=()
BASH_VERSINFO=([0]="3" [1]="1" [2]="17" [3]="1" [4]="release" 
[5]="i686-pc-msys"
)
BASH_VERSION='3.1.17(1)-release'
CM2012DIR='C:\Program Files (x86)\Common Files\Autodesk Shared\Materials\'
CM2013DIR='C:\Program Files (x86)\Common Files\Autodesk Shared\Materials\'
COLUMNS=80
COMMONPROGRAMFILES='C:\Program Files (x86)\Common Files'
COMMONPROGRAMFILES(X86)='C:\Program Files (x86)\Common Files'
COMMONPROGRAMW6432='C:\Program Files\Common Files'
COMPUTERNAME=KIM-PC
COMSPEC='C:\Windows\SysWOW64\cmd.exe'
C_EM64T_REDIST12='C:\Program Files (x86)\Common Files\Intel\Shared 
Libraries\'
C_IA32_REDIST12='C:\Program Files (x86)\Common Files\Intel\Shared 
Libraries\'
DIRSTACK=()
DXSDK_DIR='C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\'
EUID=500
FP_NO_HOST_CHECK=NO
FXC2_DIR='C:\Program Files (x86)\NVIDIA Corporation\FX Composer 2.5'
F_EM64T_REDIST12='C:\Program Files (x86)\Common Files\Intel\Shared 
Libraries\'
F_IA32_REDIST12='C:\Program Files (x86)\Common Files\Intel\Shared 
Libraries\'
GROUPS=()
HAXEPATH='C:\HaxeToolkit\haxe\'
HISTFILE=/home/Kim/.bash_history
HISTFILESIZE=500
HISTSIZE=500
HOME=/home/Kim
HOMEDRIVE=C:
HOMEPATH='\'
HOSTNAME=Kim-PC
HOSTTYPE=i686
ICPP_COMPILER12='C:\Program Files (x86)\Intel\Composer XE 2011 SP1\'
IFORT_COMPILER12='C:\Program Files (x86)\Intel\Composer XE 2011 SP1\'
IFS='
'
ILBDIR='C:\Program Files (x86)\Common Files\Autodesk Shared\Materials\'
ILLDIR='C:\Program Files (x86)\Common Files\Autodesk Shared\Materials\'
ILMDIR='C:\Program Files (x86)\Common Files\Autodesk Shared\Materials\'
INSPECTOR_XE_2011_DIR='C:\Program Files (x86)\Intel\Inspector XE 2011\'
INTEL_LICENSE_FILE='C:\Program Files (x86)\Common Files\Intel\Licenses'
JAVA_HOME='C:\Program Files\Java\jdk1.7.0_03\bin\'
LINES=35
LOCALAPPDATA='C:\Users\Kim\AppData\Local'
LOGNAME=Kim
LOGONSERVER='\\KIM-PC'
MACHTYPE=i686-pc-msys
MAILCHECK=60
MAKE_MODE=unix
MAYA_SCRIPT_PATH='C:\PROGRAM FILES (X86)\NATURALMOTION\ENDORPHIN 
2.5.2\RESOURCES
\THIRD PARTY\SCRIPTS\MAYA'
MOZ_PLUGIN_PATH='C:\Program Files (x86)\Foxit Software\Foxit 
Reader\plugins\'
MSYSCON=sh.exe
MSYSTEM=MINGW32
NEKO_INSTPATH='C:\HaxeToolkit\neko'
NUMBER_OF_PROCESSORS=8
OLDPWD=/home/Kim
OPTERR=1
OPTIND=1
OS=Windows_NT
OSTYPE=msys
PATH='.:/usr/local/bin:/mingw/bin:/bin:/c/Program Files 
(x86)/GnuWin32:/c/Progra
m Files (x86)/GnuWin32/bin:/c/Program Files (x86)/Microsoft Visual 
Studio 10.0/V
C/bin:/usr/local/include:/c/Program Files (x86)/CMake 
2.8/bin:/usr/local/bin:/c/
Program Files (x86)/AMD APP/bin/x86_64:/c/Program Files (x86)/Intel/iCLS 
Client/
:/c/Program Files/Intel/iCLS Client/:/c/Program Files/Common 
Files/Microsoft Sha
red/Windows Live:/c/Program Files (x86)/Common Files/Microsoft 
Shared/Windows Li
ve:/c/Program Files (x86)/Intel/Composer XE 2011 
SP1/redist/ia32/tbb/vc10:/c/Pro
gram Files (x86)/Intel/Composer XE 2011 
SP1/redist/intel64/tbb/vc10:/c/Program F
iles (x86)/Intel/Composer XE 2011 SP1/redist/intel64/mkl:/c/Program 
Files (x86)/
Intel/Composer XE 2011 SP1/redist/ia32/mkl:/c/Program Files (x86)/Common 
Files/I
ntel/Shared Libraries/redist/intel64/mpirt:/c/Program Files (x86)/Common 
Files/I
ntel/Shared Libraries/redist/intel64/compiler:/c/Program Files 
(x86)/Common File
s/Intel/Shared Libraries/redist/ia32/mpirt:/c/Program Files (x86)/Common 
Files/I
ntel/Shared 
Libraries/redist/ia32/compiler:/c/Windows/system32:/c/Windows:/c/Win
dows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0/:/c/Program Files
(x86)/ATI Technologies/ATI.ACE/Core-Static:/c/Program Files 
(x86)/Microsoft SQL
Server/100/Tools/Binn/:/c/Program Files/Microsoft SQL 
Server/100/Tools/Binn/:/c/
Program Files/Microsoft SQL Server/100/DTS/Binn/:/c/Program Files 
(x86)/Windows
Live/Shared:/c/Program Files/TortoiseSVN/bin:/c/Program 
Files/Intel/Intel(R) Man
agement Engine Components/DAL:/c/Program Files/Intel/Intel(R) Management 
Engine
Components/IPT:/c/Program Files (x86)/Intel/Intel(R) Management Engine 
Component
s/DAL:/c/Program Files (x86)/Intel/Intel(R) Management Engine 
Components/IPT:/c/
Program Files/Common Files/Autodesk Shared/:/c/Program Files 
(x86)/Autodesk/Back
burner/:/c/Program Files/Microsoft SQL Server/110/Tools/Binn/:/c/Program 
Files/M
icrosoft/Web Platform Installer/:/c/Program Files (x86)/Microsoft 
ASP.NET/ASP.NE
T Web Pages/v1.0/:/c/Program Files (x86)/Windows Kits/8.0/Windows 
Performance To
olkit/:/c/Program Files 
(x86)/FreeArc/bin:/c/HaxeToolkit/haxe/:/c/HaxeToolkit/ne
ko'
PATHEXT='.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC'
PIPESTATUS=([0]="0")
POSIXLY_CORRECT=y
PPID=1
PROCESSOR_ARCHITECTURE=x86
PROCESSOR_ARCHITEW6432=AMD64
PROCESSOR_IDENTIFIER='Intel64 Family 6 Model 58 Stepping 9, GenuineIntel'
PROCESSOR_LEVEL=6
PROCESSOR_REVISION=3a09
PROGRAMDATA='C:\ProgramData'
PROGRAMFILES='C:\Program Files (x86)'
PROGRAMFILES(X86)='C:\Program Files (x86)'
PROGRAMW6432='C:\Program Files'
PROMPT='$P$G'
PS1='\[\033]0;$MSYSTEM:\w\007
\033[32m\]\u@\h \[\033[33m\w\033[0m\]
$ '
PS2='> '
PS4='+ '
PSMODULEPATH='C:\Windows\system32\WindowsPowerShell\v1.0\Modules\'
PUBLIC='C:\Users\Public'
PWD=/c
PYTHON_ROOT='C:\Python24\'
SESSIONNAME=Console
SHELL=/bin/sh
SHELLOPTS=braceexpand:emacs:hashall:histexpand:history:interactive-comments:moni
tor:posix
SHLVL=1
SYSTEMDRIVE=C:
SYSTEMROOT='C:\Windows'
TEMP=/tmp
TERM=cygwin
TMP=/tmp
UID=500
USERDOMAIN=Kim-PC
USERNAME=Kim
USERPROFILE='C:\Users\Kim'
VBOX_INSTALL_PATH='C:\Program Files\Oracle\VirtualBox\'
VRAY_RT_FOR_3DSMAX2012_MAIN_X64='C:\Program Files\Chaos Group\V-Ray\RT 
for 3ds M
ax 2012 for x64/bin'
VRAY_RT_FOR_3DSMAX2012_PLUGINS_X64='C:\Program Files\Chaos 
Group\V-Ray\RT for 3d
s Max 2012 for x64/bin/plugins'
VS100COMNTOOLS='C:\Program Files (x86)\Microsoft Visual Studio 
10.0\Common7\Tool
s\'
VS110COMNTOOLS='C:\Program Files (x86)\Microsoft Visual Studio 
11.0\Common7\Tool
s\'
VTUNE_AMPLIFIER_XE_2011_DIR='C:\Program Files (x86)\Intel\VTune 
Amplifier XE 201
1\'
WINDIR='C:\Windows'
_=-a
i='/etc/profile.d/*.sh'

Re: [Mingw-users] Binutils make failure

[Earnie B. <ea...@us...>]

On Thu, Jul 4, 2013 at 1:54 PM, Kim wrote:
> On 2013/07/05 0:42, Earnie Boyd wrote:
>> On Wed, Jul 3, 2013 at 5:33 PM, Kim wrote:
>>>> It chugs along until it gets to libtool where again BINDIR has the wrong value.
>>>>
>>>> What version of MSYS are you using?  Provide the output of ``uname -a''.
>>> $ uname -a
>>> MINGW32_NT-6.1 KIM-PC 1.0.18(0.48/3/2) 2012-11-21 22:34 i686 Msys
>> Hmm..  From the MSYS shell give me the output of the ``set'' command.
>> Something is in your environment that is causing this BINDIR issue.
>>
>
> Kim@Kim-PC /c
> $ set

Ok, thanks.  Your PATH is a bit unsightly.  Let's try this experiment.

$ export PATH=.:/mingw/bin:/bin
$ cd /path/containing/binutils-2.23.1
$ rm -rf bintuils-2.23.1
$ tar axf /path/to/binutils-2.23.1.tar.gz
$ # or whatever the archive tar name is compressed with.
$ mkdir bld
$ cd bld
$ ../bintuils-2.23.1/configure --prefix=/mingw
$ make

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

Re: [Mingw-users] Binutils make failure

[Kim <sol...@gm...>]

On 2013/07/05 3:42, Earnie Boyd wrote:
> On Thu, Jul 4, 2013 at 1:54 PM, Kim wrote:
>> On 2013/07/05 0:42, Earnie Boyd wrote:
>>> On Wed, Jul 3, 2013 at 5:33 PM, Kim wrote:
>>>>> It chugs along until it gets to libtool where again BINDIR has the wrong value.
>>>>>
>>>>> What version of MSYS are you using?  Provide the output of ``uname -a''.
>>>> $ uname -a
>>>> MINGW32_NT-6.1 KIM-PC 1.0.18(0.48/3/2) 2012-11-21 22:34 i686 Msys
>>> Hmm..  From the MSYS shell give me the output of the ``set'' command.
>>> Something is in your environment that is causing this BINDIR issue.
>>>
>> Kim@Kim-PC /c
>> $ set
> Ok, thanks.  Your PATH is a bit unsightly.  Let's try this experiment.
>
> $ export PATH=.:/mingw/bin:/bin
> $ cd /path/containing/binutils-2.23.1
> $ rm -rf bintuils-2.23.1
> $ tar axf /path/to/binutils-2.23.1.tar.gz
> $ # or whatever the archive tar name is compressed with.
> $ mkdir bld
> $ cd bld
> $ ../bintuils-2.23.1/configure --prefix=/mingw
> $ make
>

Same result with incorrect BINDIR, I pastebinned the output while 
following your instructions in case you notice something I didn't.
http://pastebin.com/272vKK2L

Re: [Mingw-users] Binutils make failure

[Earnie B. <ea...@us...>]

On Thu, Jul 4, 2013 at 7:19 PM, Kim wrote:
> On 2013/07/05 3:42, Earnie Boyd wrote:
>> On Thu, Jul 4, 2013 at 1:54 PM, Kim wrote:
>>> On 2013/07/05 0:42, Earnie Boyd wrote:
>>>> On Wed, Jul 3, 2013 at 5:33 PM, Kim wrote:
>>>>>> It chugs along until it gets to libtool where again BINDIR has the wrong value.
>>>>>>
>>>>>> What version of MSYS are you using?  Provide the output of ``uname -a''.
>>>>> $ uname -a
>>>>> MINGW32_NT-6.1 KIM-PC 1.0.18(0.48/3/2) 2012-11-21 22:34 i686 Msys
>>>> Hmm..  From the MSYS shell give me the output of the ``set'' command.
>>>> Something is in your environment that is causing this BINDIR issue.
>>>>
>>> Kim@Kim-PC /c
>>> $ set
>> Ok, thanks.  Your PATH is a bit unsightly.  Let's try this experiment.
>>
>> $ export PATH=.:/mingw/bin:/bin
>> $ cd /path/containing/binutils-2.23.1
>> $ rm -rf bintuils-2.23.1
>> $ tar axf /path/to/binutils-2.23.1.tar.gz
>> $ # or whatever the archive tar name is compressed with.
>> $ mkdir bld
>> $ cd bld
>> $ ../bintuils-2.23.1/configure --prefix=/mingw
>> $ make
>>
>
> Same result with incorrect BINDIR, I pastebinned the output while
> following your instructions in case you notice something I didn't.
> http://pastebin.com/272vKK2L

I see some things odd, I'll mention two but need more time to study further.

/mingw/bin/sed
/usr/local/bin/grep

I do see you export PATH correctly so why is the script is looking in
/usr/local/bin, I don't know.  I would have expected both of these to
have been found in /bin.

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

Re: [Mingw-users] Binutils make failure

[John B. <joh...@ho...>]

On Fri, 5 Jul 2013 07:19:39 +0800, Kim wrote:
>
> On 2013/07/05 3:42, Earnie Boyd wrote:

>> Ok, thanks. Your PATH is a bit unsightly. Let's try this experiment.
>>
>> $ export PATH=.:/mingw/bin:/bin
>> $ cd /path/containing/binutils-2.23.1
>> $ rm -rf bintuils-2.23.1
>> $ tar axf /path/to/binutils-2.23.1.tar.gz
>> $ # or whatever the archive tar name is compressed with.
>> $ mkdir bld
>> $ cd bld
>> $ ../bintuils-2.23.1/configure --prefix=/mingw
>> $ make
>>
>
> Same result with incorrect BINDIR, I pastebinned the output while
> following your instructions in case you notice something I didn't.
> http://pastebin.com/272vKK2L
>

Hello Kim,

For what it is worth, you created your build directory under the
source directory. Since the binutils source is in /c/binutils-2.23.1
you should have created /c/bld and then:

$ cd /c/bld
$ ../binuils-2.23.1/configure --prefix=/mingw

That is, do not build binutils in the binutils source tree.
I don't know if it will make a difference, but it is what Earnie
wanted you to do.

Regards,
John Brown. 		 	   		  

Re: [Mingw-users] Binutils make failure

[Kim <sol...@gm...>]

On 2013/07/05 8:02, John Brown wrote:
> On Fri, 5 Jul 2013 07:19:39 +0800, Kim wrote:
>> On 2013/07/05 3:42, Earnie Boyd wrote:
>>> Ok, thanks. Your PATH is a bit unsightly. Let's try this experiment.
>>>
>>> $ export PATH=.:/mingw/bin:/bin
>>> $ cd /path/containing/binutils-2.23.1
>>> $ rm -rf bintuils-2.23.1
>>> $ tar axf /path/to/binutils-2.23.1.tar.gz
>>> $ # or whatever the archive tar name is compressed with.
>>> $ mkdir bld
>>> $ cd bld
>>> $ ../bintuils-2.23.1/configure --prefix=/mingw
>>> $ make
>>>
>> Same result with incorrect BINDIR, I pastebinned the output while
>> following your instructions in case you notice something I didn't.
>> http://pastebin.com/272vKK2L
>>
> Hello Kim,
>
> For what it is worth, you created your build directory under the
> source directory. Since the binutils source is in /c/binutils-2.23.1
> you should have created /c/bld and then:
>
> $ cd /c/bld
> $ ../binuils-2.23.1/configure --prefix=/mingw
>
> That is, do not build binutils in the binutils source tree.
> I don't know if it will make a difference, but it is what Earnie
> wanted you to do.
The bld directory was created alongside the binutils source directory, 
it's just that the source was unzipped into a folder also called 
binutils-2.23.1. Sorry for the confusion there. Just in case I 
re-extracted the source directory to my C: root, created bld alongside 
it also in the root and tried configuring and making again with the same 
make result.
> Regards,
> John Brown. 		 	   		
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> MinGW-users mailing list
> Min...@li...
>
> This list observes the Etiquette found at
> http://www.mingw.org/Mailing_Lists.
> We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.
>
> _______________________________________________
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users
> Also: mailto:min...@li...?subject=unsubscribe
>