undefined reference to ftfont_variation_glyphs

undefined reference to ftfont_variation_glyphs

[Sebastian Rose]

Since a few days I cannot build CVS emacs 23 on debian.

$ gcc --version
gcc (Debian 4.3.3-3) 4.3.3

ftfont.o:(.data+0x68): undefined reference to `ftfont_variation_glyphs'


This happens after a fresh checkout on current Debian testing.


`ftfont_variation_glyphs()' is not always surounded with the same #ifdefs!


The function itself is surounded by:

#ifdef	HAVE_M17N_FLT
#ifdef	HAVE_LIBOTF
#ifdef	HAVE_OTF_GET_VARIATION_GLYPHS

   /* FUNCTION DEFINITION HERE */

#endif	/* HAVE_OTF_GET_VARIATION_GLYPHS */
#endif	/* HAVE_M17N_FLT */
#endif	/* HAVE_LIBOTF */


While declaration (line 384) and usage (line 431) of the function
`ftfont_variation_glyphs()' are surounded solely by:


#ifdef	HAVE_OTF_GET_VARIATION_GLYPHS

   /* FUNCTION DECLARATION HERE */

#endif	/* HAVE_OTF_GET_VARIATION_GLYPHS */



I'm not able to send a patch though, since I don't know which one is
wrong. Anyway, supplementing the #ifdefs around declaration and usage
with helps and I can build emacs.



Output of `sh$  make' _before_ the change:


ftfont.o:(.data+0x68): undefined reference to `ftfont_variation_glyphs'
collect2: ld returned 1 exit status
make[1]: *** [temacs] Fehler 1
make[1]: Leaving directory `/home/sebastian/develop/emacs-CVS/emacs/src'
make: *** [src] Fehler 2


Best Regards,

  Sebastian

Re: undefined reference to ftfont_variation_glyphs

[Sebastian Rose]

[-- Attachment #1: Type: text/plain, Size: 147 bytes --]

Sorry for answering my own mail here.

This is the fix I used (and that works fine):



<sh:/home/sebastian/emacs-CVS/emacs> cvs diff src/ftfont.c

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 1936 bytes --]

Index: src/ftfont.c
===================================================================
RCS file: /sources/emacs/emacs/src/ftfont.c,v
retrieving revision 1.45
diff -r1.45 ftfont.c
383a384,387
> 
> #ifdef HAVE_LIBOTF
> #ifdef HAVE_M17N_FLT
> #ifdef HAVE_OTF_GET_VARIATION_GLYPHS
385a390,392
> #endif	/* HAVE_OTF_GET_VARIATION_GLYPHS */
> #endif	/* HAVE_M17N_FLT */
> #endif	/* HAVE_LIBOTF */
424a432,433
> #ifdef HAVE_LIBOTF
> #ifdef HAVE_M17N_FLT
429a439,440
> #endif
> #endif
</#part>


  - Sebastian




Sebastian Rose <sebastian_rose@gmx.de> writes:
> Since a few days I cannot build CVS emacs 23 on debian.
>
> $ gcc --version
> gcc (Debian 4.3.3-3) 4.3.3
>
> ftfont.o:(.data+0x68): undefined reference to `ftfont_variation_glyphs'
>
>
> This happens after a fresh checkout on current Debian testing.
>
>
> `ftfont_variation_glyphs()' is not always surounded with the same #ifdefs!
>
>
> The function itself is surounded by:
>
> #ifdef	HAVE_M17N_FLT
> #ifdef	HAVE_LIBOTF
> #ifdef	HAVE_OTF_GET_VARIATION_GLYPHS
>
>    /* FUNCTION DEFINITION HERE */
>
> #endif	/* HAVE_OTF_GET_VARIATION_GLYPHS */
> #endif	/* HAVE_M17N_FLT */
> #endif	/* HAVE_LIBOTF */
>
>
> While declaration (line 384) and usage (line 431) of the function
> `ftfont_variation_glyphs()' are surounded solely by:
>
>
> #ifdef	HAVE_OTF_GET_VARIATION_GLYPHS
>
>    /* FUNCTION DECLARATION HERE */
>
> #endif	/* HAVE_OTF_GET_VARIATION_GLYPHS */
>
>
>
> I'm not able to send a patch though, since I don't know which one is
> wrong. Anyway, supplementing the #ifdefs around declaration and usage
> with helps and I can build emacs.
>
>
>
> Output of `sh$  make' _before_ the change:
>
>
> ftfont.o:(.data+0x68): undefined reference to `ftfont_variation_glyphs'
> collect2: ld returned 1 exit status
> make[1]: *** [temacs] Fehler 1
> make[1]: Leaving directory `/home/sebastian/develop/emacs-CVS/emacs/src'
> make: *** [src] Fehler 2
>
>
> Best Regards,
>
>   Sebastian
>

