FLTK-1.3.3 build fail on linux

[Qurban Ullah]

FLTK-1.3.3 build failed on linux x86_64 with error massege.

configure log file is also attatched.

Compiling cube.cxx...
Linking cube...
../lib/libfltk_gl.a(gl_draw.o): In function `gl_font(int, int)':
gl_draw.cxx:(.text._Z7gl_fontii+0x38): undefined reference to `Fl_XFont_On_Demand::value()'
collect2: error: ld returned 1 exit status
Makefile:498: recipe for target 'cube' failed
make[1]: *** [cube] Error 1
Makefile:24: recipe for target 'all' failed
make: *** [all] Error 1

[Greg Ercolano]

On 11/05/14 06:45, Qurban Ullah wrote:
> FLTK-1.3.3 build failed on linux x86_64 with error massege.
> configure log file is also attatched.
> Compiling cube.cxx...
> Linking cube...
> ../lib/libfltk_gl.a(gl_draw.o): In function `gl_font(int, int)':
> gl_draw.cxx:(.text._Z7gl_fontii+0x38): undefined reference to 'Fl_XFont_On_Demand::value()'
> collect2: error: ld returned 1 exit status

Interesting.

I can't seem to replicate on my x86_64 linux box with 1.3.3
and that same configure line:

./configure --prefix=/usr --enable-threads --enable-xft --enable-shared

Curious what distro you have, so we can replicate.

Not sure I know the answer, but I /think/ this might be manolo's
territory. Perhaps of some help to any other devs looking into this,
given the above error:

From what I can tell, gl_draw.cxx's gl_font() references the
method 'Fl_XFont_On_Demand::value()' indirectly via this line (line 87):

XFontStruct *font = fl_xfont;

..which I /think/ triggers (in a round-about way) this method defined in FL/x.H:

operator XFontStruct*() { return value(); }

It would appear the class "Fl_XFont_On_Demand" should be FL_EXPORTED,
but I don't think it is. I see this class being defined in libfltk.a
but not in libfltk.so.

Since I can't replicate, I can't verify this is the issue, but maybe
try changing this line in FL/x.H:

BEFORE: class Fl_XFont_On_Demand
AFTER: class FL_EXPORT Fl_XFont_On_Demand

..and then do a '( make clean; make )'..?

If that doesn't help, undo that change.
Either way, let us know.

[Greg Ercolano]

On 11/05/14 09:52, Greg Ercolano wrote:
> Since I can't replicate, I can't verify this is the issue, but maybe
> try changing this line in FL/x.H:
>
> BEFORE: class Fl_XFont_On_Demand
> AFTER: class FL_EXPORT Fl_XFont_On_Demand
>
> ..and then do a '( make clean; make )'..?

Doing some tests, I have a higher confidence the above may help the OP.

That change seems to help Fl_XFont_On_Demand::value() change from "HIDDEN" to "DEFAULT":

BEFORE:
$ readelf -Ws libfltk.a | grep Fl_XFont_On_Demand
127: 0000000000000000 739 FUNC GLOBAL HIDDEN 33 _ZN18Fl_XFont_On_Demand5valueEv
^^^^^^
AFTER:
$ readelf -Ws libfltk.a | grep Fl_XFont_On_Demand
127: 0000000000000000 739 FUNC GLOBAL DEFAULT 33 _ZN18Fl_XFont_On_Demand5valueEv
^^^^^^^

As a side note: perhaps we should add "-z,defs" to the -Wl flag
which seems to force detecting this kind of thing.

The following page gave me this idea:
http://stackoverflow.com/questions/1617286/easy-check-for-unresolved-symbols-in-shared-libraries

For example, on my system that seems to build shared FLTK libs without error,
and the cube demo runs just fine, if I make the following change to the makeinclude:

BEFORE: DSOCOMMAND = $(CXX) $(DSOFLAGS) -Wl,-soname,$@ $(LDLIBS) -shared -fPIC -o
AFTER: DSOCOMMAND = $(CXX) $(DSOFLAGS) -Wl,-z,defs,-soname,$@ $(LDLIBS) -shared -fPIC -o

..then during a rebuild, it complains right away about Fl_XFont_On_Demand not being
defined when the above FL_EXPORT is not included, looking very similar to the OP's
error.

I get this error early, during construction of the lib (not during link of the cube demo):

gl_draw.o: In function `gl_font(int, int)':
gl_draw.cxx:(.text._Z7gl_fontii+0x3b): undefined reference to `Fl_XFont_On_Demand::value()'
collect2: ld returned 1 exit status
make[1]: *** [libfltk_gl.so.1.3] Error 1
make[1]: Leaving directory `/usr/local/src/fltk-1.3.x-svn/src'

