freetype-devel
[Top][All Lists]
Advanced

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

Re: [ft-devel] failed to compile ftvalid.c


From: Chia-I Wu
Subject: Re: [ft-devel] failed to compile ftvalid.c
Date: Thu, 17 Nov 2005 17:04:43 +0800
User-agent: Mutt/1.5.11

On Thu, Nov 17, 2005 at 03:47:38PM +0900, address@hidden wrote:
> Hi,
> 
> On Thu, 17 Nov 2005 11:46:09 +0900
> address@hidden wrote:
> Excuse me, you received this error in compiling ftvalid.c
> into ftvalid.o? Or, you received it in linking ftvalid.o
> to ftvalid executable?
It's in linking.
> If it's in linking, it's a bit complexed problem. GNU ld
> with --retain-symbols-file removes unlisted symbols from
> .symtab, but don't remove them from .dynsym. As a result,
> I cannot find FT_Free_Debug in
>       "nm -a freetype2/objs/.libs/libfreetype.so",
> but I can find it in
>       "nm -D freetype2/objs/.libs/libfreetype.so".
On my machine,

$ nm -a objs/.libs/libfreetype.so | grep Free_Debug
00006cb8 t FT_Free_Debug
$ nm -D objs/.libs/libfreetype.so | grep Free_Debug
(gives nothing)
$ nm --version
GNU nm 2.16.91 20050902 Debian GNU/Linux

> 
> When I link ftvalid.o refering FT_Free_Debug(),
> with libfreetype.so that does not have FT_Free_Debug() in its
> .symtab, GNU ld detects that FT_Free_Debug() exists in
> libfreetype.so, and linking is finished successfully.
> When I add "-Wl,--trace-symbol=FT_Free_Debug", I receive
> following output. GNU ld detects FT_Free_Debug() in
> libfreetype.so.
> 
> $ gcc -Wl,--trace-symbol=FT_Free_Debug -Wall -ansi -pedantic \
>   -DFT_DEBUG_LEVEL_ERROR -DFT_DEBUG_LEVEL_TRACE -DFT_DEBUG_MEMORY \
>   -o ./bin/.libs/ftvalid \
>      ./obj/ftvalid.o ./obj/common.o \
>      ../freetype2/objs/.libs/libfreetype.so \
>      -lz 
> 
> ./obj/ftvalid.o: reference to FT_Free_Debug
> ../freetype2/objs/.libs/libfreetype.so: definition of FT_Free_Debug
> 

$ gcc -Wl,--trace-symbol=FT_Free_Debug -Wall -ansi -pedantic \
-DFT_DEBUG_LEVEL_ERROR -DFT_DEBUG_LEVEL_TRACE -DFT_DEBUG_MEMORY -o \
./bin/.libs/ftvalid ./obj/ftvalid.o ./obj/common.o \
../freetype2/objs/.libs/libfreetype.so -lz

./obj/ftvalid.o: reference to FT_Free_Debug
./obj/ftvalid.o: In function `run_ot_validator':
/home/olvaffe/workshop/freetype2-local/ft2demos/src/ftvalid.c:447:
undefined reference to `FT_Free_Debug'
./obj/ftvalid.o: In function `run_gx_validator':
/home/olvaffe/workshop/freetype2-local/ft2demos/src/ftvalid.c:498:
undefined reference to `FT_Free_Debug'
./obj/ftvalid.o: In function `run_ckern_validator':
/home/olvaffe/workshop/freetype2-local/ft2demos/src/ftvalid.c:566:
undefined reference to `FT_Free_Debug'
collect2: ld returned 1 exit status

$ gcc --version
gcc (GCC) 4.0.3 20051023 (prerelease) (Debian 4.0.2-3)
$ ld --version
GNU ld version 2.16.91 20050902 Debian GNU/Linux
> I guess this is the known behaviour of GNU ld, See:
>       http://sourceware.org/ml/binutils/2001-12/msg00143.html
> 
> How did you remove FT_Free_Debug() completely?
Same error message.
> 
> P.S.
> BTW, now I think about this issue: the tools outside of libfreetype
> should not refer FT_Alloc_Debug(), FT_Free_Debug() etc etc anymore.
> Therefore, ftvalid.c should include ftdbgmem.c by itself?
I suggest exporting another function, which simply calls FT_FREE, to
free the tables.

When FT_DEBUG_MEMORY is not defined, the clients can `free' the table
without causing any problem.  But when it is, this confuses leak
detection (some FT_ALLOC'ed memories are not FT_FREE'ed) and causes
double free.

Or, we can have two versions of validating.  One does everything
automatically, like the current one, and free the tables before
returning.  The other only validates.  Clients should prepare buffers
and FT_Load_Sfnt_Table themselves.

-- 
Regards,
olv




reply via email to

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