Re: undefined reference to ftfont_variation_glyphs

[Stefan Monnier]

> This is the fix I used (and that works fine):

Could you resend it in "unified diff" (or "context diff") format, please?


        Stefan

Re: undefined reference to ftfont_variation_glyphs

[Sebastian Rose]

[-- Attachment #1: Type: text/plain, Size: 239 bytes --]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
>> This is the fix I used (and that works fine):
>
> Could you resend it in "unified diff" (or "context diff") format, please?

Unified:

<sh:/.../emacs-CVS/emacs> cvs diff -u src/ftfont.c

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 1308 bytes --]

Index: src/ftfont.c
===================================================================
RCS file: /sources/emacs/emacs/src/ftfont.c,v
retrieving revision 1.45
diff -u -r1.45 ftfont.c
--- src/ftfont.c	11 Feb 2009 09:45:14 -0000	1.45
+++ src/ftfont.c	27 Mar 2009 21:34:17 -0000
@@ -381,8 +381,15 @@
 				    int *, int *));
 static Lisp_Object ftfont_otf_capability P_ ((struct font *));
 static Lisp_Object ftfont_shape P_ ((Lisp_Object));
+
+#ifdef HAVE_LIBOTF
+#ifdef HAVE_M17N_FLT
+#ifdef HAVE_OTF_GET_VARIATION_GLYPHS
 static int ftfont_variation_glyphs P_ ((struct font *, int c,
 					unsigned variations[256]));
+#endif	/* HAVE_OTF_GET_VARIATION_GLYPHS */
+#endif	/* HAVE_M17N_FLT */
+#endif	/* HAVE_LIBOTF */
 
 struct font_driver ftfont_driver =
   {
@@ -422,11 +429,15 @@
     NULL,
 #endif	/* not (HAVE_M17N_FLT && HAVE_LIBOTF) */
     NULL,			/* check */
+#ifdef HAVE_LIBOTF
+#ifdef HAVE_M17N_FLT
 #ifdef HAVE_OTF_GET_VARIATION_GLYPHS
     ftfont_variation_glyphs
 #else
     NULL
 #endif
+#endif
+#endif
   };
 
 extern Lisp_Object QCname;
</#part>

-- 
Sebastian Rose, EMMA STIL - mediendesign, Niemeyerstr.6, 30449 Hannover
Tel.:  +49 (0)511 - 36 58 472
Fax:   +49 (0)1805 - 233633 - 11044
mobil: +49 (0)173 - 83 93 417
Email: s.rose@emma-stil.de, sebastian_rose@gmx.de
Http:  www.emma-stil.de

Re: undefined reference to ftfont_variation_glyphs

[Chong Yidong]

Sebastian Rose <sebastian_rose@gmx.de> writes:

> Since a few days I cannot build CVS emacs 23 on debian.
>
> ftfont.o:(.data+0x68): undefined reference to `ftfont_variation_glyphs'

That's strange---I don't have libotf either, and I do not see this
problem.  Could you roll back a few revisions and check which checkin
caused the breakage on your side?

Re: undefined reference to ftfont_variation_glyphs

[Stefan Monnier]

> @@ -422,11 +429,15 @@
>      NULL,
>  #endif	/* not (HAVE_M17N_FLT && HAVE_LIBOTF) */
>      NULL,			/* check */
> +#ifdef HAVE_LIBOTF
> +#ifdef HAVE_M17N_FLT
>  #ifdef HAVE_OTF_GET_VARIATION_GLYPHS
>      ftfont_variation_glyphs
>  #else
>      NULL
>  #endif
> +#endif
> +#endif
>    };
 
Makes me wonder: how come HAVE_OTF_GET_VARIATION_GLYPHS is defined for
you if ftfont_variation_glyphs isn't?


        Stefan

Re: undefined reference to ftfont_variation_glyphs

[Sebastian Rose]

Chong Yidong <cyd@stupidchicken.com> writes:

> Sebastian Rose <sebastian_rose@gmx.de> writes:
>
>> Since a few days I cannot build CVS emacs 23 on debian.
>>
>> ftfont.o:(.data+0x68): undefined reference to `ftfont_variation_glyphs'
>
> That's strange---I don't have libotf either, and I do not see this
> problem.  Could you roll back a few revisions and check which checkin
> caused the breakage on your side?

