And yet, another strange error appears. This time, libtool crashes complaining about a "false cr" error in libgnu.la. Attaching the error from make.
Your configure script seemed not to find
ar. Check your
config.log, find
checking for ar line, and see the result.
What are your commands to call configure, and env vars related to build?
Where is
-idirafter u:/usr/include/os2tk45 and
-DOS2 from ?
If you're using
config.site, what is the content of it?
What is your
sh.exe? How about trying to various shs such as dash, ash, bash, mksh, pdksh, and so on.
just puzzles me. I'm starting to believe something in my development toolchain is broken.
Looking at the makefile directives in the listed rows I can see this:
row 600: $(MAKE) $(AM_MAKEFLAGS) all-recursive (not too surprising, it's the make all directive)
row 611: && exit 0; \ (am--refresh directive, not too useful I'm afraid)
row 660: install-gengetoptdocDATA: $(gengetoptdoc_DATA)
row 689: $(am__recursive_targets):
@fail=; \
row 716: ID: $(am__tagged_files)
$(am__define_uniq_tagged_files); mkid -fID $$unique
tags: tags-recursive
So it seems that looking at the makefile is not helping much (or it's just that I'm not too experienced with makefiles).
I don't understand what you mean. And see
Makefile.am not
Makefile if possible.
EDIT: as soon as I gave autoreconf -sfi the usual error appears during make:
libtool: error: object name conflicts in archive: .libs/libgengetopt.lax/gnu.a/D:/Sviluppo/Sorgenti/gengetopt-2.23/src/../gl/.libs/gnu.a
Can't really fathom what the hell is happening here.
In case of the gengetopt v2.23 tarball, it's not necessary to call
autoreconf at all. Anyway, it seems that your autotools are broken. Such an error is caused when a path starting with X:/ is not recognized as an absolute path. You should look into the libtool parts determining if a path is absolute. Usually, they have
/* pattern in
case.