On 13-04-09 07:40 AM, Steven R. Loomis wrote: > (meant to reply all) > > Richard, > GCC 3.4.3 is about 9 years old- http://gcc.gnu.org/gcc-3.4/ > Would it be possible to rebuild gcc, even in a user account? Binaries are > pretty easy to come by, also. Might be worthwhile. Could be endian problems?
Looks like Richard's problem was with pkg-config and as a result not detecting FreeType. > Does the travis build try anything big endian? I don't think so. They are pretty hard to come by these days! I'll take a look. behdad > > On Fri, Apr 5, 2013 at 12:09 PM, Richard Wordingham > <[email protected] <mailto:[email protected]>> > wrote: > > I had difficulty compiling HarfBuzz 0.9.14 on Solaris 10, and I would > like advice on whether it is worth developing official, robust fixes. > You might advise me that the system is obsolete and not worth > supporting. > > Environment: > > O/S: SunOS 5.10 Generic_118833-18 > HW: sun4u SUNW,A70 > Compiler: gcc Version 3.4.3 > > Unfortunately, upgrading this system's software is not an option. > > Compilation problems: > > 1) libstdc++.la is an empty file! It is therefore not recognised as a > valid library, and compilation halts. > > My work-around is to manually remove "-lstdc++" from the generated > script libtool. > > 2) The compiler does not recognise the option > -fvisibility-inlines-hidden. > > My work-around is to manually remove it from the script configure. > > 3) The compiler considers the that overload resolution between the > following templates in hb-open-type-private.hh is not possible: > > /* Cast to struct T, pointer to pointer */ > template<typename Type, typename TObject> > inline const Type* CastP(const TObject *X) > { return reinterpret_cast<const Type*> (X); } > template<typename Type, typename TObject> > inline Type* CastP(TObject *X) > { return reinterpret_cast<Type*> (X); } > > My workaround is to rename the former CastCP and change CastP to CastCP > until the compiler stops complaining. I had to make the same change > for other pairs. > > Run-time problems: > > The program in test.cc core suffers an assertion failure because buffer > directionality is invalid. I believe this is the intended response to > the behaviour in test.cc. When I correct the file by calling > hb_buffer_guess_segment_properties() before hb_shape(), I get > intelligible glyph indices on Linux. However, on Solaris the glyph > indices are returned as 0, even for such simple strings as "abcde". > I suspect misaligned data in the font file. If this is the problem, > would the problem be fixed, or is it now considered now worth > supporting systems that don't handle this automatically? > > Richard. > _______________________________________________ > HarfBuzz mailing list > [email protected] <mailto:[email protected]> > http://lists.freedesktop.org/mailman/listinfo/harfbuzz > > > > > _______________________________________________ > HarfBuzz mailing list > [email protected] > http://lists.freedesktop.org/mailman/listinfo/harfbuzz > -- behdad http://behdad.org/ _______________________________________________ HarfBuzz mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/harfbuzz
