Re: [ft] Compiling freetype 2.3.9 with bcc fails

[mpsuzuki]

Hi,

Thank you for the experiment, yes "-o" was the root of
our bcc32 problem. I reached same conclusion. My misunderstanding
about 1-step & 2-step was solved. I didn't receive the
error you got (about HELLO.OBJ), but I agree with your
observation that "-o" causes problem.

Also thank you for the proposal to use "-n" option to
specify the directory of the executable. But now I'm
trying to use "-e" option to specify the pathname of
the executable. If you have sparetime, please check
"-e" accepts the pathname including directory, aslike

        bcc32 -eobjs\apinames.exe src\tools\apinames.c

In my environment, it finishes successfully, and
apinames.exe does not crash.

The reason why I try "-e" instead of "-n" is that the
default output filename is dependent with the compilers.
Most Unix compilers generates "a.out" from "hello.c",
but bcc32 generates "hello.exe" from "hello.c" by default.
So if I use "-n" and leave the output filename for
compilers' default, we don't know the output filename.

Regards,
mpsuzuki

On Tue, 14 Jul 2009 08:40:54 +0200
Mirco Babin <address@hidden> wrote:

>Hi,
>
>Compiling test.c fails:
>bcc32 -ohello.exe hello.c
>CodeGear C++ 5.93 for Win32 Copyright (c) 1993, 2007 CodeGear
>hello.c:
>Turbo Incremental Link 5.81 Copyright (c) 1997-2008 CodeGear
>Fatal: Unable to open file 'HELLO.OBJ'
>
>This works:
>bcc32 hello.c
>CodeGear C++ 5.93 for Win32 Copyright (c) 1993, 2007 CodeGear
>hello.c:
>Turbo Incremental Link 5.81 Copyright (c) 1997-2008 CodeGear
>
>Hello.exe is created and works fine.
>
>
>
>I think your conclusion about the -o switch (it may not be used for an
>executable name) is correct.
>I found out that bcc32 -n./objs hello.c outputs the .obj and .exe file to
>the ./objs subdirectory
>
>My conclusion about the current directory is wrong. It is the -o flag that
>may not be used.
>
>Regards,
>Mirco
>