I _have_ libotf (see below).

That's the problem I believe. If one has libotf, the function is
declared and used, but never defined. The function definition is
enclosed by additional #ifdefs.

I'm afraid I won't be of great help here, since my my knowledge of
emacs' code tends to zero.


> problem.  Could you roll back a few revisions and check which checkin
> caused the breakage on your side?

The last time I could build emacs was 13. March 2009. But I don't update
on regular basis, just once or twice a week. So this will take some time
to find out, but I'll try.




This is the conclusion of ./configure in a fresh checked out emacs
directory (which shows that libotf was found):



Configured for `i686-pc-linux-gnu'.

  Where should the build process find the source code?    /home/sebastian/develop/emacs-CVS/emacs
  What operating system and machine description files should Emacs use?
        `s/gnu-linux.h' and `m/intel386.h'
  What compiler should emacs be built with?               gcc -g -O2 -Wno-pointer-sign
  Should Emacs use the GNU version of malloc?             yes
      (Using Doug Lea's new malloc from the GNU C Library.)
  Should Emacs use a relocating allocator for buffers?    yes
  Should Emacs use mmap(2) for buffer allocation?         no
  What window system should Emacs use?                    x11
  What toolkit should Emacs use?                          GTK
  Where do we find X Windows header files?                Standard dirs
  Where do we find X Windows libraries?                   Standard dirs
  Does Emacs use -lXaw3d?                                 no
  Does Emacs use -lXpm?                                   yes
  Does Emacs use -ljpeg?                                  yes
  Does Emacs use -ltiff?                                  yes
  Does Emacs use a gif library?                           yes -lgif
  Does Emacs use -lpng?                                   yes
  Does Emacs use -lrsvg-2?                                yes
  Does Emacs use -lgpm?                                   yes
  Does Emacs use -ldbus?                                  yes
  Does Emacs use -lfreetype?                              yes
  Does Emacs use -lm17n-flt?                              no
  Does Emacs use -lotf?                                   yes
  Does Emacs use -lxft?                                   yes
  Does Emacs use toolkit scroll bars?                     yes


configure: creating ./config.status
config.status: creating Makefile
config.status: creating lib-src/Makefile.c
config.status: creating oldXMenu/Makefile
config.status: creating doc/emacs/Makefile
config.status: creating doc/misc/Makefile
config.status: creating doc/lispintro/Makefile
config.status: creating doc/lispref/Makefile
config.status: creating src/Makefile.c
config.status: creating lwlib/Makefile
config.status: creating lisp/Makefile
config.status: creating leim/Makefile
config.status: creating src/config.h
config.status: executing default commands
creating src/epaths.h
creating lib-src/Makefile
creating src/Makefile





-- 
Sebastian Rose, EMMA STIL - mediendesign, Niemeyerstr.6, 30449 Hannover
Tel.:  +49 (0)511 - 36 58 472
Fax:   +49 (0)1805 - 233633 - 11044
mobil: +49 (0)173 - 83 93 417
Email: s.rose@emma-stil.de, sebastian_rose@gmx.de
Http:  www.emma-stil.de

Re: undefined reference to ftfont_variation_glyphs

[Sebastian Rose]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> @@ -422,11 +429,15 @@
>>      NULL,
>>  #endif	/* not (HAVE_M17N_FLT && HAVE_LIBOTF) */
>>      NULL,			/* check */
>> +#ifdef HAVE_LIBOTF
>> +#ifdef HAVE_M17N_FLT
>>  #ifdef HAVE_OTF_GET_VARIATION_GLYPHS
>>      ftfont_variation_glyphs
>>  #else
>>      NULL
>>  #endif
>> +#endif
>> +#endif
>>    };
>  
> Makes me wonder: how come HAVE_OTF_GET_VARIATION_GLYPHS is defined for
> you if ftfont_variation_glyphs isn't?
>
>
>         Stefan

