Closed Bug 732340 Opened 12 years ago Closed 12 years ago

libxul.so: hidden symbol `int SortedArrayOf<Record<LangSys> >::search<unsigned int>(unsigned int const&) const' isn't defined

Categories

(Core :: Graphics, defect)

Product:
Core
Component:
Graphics
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
blocker

Tracking

()

Status:
RESOLVED DUPLICATE of bug 771222

People

(Reporter: ewong, Assigned: kdevel)

References

Details

Attachments

(1 file, 2 obsolete files)

patch: instanciate templates explictly v2 (moved to .cc)
595 bytes, patch
mozilla
: review-
Details | Diff | Splinter Review 
While linking, the linker chokes stating :
/usr/lib/gcc/i486-slackware-linux/4.3.3/../../../../i486-slackware-linux/bin/ld: libxul.so: hidden symbol `int SortedArrayOf<Record<LangSys> >::search<unsigned int>(unsigned int const&) const' isn't defined
/usr/lib/gcc/i486-slackware-linux/4.3.3/../../../../i486-slackware-linux/bin/ld: final link failed: Nonrepresentable section on output
collect2: ld returned 1 exit status
make[5]: *** [libxul.so] Error 1
.mozconfig:

ac_add_options --enable-application=calendar
ac_add_options --enable-chrome-format=jar
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/objdir-sb-release
mk_add_options MOZ_MAKE_FLAGS="-j8"
mk_add_options AUTOCONF=autoconf2.13
This also happens when building SeaMonkey (trunk) w/ Lightning.
I have no problems building Sunbird on win32. 