make: *** [all] Error 1

..and if I put the FL_EXPORT back (suggested change), that error goes away
and all of FLTK builds OK.

So in other words, making that change may help us detect unresolved symbols
during development on systems that might otherwise not show the problem.

Just a thought, I don't fully understand shared builds on linux, and don't
consider my understanding complete on the matter; I'm definitely no guru
regarding shared lib builds.

[Qurban Ullah]

Thank sir, build succeded, build faiedl may be due to some veriable defined already in terminal. I open new terminal and succeded to compile with out any error.

Sent from Samsung Mobile

--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[MacArthur, Ian (Selex ES, UK)]

> I can't seem to replicate on my x86_64 linux box with 1.3.3
> and that same configure line:
>
> ./configure --prefix=/usr --enable-threads --enable-xft --enable-shared
>
> Curious what distro you have, so we can replicate.
>
> Not sure I know the answer, but I /think/ this might be manolo's
> territory. Perhaps of some help to any other devs looking into
> this,
> given the above error:

History:

The XFont_On_Demand stuff was added (mainly by me) though the design and implementation came from Aaron Ucko, and address an issue with core fonts on X11 systems (in particular it resolved some packaging issue on debian, which is what was driving Ucko's effort, IIRC.)

However; it should be entirely internal to fltk, so there should be no need for this class to be visible.

At least, I think that there is no need for it to be visible...

Note in particular that the behaviour of the XFont_On_Demand class changes depending on whether the core font system compiled into fltk is XFT or just the X11-core fonts.

If the X11-core fonts are used, then you *always* get an X-font anyway, so the XFont_On_Demand stuff is essentially null.
Under XFT, which is our normal default case these days, then the XFont_On_Demand stuff does actually do something, in the particular special case that you need to find a X11-core font to "match" the currently selected (XFT) font. (E.g. to render text into an XGL surface, which needs a core font not an XFT font...)

So... that's what it is for. I don't think it should need to be visible externally.

I do not know why the OP's build did not work, as it should have.






Selex ES Ltd
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL
A company registered in England & Wales. Company no. 02426132
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

[Greg Ercolano]

On 11/06/14 04:07, MacArthur, Ian (Selex ES, UK) wrote:
> The XFont_On_Demand stuff was added (mainly by me) though the design and implementation came from Aaron Ucko, and address an issue with core fonts on X11 systems (in particular it resolved some packaging issue on debian, which is what was driving Ucko's effort, IIRC.) However; it should be entirely internal to fltk, so there should be no need for this class to be visible. At least, I think that there is no need for it to be visible...

Am I right in thinking the issue is that fltk_gl.so wants to use it,
and it's defined in libfltk, so for the reference to resolve across
the two libs, it has to be public?

> I do not know why the OP's build did not work, as it should have.

Right, I'm kinda confused by that too..
But is it the case that there's a reference across the two libs?

[Ian MacArthur]

Ummm, maybe... I am not so sure now...

I thought it was internal to the font handling code, so should all be in the core fltk lib. But maybe bits of it do leech out into the fltk_gl lib too. I did not expect that to be the case though.