I don't know anything about the emacs code. I think HAVE_LIBOTF is
defined, since ./configure finds libotf.

If HAVE_OTF_GET_VARIATION_GLYPHS is defined in this case, the culprit
might be HAVE_M17N_FLT.

No matter which one is defined or not, it seems wrong to enclose a
functions declaration, usage, and definition in different sets of
include guards.


Regards,

   Sebastian

Re: undefined reference to ftfont_variation_glyphs

[Sebastian Rose]

Sebastian Rose <sebastian_rose@gmx.de> writes:
> The last time I could build emacs was 13. March 2009. But I don't update
> on regular basis, just once or twice a week. So this will take some time
> to find out, but I'll try.


Hmm - it seems the error emerged either before my last successfull build
(i.e. before 13. March) and is related to a change in libotf.


If I pull the version of 13. March (the one I could build by then), I
can't build on my current system today. Looks like I had still had
libotf 0.9.8.1 on my system. Function OTF_get_variation_glyphs is quite
new in 0.9.9


/usr/include/otf.h says:

   /* Version name of this library.  */
   #define LIBOTF_VERSION "0.9.9"


Debian Changlog
(http://packages.debian.org/changelogs/pool/main/libo/libotf/libotf_0.9.9-1/changelog)
says this version is in testing since Tue, 03 Mar 2009:

   libotf  (0.9.9-1) unstable; urgency=low
  
     * New upstream release 0.9.9.
     * debian/copyright: update the copyright year.
     * debian/control: inherit Priority and Section.
  
   -- Harshula Jayasuriya <harshula@gmail.com>  Tue, 03 Mar 2009 21:02:52 +1100 









  - Sebastian

Re: undefined reference to ftfont_variation_glyphs

[Chong Yidong]

Sebastian Rose <sebastian_rose@gmx.de> writes:

> This is the fix I used (and that works fine):

I've checked in your patch (with a slight correction).  Thanks.

Re: undefined reference to ftfont_variation_glyphs

[Sebastian Rose]

Chong Yidong <cyd@stupidchicken.com> writes:

> Sebastian Rose <sebastian_rose@gmx.de> writes:
>
>> This is the fix I used (and that works fine):
>
> I've checked in your patch (with a slight correction).  Thanks.

Now it works :)
Pulled emacs into a new directory and build emacs successfully.

  Thanks a lot

Re: undefined reference to ftfont_variation_glyphs

[Kenichi Handa]

Sorry for the late response on this matter.

In article <873acy3n9m.fsf@kassiopeya.MSHEIMNETZ>, Sebastian Rose <sebastian_rose@gmx.de> writes:

> Since a few days I cannot build CVS emacs 23 on debian.

> $ gcc --version
> gcc (Debian 4.3.3-3) 4.3.3

> ftfont.o:(.data+0x68): undefined reference to `ftfont_variation_glyphs'

[...]
> While declaration (line 384) and usage (line 431) of the function
> `ftfont_variation_glyphs()' are surounded solely by:

> #ifdef	HAVE_OTF_GET_VARIATION_GLYPHS

>    /* FUNCTION DECLARATION HERE */

> #endif	/* HAVE_OTF_GET_VARIATION_GLYPHS */

Yes, it's a bug, and thank you for the patch.  But, actually
ftfont_variation_glyphs is usable even without
HAVE_M17N_FLT.  So, the right fix is to define it without
checking HAVE_M17N_FLT.

Chong Yidong <cyd@stupidchicken.com> writes:

> I've checked in your patch (with a slight correction).  Thanks.

I've just installed another fix.

---
Kenichi Handa
handa@m17n.org

Re: undefined reference to ftfont_variation_glyphs

[Sebastian Rose]

Kenichi Handa <handa@m17n.org> writes:
> I've just installed another fix.

Confirmed. It works. Thanks a lot,


Sebastian