I'm attempting to build the Borland C++Builder DLL version of 0.9.6b.
The problem I've been running into is what appears to be a bug in
ILINK32.EXE. Apparently a limitation of the linker response file line length
causes the linker to suddenly stop interpreting the (huge) list of objects
as objects and skips to subsequent fields, e.g. - EXE name, MAP file, etc.
This really had me going because the errors I got from the linker didn't
make sense, e.g. - this makefile command:
$(O_CRYPTO): $(CRYPTOOBJ)
$(LINK) $(MLFLAGS) $(SHLIB_EX_OBJ) @&&| $(CRYPTOOBJ)
|, $(O_CRYPTO), , $(EX_LIBS), ms\LIBEAYB.def,
would result in a 'Too many EXE filenames present', or 'Too many MAP
filenames present IMPORT32.LIB'. In order to fix it, I had to break up the
CRYPTOOBJ into about 12 or 13 pieces and SSLOBJ into 2 pieces, e.g. -
$(O_CRYPTO): $(CRYPTOOBJ)
$(LINK) $(MLFLAGS) $(SHLIB_EX_OBJ) @&&! +
$(CRYPTOOBJ0) +
$(CRYPTOOBJ1) +
$(CRYPTOOBJ2) +
$(CRYPTOOBJ3) +
$(CRYPTOOBJ4) +
$(CRYPTOOBJ5) +
$(CRYPTOOBJ6) +
$(CRYPTOOBJ7) +
$(CRYPTOOBJ8) +
$(CRYPTOOBJ9) +
$(CRYPTOOBJ10) +
$(CRYPTOOBJ11) +
$(CRYPTOOBJ12) +
, $(O_CRYPTO),, $(EX_LIBS), ms\LIBEAYB.def
!
Background: The main purpose of any response file is to circumvent command
line character capacities by what normally would be command line output to a
file and then having the executable (typically a linker or librarian) read
it's input commands from that text file. Unfortunately, some artificial
ILINK32 input line buffer length was too small a value to handle the long
list of objects. The error handling for that condition was poorly written so
that misleading error messages were output from the linker.
Interestingly enough, apparently no such limitation plagues TLIB, which
handles the long-lined response files just fine.
> Jason Loefer
> TGA Technologies, Inc.
> [EMAIL PROTECTED]
> 770-662-5585x123
>
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
