unfortunately even when I apply the resolution to this bug "USE=bindist emerge freetype" there is still a ewarning saying bytecode has NOT been sucessfull. the problem lies in the freetype 2.1.9 ebuild flag -DTT_CONFIG_OPTION_BYTECODE_INTERPRETER which seems to have no effect. only by paching ftoption.h can bytecode be enabled Reproducible: Always Steps to Reproduce: 1.USE=bindist emerge freetype 2. 3. Actual Results: no bytecode freetype and ewarning saying bytecode has NOT been sucessfull. Expected Results: bytecode freetype and no ewarning
Created attachment 54769 [details, diff] ebuild fix
Um, are we picky today? ;)
the warning is correct. let me get this straight, you compile with USE=bindist & get the message that the bytecode interpreter is disabled ? And if you compile with USE=-bindist you get no such message ? btw, i must say while looking into this once again to be sure *bareuh* I had a hard time seeing the difference between the BI & AH.
both USE=" -bindist" and USE="bindist" give the same ftoption.h file. I am sure that with the bindist flag enabled TT_CONFIG_OPTION_BYTECODE_INTERPRETER should be uncommented. I know its really nitpickin, and is barely noticeable. Except with some apps (ie some emulation stuff). - bernie
You didn't answer my question.
No with USE=bindist I get the message that the bytecode interpreter is disabled. And if I compile with USE=-bindist I also get the message. in other words the bindist flag has no effect.
The file the r1 ebuild checks ftoption.h is the same with USE=bindist and USE=-bindist. So either ditch the bindist flag or as I patched - change the file it checks. Whatdo you think?
it works fine here, but i have some clue why it may not work correctly in some cases. What shell are you using ?
bash. wierd hey? Once the ebuild is completed the file /usr/include/freetype2/freetype/config/ftoption.h has the line 439 TT_CONFIG_OPTION_BYTECODE_INTERPRETER commented out. If I am not mistaken this should be uncommented when bindist is in the use flag right?
keep the attitude to yourself please. Don't get so hung up on your config patch, we do exactly the same thing in another way.
no probs. btw no attitude intended
i made some minor changes to the 2.1.9-r1 ebuild which will hopefully remedy your problem. Please sync and see (got to have cvs revision 1.17 at least in the ebuild header).
for 2.2.1 we now patch the config option in the header, b/c some apps rely on that.