Linux builds look OK on <http://tinderbox.mozilla.org/showbuilds.cgi?tree=CalendarTrunk>. 
Maybe something special to your system or build chain?
(In reply to Stefan Sitter from comment #3)
> I have no problems building Sunbird on win32. 
> 
> Linux builds look OK on
> <http://tinderbox.mozilla.org/showbuilds.cgi?tree=CalendarTrunk>. 
> Maybe something special to your system or build chain?

I think I found the problem.  

When I add |ac_add_options --disable-optimization| to my .mozconfig,
both Sunbird and SeaMonkey w/Lightning builds properly.

But looking at CalendarTrunk, it's the builds are optimized.  
I'm wondering if I've hit some sort of memory limit here. I have
1GB ram for this linux box.
Resolving this to WFM as this is a machine issue.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
I am hitting exact same issue as reported by Edmund, with a separately built 4.3.3 based toolchain for ARM, in a crosscompiling setup using latest nightly (12 Mar 12). Will try with the --disable-optimization step and report.
Bug 736131 reports the same problem with Firefox and therefore this doesn't look like a Sunbird or Lightning problem.
To update from my side - I moved to gcc4.5, and no longer see this issue. Suspecting the size of libjs_static, that has grown to 137+ MB.
nm gfx/harfbuzz/src/hb-ot-layout.o | grep Sorted

GCC 4.3.2

0000000000000000 W _ZNK13SortedArrayOfI11RangeRecordE6searchIjEEiRKT_
                 U _ZNK13SortedArrayOfI6RecordI6ScriptEE6searchIjEEiRKT_
0000000000000000 W _ZNK13SortedArrayOfI6RecordI7LangSysEE6searchIjEEiRKT_
                 U _ZNK13SortedArrayOfI7IntTypeItEE6searchIjEEiRKT_
0000000000000000 W _ZZNK13SortedArrayOfI11RangeRecordE6searchIjEEiRKT_EN3Cmp3cmp

GCC 4.7.0

0000000000000000 W _ZNK13SortedArrayOfI6RecordI7LangSysEE6searchIjEEiRKT_
0000000000000000 W _ZNK13SortedArrayOfI7IntTypeItEE6searchIjEEiRKT_
0000000000000000 W _ZZNK13SortedArrayOfI11RangeRecordE6searchIjEEiRKT_EN3Cmp3cmpEPKjPKS0_
0000000000000000 W _ZZNK13SortedArrayOfI6RecordI6ScriptEE6searchIjEEiRKT_EN3Cmp3cmpEPKjPKS2_
0000000000000000 W _ZZNK13SortedArrayOfI6RecordI7LangSysEE6searchIjEEiRKT_EN3Cmp3cmpEPKjPKS2_
0000000000000000 W _ZZNK13SortedArrayOfI7IntTypeItEE6searchIjEEiRKT_EN3Cmp3cmpEPKjPKS1_

    
    

    
  


  

    
    

    
  


  

        Attachment #606524 -
        Attachment is obsolete: true

        Attachment #606527 -
        Attachment is obsolete: true
Assignee: nobody → kdevel
Component: Sunbird Only → Graphics
Product: Calendar → Core
QA Contact: sunbird → thebes
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Status: REOPENED → ASSIGNED

    
    

    
  
Comment on attachment 606528 [details] [diff] [review]
patch: instanciate templates explictly v2 (moved to .cc)

Hello Graphics Folks. Joe, could you delegate to an appropriate reviewer or review this yourself?

        Attachment #606528 -
        Flags: review?(joe)

    
    

    
  
Is this an actual code bug, or is it (as it looks at first glance) really a workaround for a toolchain or build environment bug? Should we be asking Behdad to take this upstream in harfbuzz? I'd prefer to avoid local patches that we then have to maintain indefinitely across future updates....

    
    

    
  
Comment on attachment 606528 [details] [diff] [review]
patch: instanciate templates explictly v2 (moved to .cc)

Review of attachment 606528 [details] [diff] [review]:
-----------------------------------------------------------------

Jonathan, feel free to delegate to Behdad.

        Attachment #606528 -
        Flags: review?(joe) → review?(jfkthame)

    
    

    
  
Comment on attachment 606528 [details] [diff] [review]
patch: instanciate templates explictly v2 (moved to .cc)

Behdad, this appears to be needed to work around build problems with some toolchains (see above). Do you see any problem with adding the explicit instantiations as in this patch?

Would you be willing to take this upstream? It presumably may help other users to build successfully, too, depending on their toolchain and environment.

        Attachment #606528 -
        Flags: review?(jfkthame) → review?(mozilla)

    
    

    
  
(In reply to Jonathan Kew (:jfkthame) from comment #17)
> Comment on attachment 606528 [details] [diff] [review]
> patch: instanciate templates explictly v2 (moved to .cc)
> 
> Behdad, this appears to be needed to work around build problems with some
> toolchains (see above). Do you see any problem with adding the explicit
> instantiations as in this patch?
> 
> Would you be willing to take this upstream? It presumably may help other
> users to build successfully, too, depending on their toolchain and
> environment.

Well, normally I wouldn't have anything against these kinds of things, however, only if it's testable so it doesn't get outdated.  For example, there's many many more template instantiations happening in HarfBuzz.  Why these three?  It's quite arbitrary.  Maybe there's something we are doing differently about these three that is causing it?  I don't know.  And I think we should try to understand that first.

The more I look at it the more arbitrary it looks.  I think this needs more investigation.

    
    

    
  
This bug has popped up for me in V13 release compile.

Trying ac_add_options --disable-optimization 

gcc is 4.3 from debian lenny stable 64 bit environment

Will report back when fresh compile succeeds or fails

    
    

    
  
No joy with config file changes,

 libxul.so: hidden symbol `int SortedArrayOf<Record<LangSys> >::search<unsigned int>(unsigned int const&) const' isn't defined

aborts the make

pending resolution I'll stay with version 12...

    
    

    
  
Jonathan, any hints as to how to repro this?

    
    

    
  
Not really; seems to be dependent on the compiler version, as well as (sometimes) optimization options. The obvious thing to try would be gcc 4.3 on Lenny 64bit, as per comment 19, but I don't have such a machine on hand, I'd have to set up something from scratch in order to try it.

    
    

    
  
I am happy to test compile any suggestions or try to help in any way...but this level of code hacking is a bit outside my pay grade. I don't even understand the error message.:-)

It is perhaps possible that I could open up telnet/ssh access to that machine from one fixed IP address...

Th issue seems to be somewhere deep within the graphics and fonts stuff.

    
    

    
  
You can test by trying to get harfbuzz itself to compile.  That's much easier.  Here's a tarball for you:

http://www.freedesktop.org/software/harfbuzz/snapshot/harfbuzz-20120607.tar.bz2

Try with various optimization levels (-O2 -O3 -Os).

    
    

    
  
Ok

that doesnt compile either

I did ./configure
make 
and got

hb-ft.cc:34:10: error: #include expects "FILENAME" or <FILENAME>
hb-ft.cc: In function ‘hb_position_t hb_ft_get_glyph_h_advance(hb_font_t*, void*, hb_codepoint_t, void*)’:
hb-ft.cc:102: error: ‘FT_Get_Advance’ was not declared in this scope
hb-ft.cc: In function ‘hb_position_t hb_ft_get_glyph_v_advance(hb_font_t*, void*, hb_codepoint_t, void*)’:
hb-ft.cc:118: error: ‘FT_Get_Advance’ was not declared in this scope

Hmm. 

FT_ADVANCES_H is nowhere defined it seems. 
 how do I try with optimisations?

    
    

    
  
Something broken with your FreeType installation.

    
    

    
  
dunno how. that constant is nowhere  defined in any harfbuzz files..

Neither does it seem to exist anywhere in /usr/include/freetype2/freetype/*.h

Its a perfectly standard freetype installation from the lenny repository.

Where is it SUPPOSED to be defined?

    
    

    
  
It was added in FreeType 2.3.8 (released in January 2009). I suspect Lenny only provides 2.3.7.

    
    

    
  
yeah. Ive been trawling through that header tree and it simply doesn't exist anywhere.

Shhesh..

    
    

    
  
In /usr/include/ft2build.h.  Donno.  Not going to worry on 4yr old systems for now.  Feel free to hack it out for testing.

    
    

    
  
spose there's no precompiled 64 bit firefox V13 is there?

Lenny may be 4 years old, but its 64 bit!

No dice Behdad - that include file merely loads the default tree config file which doesn't call for ftadvanc.h because it doesn't exist on my system!


I'll see if there's a better backport of the freetype available..but its getting messy.

Odd that I didn't get that error in the mozilla build tho.

    
    

    
  
Jonathan: yes. lenny freetype is 2.3.7.

    
    

    
  
(In reply to tnp from comment #31)
> Odd that I didn't get that error in the mozilla build tho.

Not odd; Gecko doesn't use the hb-ft stuff, it provides its own font callbacks.

    
    

    
  
Now I am truly confused. 

If the error is in the HB stuff and gecko doesn't use it?

Anyway got harfbuzz to compile by commenting out all  references to ‘FT_Get_Advance’ and the header file

so the only definite things so far is that hb will compile, but ought to have a better freetype than I have installed..so whats next?

    
    

    
  
Next is to try to reproduce the compile error.  Check the commandline gecko uses to compile harfbuzz, see what optimizations, etc it's using.

Jonathan, how old is HB in gecko these days?

    
    

    
  
Well I am getting reasonably confused.

I patched the harfbuzz source in the gecko tree to conform with what had compiled standalone and I get the same error. 

libxul.so: hidden symbol `int SortedArrayOf<Record<LangSys> >::search<unsigned int>(unsigned int const&) const' isn't defined

I'll try a make clean unless you have a better suggestion.

harfbuzz/gecko  looks pretty identical to what I downloaded..

    
    

    
  
(In reply to tnp from comment #34)
> Now I am truly confused. 
> 
> If the error is in the HB stuff and gecko doesn't use it?

Gecko uses harfbuzz, but it doesn't use the hb-ft interface to freetype fonts.

    
    

    
  
(In reply to Behdad Esfahbod from comment #35)
> Next is to try to reproduce the compile error.  Check the commandline gecko
> uses to compile harfbuzz, see what optimizations, etc it's using.
> 
> Jonathan, how old is HB in gecko these days?

In current mozilla-central, it's pretty recent (updated 2012-06-04 to commit a3547330fa88e30a138f6f17e60d9c7d1e316622, in bug 758236.)

But as tnp is trying to build the mozilla-13 release, that'll be significantly older... it was updated on 2012-02-14 to commit f51e167436a51b890ffe3f7f7920498fa287acd9 in bug 695857, which I think was the last update that's in v13. We have a few local patches on top of that commit, but I don't think any of them would affect this template-instantiation issue.

    
    

    
  
Make clean failed also.

Can anyone tell me how to build just the bits we think are problematic? because the whole  build takes 3 hours on this machine.. then I can redirect the output to a file and go over it in detail looking to see whats what.

    
    

    
  
Ok. I managed to ID how the make system sort of works and build just the harfbuzz section using the local Makefile and this is the actual output from the command that compiles it.

c++ -o hb-ot-layout.o -c -I../../../dist/stl_wrappers -I../../../dist/system_wrappers -include /home/leo/Downloads/firefox-src/mozilla-release/config/gcc_hidden.h -DMOZ_GLUE_IN_P
ROGRAM -DMOZILLA_INTERNAL_API -D_IMPL_NS_COM -DEXPORT_XPT_API -DEXPORT_XPTC_API -D_IMPL_NS_GFX -D_IMPL_NS_WIDGET -DIMPL_XREAPI -DIMPL_NS_NET -DIMPL_THEBES  -DSTATIC_EXPORTABLE_JS
_API -DOSTYPE=\"Linux2.6.32-bpo\" -DOSARCH=Linux -DPACKAGE_VERSION="\"moz\"" -DPACKAGE_BUGREPORT="\"http://bugzilla.mozilla.org/\"" -DHAVE_OT=1 -I/home/leo/Downloads/firefox-src/
mozilla-release/gfx/harfbuzz/src  -I/home/leo/Downloads/firefox-src/mozilla-release/gfx/harfbuzz/src -I. -I../../../dist/include -I../../../dist/include/nsprpub  -I/home/leo/Downloads/firefox-src/mozilla-release/obj-firefox/dist/include/nspr -I/home/leo/Downloads/firefox-src/mozilla-release/obj-firefox/dist/include/nss      -fPIC  -fno-rtti -pedantic -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctordtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof -Wno-variadic-macros -Werror=return-type -Wno-long
-long -fno-exceptions -fno-strict-aliasing -fshort-wchar -ffunction-sections -fdata-sections -pthread -pipe  -DNDEBUG -DTRIMMED -g -Os -freorder-blocks  -fomit-frame-pointer   -D
MOZILLA_CLIENT -include ../../../mozilla-config.h -MD -MF .deps/hb-ot-layout.pp -UDEBUG /home/leo/Downloads/firefox-src/mozilla-release/gfx/harfbuzz/src/hb-ot-layout.cc
hb-ot-map.cc


Errors or warnings are produced:

In file included from /home/leo/Downloads/firefox-src/mozilla-release/gfx/harfbuzz/src/hb-object-private.hh:37,
                 from /home/leo/Downloads/firefox-src/mozilla-release/gfx/harfbuzz/src/hb-buffer-private.hh:35,
                 from /home/leo/Downloads/firefox-src/mozilla-release/gfx/harfbuzz/src/hb-ot-map-private.hh:32,
                 from /home/leo/Downloads/firefox-src/mozilla-release/gfx/harfbuzz/src/hb-ot-shape-private.hh:34,
                 from /home/leo/Downloads/firefox-src/mozilla-release/gfx/harfbuzz/src/hb-ot-shape-normalize.cc:27:
/home/leo/Downloads/firefox-src/mozilla-release/gfx/harfbuzz/src/hb-mutex-private.hh:69:2: warning: #warning is a GCC extension
/home/leo/Downloads/firefox-src/mozilla-release/gfx/harfbuzz/src/hb-mutex-private.hh:69:2: warning: #warning "Could not find any system to define platform macros, library will NOT be thread-safe"

performing an nm on the  object file gives me this:

nm hb-ot-layout.o | grep Sorted
0000000000000000 W _ZNK13SortedArrayOfI11RangeRecordE6searchIjEEiRKT_
                 U _ZNK13SortedArrayOfI6RecordI6ScriptEE6searchIjEEiRKT_
                 U _ZNK13SortedArrayOfI6RecordI7LangSysEE6searchIjEEiRKT_
                 U _ZNK13SortedArrayOfI7IntTypeItEE6searchIjEEiRKT_
0000000000000000 W _ZZNK13SortedArrayOfI11RangeRecordE6searchIjEEiRKT_EN3Cmp3cmpEPKjPKS0_
0000000000000000 W _ZZNK13SortedArrayOfI6RecordI6ScriptEE6searchIjEEiRKT_EN3Cmp3cmpEPKjPKS2_
0000000000000000 W _ZZNK13SortedArrayOfI6RecordI7LangSysEE6searchIjEEiRKT_EN3Cmp3cmpEPKjPKS2_
0000000000000000 W _ZZNK13SortedArrayOfI7IntTypeItEE6searchIjEEiRKT_EN3Cmp3cmpEPKjPKS1_

This is about the limit of my pay grade: C++ is not a language I know very well. :-)

    
    

    
  
One final point: this is the same operation applied to the standalone library compiled object

 nm libharfbuzz_la-hb-ot-layout.o | grep Sorted
0000000000000000 W _ZNK13SortedArrayOfI11RangeRecordE6searchIjEEiRKT_
0000000000000000 W _ZZNK13SortedArrayOfI11RangeRecordE6searchIjEEiRKT_EN3Cmp3cmpEPKjPKS0_
0000000000000000 W _ZZNK13SortedArrayOfI6RecordI6ScriptEE6searchIjEEiRKT_EN3Cmp3cmpEPKjPKS2_
0000000000000000 W _ZZNK13SortedArrayOfI6RecordI7LangSysEE6searchIjEEiRKT_EN3Cmp3cmpEPKjPKS2_
0000000000000000 W _ZZNK13SortedArrayOfI7IntTypeItEE6searchIjEEiRKT_EN3Cmp3cmpEPKjPKS1_

So it looks like its an interaction between a particular set of sources and a particular set of compile options, and not compiler version dependent, necessarily.

Which raises the question of who is to fix it! :-)

    
  
Status: ASSIGNED → RESOLVED
Closed: 12 years ago → 12 years ago
Resolution: --- → DUPLICATE

    
    

    
  
Comment on attachment 606528 [details] [diff] [review]
patch: instanciate templates explictly v2 (moved to .cc)

Review of attachment 606528 [details] [diff] [review]:
-----------------------------------------------------------------

This is being tracked in the bug this is marked dupe of.

        Attachment #606528 -
        Flags: review?(mozilla) → review-

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: