Failure building ctags with MinGW.

Failure building ctags with MinGW.

[Óscar Fuentes]

While building with MinGW and GNUWin32:

gcc -o oo-spd/i386/ctags.exe  -gdwarf-2 -g3   -Lc:/apps/gnuwin32/lib oo-spd/i386/ctags.o oo-spd/i386/getopt.o oo-spd/i386/getopt1.o oo-spd/i386/ntlib.o oo-spd/i386/regex.o   -ladvapi32
oo-spd/i386/ctags.o: In function `readline':
d:\dev\other\bzr-emacs\personal\lib-src/ctags.c:6335: undefined reference to `_imp__re_match'
oo-spd/i386/ctags.o: In function `add_regex':
d:\dev\other\bzr-emacs\personal\lib-src/ctags.c:5880: undefined reference to `_imp__re_set_syntax'
d:\dev\other\bzr-emacs\personal\lib-src/ctags.c:5884: undefined reference to `_imp__re_compile_pattern'
d:\dev\other\bzr-emacs\personal\lib-src/ctags.c:5882: undefined reference to `_imp__re_set_syntax'
oo-spd/i386/ctags.o: In function `regex_tag_multiline':
d:\dev\other\bzr-emacs\personal\lib-src/ctags.c:6006: undefined reference to `_imp__re_search'
collect2: ld returned 1 exit status
make[2]: *** [oo-spd/i386/ctags.exe] Error 1
make[2]: se sale del directorio `d:/dev/other/bzr-emacs/personal/lib-src'
make[1]: *** [all-other-dirs-gmake] Error 2
make[1]: se sale del directorio `d:/dev/other/bzr-emacs/personal/nt'
make: *** [bootstrap] Error 2

Isn't -lregex missing from the link command line?

-- 
Óscar

Re: Failure building ctags with MinGW.

[Óscar Fuentes]

The build was picking GNUWin32's regex.h. Removing it and rebuilding
solved the problem.

Óscar Fuentes <ofv@wanadoo.es> writes:

> While building with MinGW and GNUWin32:
>
> gcc -o oo-spd/i386/ctags.exe  -gdwarf-2 -g3   -Lc:/apps/gnuwin32/lib oo-spd/i386/ctags.o oo-spd/i386/getopt.o oo-spd/i386/getopt1.o oo-spd/i386/ntlib.o oo-spd/i386/regex.o   -ladvapi32
> oo-spd/i386/ctags.o: In function `readline':
> d:\dev\other\bzr-emacs\personal\lib-src/ctags.c:6335: undefined reference to `_imp__re_match'
> oo-spd/i386/ctags.o: In function `add_regex':
> d:\dev\other\bzr-emacs\personal\lib-src/ctags.c:5880: undefined reference to `_imp__re_set_syntax'
> d:\dev\other\bzr-emacs\personal\lib-src/ctags.c:5884: undefined reference to `_imp__re_compile_pattern'
> d:\dev\other\bzr-emacs\personal\lib-src/ctags.c:5882: undefined reference to `_imp__re_set_syntax'
> oo-spd/i386/ctags.o: In function `regex_tag_multiline':
> d:\dev\other\bzr-emacs\personal\lib-src/ctags.c:6006: undefined reference to `_imp__re_search'
> collect2: ld returned 1 exit status
> make[2]: *** [oo-spd/i386/ctags.exe] Error 1
> make[2]: se sale del directorio `d:/dev/other/bzr-emacs/personal/lib-src'
> make[1]: *** [all-other-dirs-gmake] Error 2
> make[1]: se sale del directorio `d:/dev/other/bzr-emacs/personal/nt'
> make: *** [bootstrap] Error 2
>
> Isn't -lregex missing from the link command line?

-- 
Óscar

Re: Failure building ctags with MinGW.

[Eli Zaretskii]

> From: Óscar_Fuentes <ofv@wanadoo.es>
> Date: Thu, 17 Dec 2009 22:18:11 +0100
> 
> The build was picking GNUWin32's regex.h. Removing it and rebuilding
> solved the problem.

Which package did that regex.h come from?  Perhaps we should add
something to PROBLEMS.

Hmm... actually, that's strange: shouldn't GCC find src/regex.h
_before_ it looks in your system include directory?  Adding -v to the
compilation command in lib-src shows that it should:

    #include "..." search starts here:
    #include <...> search starts here:
     .
     ../nt/inc
     ../src
     D:/usr/bin/../lib/gcc/mingw32/3.4.2/../../../../include
     D:/usr/bin/../lib/gcc/mingw32/3.4.2/include
    End of search list.

Could you please look into this and see why it didn't work for you, or
tell what am I missing?

Re: Failure building ctags with MinGW.

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Óscar_Fuentes <ofv@wanadoo.es>
>> Date: Thu, 17 Dec 2009 22:18:11 +0100
>> 
>> The build was picking GNUWin32's regex.h. Removing it and rebuilding
>> solved the problem.
>
> Which package did that regex.h come from?  Perhaps we should add
> something to PROBLEMS.

The package is regex. That machine contains a full GNUWin32 install,
comprising all packages.

> Hmm... actually, that's strange: shouldn't GCC find src/regex.h
> _before_ it looks in your system include directory?  Adding -v to the
> compilation command in lib-src shows that it should:
>
>     #include "..." search starts here:
>     #include <...> search starts here:
>      .
>      ../nt/inc
>      ../src
>      D:/usr/bin/../lib/gcc/mingw32/3.4.2/../../../../include
>      D:/usr/bin/../lib/gcc/mingw32/3.4.2/include
>     End of search list.
>
> Could you please look into this and see why it didn't work for you, or
> tell what am I missing?

The problem is that the build was configured with

--cflags -Ic:/apps/gnuwin32/include --ldflags -Lc:/gnuwin32/lib

(for adding graphics support.) With this settings, the include search
path sequence becomes

#include "..." search starts here:
#include <...> search starts here:
 .
 c:/apps/gnuwin32/include
 ../nt/inc
 ../src
 c:\apps\msys\1.0\mingw\bin\../lib/gcc/mingw32/4.4.0/../../../../include
 c:\apps\msys\1.0\mingw\bin\../lib/gcc/mingw32/4.4.0/include
 c:\apps\msys\1.0\mingw\bin\../lib/gcc/mingw32/4.4.0/include-fixed
 c:\apps\msys\1.0\mingw\bin\../lib/gcc/mingw32/4.4.0/../../../../mingw32/include
End of search list.

so it picks regex.h from gnuwin32 include directory.

I had to remove gnuwin32's unistd.h too, because it contains

#include <process.h>

which reads Emacs' src/process.h, which in turn includes unistd.h,
entering a recursive inclusion.

-- 
Óscar

Re: Failure building ctags with MinGW.

[Eli Zaretskii]

> From: Óscar_Fuentes <ofv@wanadoo.es>
> Date: Fri, 18 Dec 2009 16:24:36 +0100
> 
> The problem is that the build was configured with
> 
> --cflags -Ic:/apps/gnuwin32/include --ldflags -Lc:/gnuwin32/lib
> 
> (for adding graphics support.)

I see.  Why don't you just put the gnuwin32/include files into the
normal MinGW include directory?  Why is it a good idea to have two
separate include trees?

Re: Failure building ctags with MinGW.

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> The problem is that the build was configured with
>> 
>> --cflags -Ic:/apps/gnuwin32/include --ldflags -Lc:/gnuwin32/lib
>> 
>> (for adding graphics support.)
>
> I see.  Why don't you just put the gnuwin32/include files into the
> normal MinGW include directory?  Why is it a good idea to have two
> separate include trees?

I prefer to keep the MinGW install pristine.

OTOH, maybe using -i instead of -I for cflags is the best solution here.

-- 
Óscar