Mail Archives: djgpp/1999/10/13/16:45:49
I'll reply to my own post here, not having seen any answer yet.
But I believe that the unresolved references I am referring to, as well
as the "other" linker reporting a problem with not finding an entry
point, has to do with mixing and matching the linkers and also failing
to realize that when I invoke the linker, I must supply all the options
including names of standard libraries on the command line.
So is there anyone here who has successfully configured---what is it?
the specs file?--on their system such that they can use the one 'ld'
from the standard distribution to get unresolved externals while using
the 'ld' that comes with RSXNTDJ to make the exe? I also use rhide to
build the 32-bit MSDOS programs for testing: is the C standard library
being referenced different from the one in /djgpp/lib, and if so, how
do I know I am not getting a buggy (earlier version) of a system call
than the one used if I weren't using RSXNTDJ??
Mavi Gozler <MaviGozler AT yahoo DOT com> wrote:
> "Johan Venter" <jventer AT writeme DOT com> wrote:
> > Mavi Gozler <MaviGozler AT yahoo DOT com> wrote in message
> > news:7tuuqf$dqs$1 AT nnrp1 DOT deja DOT com...
> > >
> > > The question is: how can the configuration be adjusted or deal
with
> > > the undefined references? The makefile is rather big to post, but
> it
> > > can be posted it if there aren't some things that can be done to
> check
> > > the system in general or the problem is not evident here.
> >
> > You've failed to mention what version of RSXNTDJ you are using (1.5
> is the
> > latest). Please see my RSXNTDJ HOWTO at http://surf.to/rsxntdj for
> information
> > on setting it up correctly.
> >
> > --
> > Johan Venter
> > ICQ 3643877 - jventer AT writeme DOT com
> > The TPU DJGPP Interest Group - http://surf.to/djgppig
> > The RSXNTDJ 1.5 HOWTO - http://surf.to/rsxntdj
>
> Yes, I realized I had forgotten to give vital information about what
> tools I was using just after I posted the message.
>
> RSXNTDJ is ver 1.50 with all the fixes and patches performed (without
> difficulty) and obtained from your web site.
>
> Most everything else is the latest as well:
> C:\>gcc -v
> Reading specs from c:/djgpp/rsxntdj/lib/specs
> gcc driver version 2.95.1 19990816 (release) executing gcc version
2.8.1
> C:\>ld -v
> GNU ld version 2.8.1 (with BFD 2.8.1)
> C:\>ldrsx -v
> ld version 2.7 (with BFD 2.7)
> C:\>cpp -v
> GNU CPP version 2.7.2.1 (80386, BSD syntax)
> #include "..." search starts here:
> #include <...> search starts here:
> c:\djgpp\rsxntdj\INCLUDE\MSSDK
> d:\MSSDK\INCLUDE
> c:\djgpp\rsxntdj\INCLUDE\WIN32
> c:\djgpp\rsxntdj\INCLUDE
> /usr/local/include
> /usr/local/go32/include
> /usr/local/lib/gcc-lib/go32/2.7.2.1/include
> /usr/include
> End of search list.
> C:\>make -v
> GNU Make version 3.76.1, by Richard Stallman and Roland McGrath.
>
> DJ library is 2.02.
> (Did I miss something?)
>
> Although I now have another (new) problem to describe below, I solved
> the problem I originally posted: what I found was that I had
specified
> in the makefile as an include directory (-I option to gccw32) the
> directory '/djgpp/include', and so in particular the 'ctype.h' was
> being read from there rather than from '/djgpp/rsxntdj/include' where
> it should have been read as a standard header.
>
> But the new problem may be with a confusion of which link editor (ld)
> to use. In my makefile, I have the following lines (edited a bit
here):
>
> --------start of makefile contents------
> PROJECT = my.exe
> DEFINES = VERBOSE=2 NDBM
> INCLUDES = /projects/inifsys /projects/src/crypto /projects/ndbm \
> /projects/src/mss12 /projects/src/misc
> PROJ_BASENAMES = qsupport bldpage draw gif html http ll_msort \
> qc2gif qcdbm qcfonts admin readqc
> LIBS = /projects/qc/fonts/librfontw.a /projects/src/misc/libgenw.a
\
> /projects/src/mss12/libmssw.a /projects/ndbm/libndbmw.a
\
> /projects/inifsys/libiniw.a
> LIBPATHS =
> OBJECTS_DIR = $(TMP)/obj/
>
> ifdef check
> LD = ld
> else
> LD = ldrsx
> endif
>
> OBJECTS_DIR := $(subst \,/,$(OBJECTS_DIR))
> SOURCES = $(addsuffix .c,$(PROJ_BASENAMES))
> OBJECTS = $(addsuffix .o,$(PROJ_BASENAMES))
> ifdef debug
> CFLAGS = -Wall -g $(addprefix -D,$(DEFINES)) $(addprefix -
I,$(INCLUDES))
> LDFLAGS = -g $(addprefix -L,$(LIBPATHS))
> else
> CFLAGS = -Wall -O $(addprefix -D,$(DEFINES)) $(addprefix -
I,$(INCLUDES))
> LDFLAGS = $(addprefix -L,$(LIBPATHS))
> endif
> CFLAGS := $(CFLAGS) $(MTFLAG) $(DLLFLAGS) $(CRTFLAG)
>
> all: $(PROJECT)
>
> ifdef check
> $(PROJECT): $(addprefix $(OBJECTS_DIR),$(OBJECTS)) $(LIBS)
> echo Link Editor is 'ld': Do not use to build Windows executables!
> echo Use only to check unresolved externals
> echo make sure you use 'ldrsx' to build the final executable!
> $(LD) $(LDFLAGS) -o $@ $(addprefix $(OBJECTS_DIR),$(OBJECTS))$(LIBS)
> else
> $(PROJECT): $(addprefix $(OBJECTS_DIR),$(OBJECTS))$(LIBS)
> echo Link Editor is 'ldrsx': gives no error info on unresolved
> echo externals. Use 'make check=1' to get regular 'ld' to check for
> echo unresovled externals, then just 'make' for building the final
> echo executable
> $(LD) $(LDFLAGS) -o $@ $(addprefix $(OBJECTS_DIR),$(OBJECTS))
$(LIBS)
> endif
>
> $(addprefix $(OBJECTS_DIR),%.o): %.c
> $(CC) $(CFLAGS) -c -o $@ $<
>
> clean:
> $(RM) $(addprefix $(OBJECTS_DIR),$(OBJECTS)) $(PROJECT)
>
> --------end of makefile contents------
>
> You can see that I use the ld that comes "standard" as the one to
check
> for missing references using a 'make check=1' call; thereafter a
> simple 'make' is intended to call the 'ld' that comes with RSXNTDJ,
> which is named 'ldrsx' in the /djgpp/bin directory.
>
> The output from the 'make check=1' call produces a huge stream of
> undefined references, namely to standard C library calls, such as all
> calls in stdlib (free, malloc, exit, etc.), in string (strcmp, strdup,
> strcpy, strcat, etc.), in ctype (namely to _ctype), and so on.
>
> Then just entering 'make' alone follows, and the output is:
> C:\>make
> [echoed reminder text deleted]
> ldrsx -o my.exe c:/temp/obj/qsupport.o c:/temp/obj/bldpage.o
> c:/temp/obj/draw.o c:/temp/obj/gif.o c:/temp/obj/html.o
> c:/temp/obj/http.o c:/temp/obj/ll_msort.o c:/temp/obj/qc2gif.o
> c:/temp/obj/qcdbm.o c:/temp/obj/qcfonts.o c:/temp/obj/qcuser.o
> c:/temp/obj/admin.o c:/temp/obj/readqc.o
> /projects/qc/fonts/librfontw.a /projects/src/misc/libgenw.a
> /projects/src/mss12/libmssw.a /projects/ndbm/libndbmw.a
> /projects/inifsys/libiniw.a
> C:\DJGPP\BIN/ldrsx.exe: warning: cannot find entry symbol start;
> defaulting to 000018d0
>
> The unresolved standard C library calls and the warning from ldrsx.exe
> means I am not going to risk running the EXE file it produced.
>
> Please note this is a console ("character mode") Win32 application,
> with only a main() and no WinMain() or DLLEntryPoint() [yet], and
> gccw32 is invoked with no option '-Z' passed during the making of the
> sources (either in libraries or main project).
>
> The question is how to get clean output from the call to 'ld.exe' and
> to 'ldrsx.exe'.
>
> Thanks for your assistance.
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>
--
On UNIX: "This isn't rocket science, you know."
MsgID: <5dfp6t$9jp AT web DOT nmti DOT com>
Sent via Deja.com http://www.deja.com/
Before you buy.
- Raw text -