[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug-wget] Re: wget 1.9.1 doesn't compile with gcc 4.4.0 on Windows (Min
From: |
Andy Rushton |
Subject: |
[Bug-wget] Re: wget 1.9.1 doesn't compile with gcc 4.4.0 on Windows (MinGW) |
Date: |
Mon, 12 Oct 2009 23:17:28 +0100 |
User-agent: |
Thunderbird 2.0.0.23 (Windows/20090812) |
Tony Lewis wrote:
Or Andy could try 1.12 and tell Micah what needs to be done for it to build
under MinGW. :-)
OK, having said I wasn't interested (but just to Micah), I thought I'd
give it a go after all. I downloaded 1.12 from gnu.
The MinGW-specific build system provided by the MinGW-port maintainers
for this package are monstrous. A good example of how to achieve
lock-out through obfuscation I think. So I had a go at guessing how to
build without their scripts but using them as hints.
Here goes:
---------------------------------------------------
./configure
Note: the existing MinGW-port script uses --disable-nls but I thought
I'd try it without.
I got two messages but otherwise configure completed OK:
configure: Disabling IPv6 support: your system does not support
getaddrinfo(3).
Hmm, yes it does, that's been in Windoze for yonks, but maybe its not in
the MinGW headers yet.
configure: disabling IRIs because libiconv wasn't found
Don't know the significance of this.
They're warnings, so don't really exist - onto the next stage...
---------------------------------------------------
make CPPFLAGS=-DWINDOWS LIBS=-lws2_32 exeext=.exe
This command-line was suggested by my reading of the old build system as
a starting point. No doubt these options could be generated by
configure? I added the -DWINDOWS because my first try without it seemed
to be trying to build a Unix version, suggesting that OS detection is
broken somewhere. Also it seems to me that the configure script should
really know that you have to link in winsock 2 explicitly.
host.c:67: error: conflicting types for 'WSAGetLastError'
This is on the following line:
extern int h_errno;
I don't see how this generates the error - the following are the only
references to h_errno in the source:
src/config.h:124:/* Define to 1 if you have the declaration of
`h_errno', and to 0 if you
src/host.c:50:# define SET_H_ERRNO(err) ((void)(h_errno = (err)))
src/host.c:67:extern int h_errno;
src/host.c:810: host_errstr (h_errno));
Anyone know how a declaration of h_errno is giving this error? Obviously
some macro is involved, but I can't find it.
Anyway, comment it out is the first rule of hacking, so I did that.
Everything compiled!
---------------------------------------------------
link failed:
Ah, but it didn't link.
connect.o:connect.c:(.text+0xe2): undefined reference to
`wrapped_closesocket'
(amongst others) suggests (after a bit of grepping) that mswindows.o is
not being linked in.
at src/Makefile:169:
added: mswindows.$(OBJEXT)
---------------------------------------------------
link failed part 2:
but with only two errors:
ftp.o:ftp.c:(.text+0x2b45): undefined reference to `symlink'
mswindows.o:mswindows.c:(.text+0x110f): undefined reference to `sleep'
Hmm, Windows doesn't do symlinks. And it has a Sleep(milliseconds) (yes,
with initial cap) rather than sleep(seconds). Sounds like a configure
problem.
---------------------------------------------------
config.h:374:
#define HAVE_SYMLINK 1
commented out
config.h:434:
#define HAVE_USLEEP 1
commented out
This solved those two problems, so this was a configure problem. Windows
doesn't have symlinks or usleep.
This should do it, but I now have a new missing symbol: 'compiled_features'.
---------------------------------------------------
Perl?????????!?!?!?!?!?????
The compiled_features array is defined in build_info.c. This does not
exist but is generated by a Perl (?!?) script. The rule for building
this is:
build_info.c: $(srcdir)/Makefile.am $(srcdir)/build_info.c.in
$(PERL) $(top_srcdir)/build-aux/build_info.pl \
$(srcdir)/build_info.c.in > $@
Yuck, a Perl script? Really? I'm not convinced that it's a good idea to
rely on that being installed on every platform wget might be built on.
Especially as it seems to be doing something trivial.
Anyway, like all Perl it's totally incomprehensible even when its only
doing something trivial so I just created a dummy build_info.c with an
empty array:
const char* (compiled_features[]) =
{
};
This compiled OK and allowed the build to complete!
By the way, if anyone can explain what the Perl script is doing I'll
generate a build_info.c that uses the config.h macros and does away with
the need for a script. Then the build procedure will rely on only the
standard compilation tools of configure/make/gcc (as far as I can see
scanning the Makefiles).
---------------------------------------------------
I couldn't run the tests - Perl scripts. However, I have downloaded a
few files with it and it seems to work OK.
Andy