discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Troubles with GNUstep Make


From: Tim Kack
Subject: Re: Troubles with GNUstep Make
Date: Tue, 17 Mar 2009 22:20:34 +0100

Hi Torli,

First of all - sorry if I repost the obvious - Adam and Richard already has pinpointed the problem pretty much.

So I decided to see what exacly is going on to explain this behavior.
I replicated the behavior perfectly when I forgot to change _OBJC_FILES to match the TOOL_NAME.

I.e
TOOL_NAME = simpleS
simple_OBJC_FILES = source.m

If I run it with above setting and using 'make messages=yes' I get the following output:

This is gnustep-make 2.0.8. Type 'make print-gnustep-make-help' for help.
Making all for tool simpleS...
cd .; \
    /usr/GNUstep/System/Library/Makefiles/mkinstalldirs ./obj
make -f GNUmakefile --no-print-directory --no-keep-going \
    internal-tool-compile \
    GNUSTEP_TYPE=tool \
    GNUSTEP_INSTANCE=simpleS \
    GNUSTEP_OPERATION=compile \
    GNUSTEP_BUILD_DIR="." \
    _GNUSTEP_MAKE_PARALLEL=yes
gcc  -rdynamic       -fgnu-runtime -o obj/simpleS \
         \
             -L/home/tkack/GNUstep/Library/Libraries -L/usr/GNUstep/Local/Library/Libraries -L/usr/GNUstep/System/Library/Libraries     -lgnustep-base   -lpthread -lobjc   -lm
/usr/lib/gcc/i486-linux-gnu/4.3.2/../../../../lib/crt1.o: In function `_start':
(.text+0x18): undefined reference to `main'
collect2: ld returned 1 exit status


Note that the call to gcc start with 'gcc  -rdynamic' and it should produce object file 'obj/simpleS'.
So I corrected my GNUmakefile to be:

TOOL_NAME = simpleS
simpleS_OBJC_FILES = source.m

Ran 'make clean' followed by 'make messages=yes'

The following output is seen (skipping the make -f part)

gcc source.m -c \
          -MMD -MP -DGNUSTEP -DGNUSTEP_BASE_LIBRARY=1 -DGNU_GUI_LIBRARY=1 -DGNU_RUNTIME=1 -DGNUSTEP_BASE_LIBRARY=1 -D_REENTRANT -fPIC -g -Wall -DDEBUG -fno-omit-frame-pointer -DGSWARN -DGSDIAGNOSE -Wno-import -g -fno-strict-aliasing -fgnu-runtime -fconstant-string-class=NSConstantString -I. -I/home/tkack/GNUstep/Library/Headers -I/usr/GNUstep/Local/Library/Headers -I/usr/GNUstep/System/Library/Headers \
           -o obj/source.m.o
gcc  -rdynamic       -fgnu-runtime -o obj/simpleS \
        ./obj/source.m.o \
             -L/home/tkack/GNUstep/Library/Libraries -L/usr/GNUstep/Local/Library/Libraries -L/usr/GNUstep/System/Library/Libraries     -lgnustep-base   -lpthread -lobjc   -lm


Note - there is two gcc runs.
First is compiling source.m to source.m.o.
Second run is the -rdynamic flag added. GCC docs are telling us:

-rdynamic
    Pass the flag -export-dynamic to the ELF linker, on targets that support it. This instructs the linker to add all symbols, not only used ones, to the dynamic symbol table. This option is needed for some uses of dlopen or to allow obtaining backtraces from within a program.

But the problem is that we in the first case do not have a source.m.o compiled and hence cannot the dynamic linker find a main() function anywhere.

(Sorry for the longwinded explanation, but I was just curious)

Actually - I wish that there was some logic that checked TOOL_NAME had a matching toolname_OBJC_FILES. Perhaps we should have stricter checking in the make package for that?

Cheers,
Tim

2009/3/17 Torli Birnbauer <gootobi@gmail.com>
On Tue, 2009-03-17 at 19:59 +0000, Richard Frith-Macdonald wrote:
On 17 Mar 2009, at 19:45, Torli Birnbauer wrote: > I have recently installed GNUstep binaries with Synaptic Package > Manager on my Ubuntu system, and subsequently started to study the > Base Programming Manual, where I came across the following: > > > Now create the makefile, again using your favourite text editor, and > save it in the same project directory with the filename GNUmakefile. > > include $(GNUSTEP_MAKEFILES)/common.
make > TOOL_NAME = LogTest > LogTest_OBJC_FILES = source.m > include $(GNUSTEP_MAKEFILES)/tool.make > > If you look at the makefile above you will notice the two lines that > tell the make utility to build a tool with the filename LogTest from > the Objective-C source file source.m. You could copy and modify this > makefile for later projects you may have: just change the tool name > and list the new source files. > > The trouble is that changing the line {{ TOOL_NAME = LogTest }} to > something else, make does not work. > It looks as if certain names like {{ LogTest, simple, ...}} were pre- > compiled into GNUstep make. Is this a known undocumented problem, or > will building GNUstep Make from source solve this problem? Neither ... there's no evidence of any problem with gnustep-make there. What it looks like is that there is a problem with your source code. The makefile is trying to link the tool WriteStr2File and has found that the source code (whatever that is in your case) does not contain the required 'main()' function. You can do 'make messages=yes' to get more information about exactly what it's doing.

Richard, this is a very interesting hypothesis you've brought up. I Know to you it must look credible, but it is a total hogwash to me! If I change the setting of {{ TOOL_NAME }} variable from  {{ TOOL_NAME = WriteStr2File }} back to {{ TOOL_NAME = LogTest }} or to {{ TOOL_NAME = simple }}, as can be found in the "Make Utility" documentation on page http://www.gnustep.org/developers/documentation.html under the subtitle "1.2 Structure of a Makefile" the compilation and linking finishes flawlessly.

Torli,


_______________________________________________
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep



reply via email to

[Prev in Thread] Current Thread [Next in Thread]