Re: [ft-devel] problems with `kushal-work' branch
> Also, I've tried installing FreeType library on another Ubuntu 17.04 > 64-bit. > > I did > > ./autogen > ./configure --prefix= > make > make install > > AFAICS it installed the 32-bit version. ( no lib64/ folder, there > was an lib/ folder). See my previous e-mail. I don't use Ubuntu, so I can't tell you whether stuff gets automatically put into `lib/x86_64-linux-gnu', or whether you have to provide a `--libdir' option to the configure script... However, this isn't something for worrying. Just use $(libdir)... Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] problems with `kushal-work' branch
> $ uname -a > Linux ubuntu 4.4.0-87-generic #110-Ubuntu SMP Tue Jul 18 12:55:35 UTC 2017 > x86_64 x86_64 x86_64 GNU/Linux Aah, Ubuntu no longer have `/usr/lib64'; it's called `/usr/lib/x86_64-linux-gnu' instead, cf. https://askubuntu.com/questions/611419/ubuntu-12-04-5-64bit-no-usr-lib64 One more reason to not assume a default directory for library files :-) If you are going to use FreeType's build system, just rely on $(libdir). Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] problems with `kushal-work' branch
Got it. Thanks. Also, I've tried installing FreeType library on another Ubuntu 17.04 64-bit. I did ./autogen ./configure --prefix= make make install AFAICS it installed the 32-bit version. ( no lib64/ folder, there was an lib/ folder). On Tue, Aug 8, 2017 at 12:15 PM, Werner LEMBERG wrote: > > >> . As a prerequisite (documented in the README) the user must > >> compile the `base' version of FreeType manually so that a DLL > >> gets created. This should *not* be handled automatically. And > >> no need to install them. > >> . Similarly, the `test' version of FreeType should be built with a > >> simple call to `make'. Again there should be no need to install > >> it. > >> . The user should then specify the `base' FreeType `.so' file using > >> a variable, say, `FREETYPE_BASE_DLL'. > > > > After compiling both the libraries, I am doing this in objs/ folder. > > > > libtool --mode=install cp libfreetype.la \ > > /home/ksvsk/working-repo/tests/make_png/test/libfreetype.la > > > > And using the .so file generated in the test/ folder. Similarly > > doing this for the 'base' version as well. I am getting the correct > > result. Is this what is needed to be done? > > Well, calling `libtool' this way is kind of an installation, which is > exactly what should *not* be expected. There shouldn't be any > assumptions where the base DLL is located. > > Maybe I wasn't clear enough, so I'm trying again. > > . Compile the base FreeType version in directory > `/home/kushal/freetype2-base'. After compilation, the .so file > can be found as > `/home/kushal/freetype2-base/objs/.libs/libfreetype.so.6.12.5'. > > . Compile the test FreeType version (i.e., current git) in directory > `/home/kushal/freetype2'. After compilation, the .so file can be > found as > `/home/kushal/freetype2/objs/.libs/libfreetype.so.6.14.0'. > > . The glyph image tests should now > be run with something similar to the following > > cd /home/kushal/freetype2 > > FREETYPE_TEST_BASE_DLL="/home/kushal/freetype2-base/objs/.libs/libfreetype.so.6.12.5" > \ > FREETYPE_TEST_FONT="/home/kushal/foo.ttf" \ > FREETYPE_TEST_PT_SIZES="12 15 18" \ > FREETYPE_TEST_MODES="aa mono" \ > make tests > > Of course, there is no need to explicitly specify the second DLL > because `make tests' can find it by itself. > > > Werner > ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] problems with `kushal-work' branch
>> . As a prerequisite (documented in the README) the user must >> compile the `base' version of FreeType manually so that a DLL >> gets created. This should *not* be handled automatically. And >> no need to install them. >> . Similarly, the `test' version of FreeType should be built with a >> simple call to `make'. Again there should be no need to install >> it. >> . The user should then specify the `base' FreeType `.so' file using >> a variable, say, `FREETYPE_BASE_DLL'. > > After compiling both the libraries, I am doing this in objs/ folder. > > libtool --mode=install cp libfreetype.la \ > /home/ksvsk/working-repo/tests/make_png/test/libfreetype.la > > And using the .so file generated in the test/ folder. Similarly > doing this for the 'base' version as well. I am getting the correct > result. Is this what is needed to be done? Well, calling `libtool' this way is kind of an installation, which is exactly what should *not* be expected. There shouldn't be any assumptions where the base DLL is located. Maybe I wasn't clear enough, so I'm trying again. . Compile the base FreeType version in directory `/home/kushal/freetype2-base'. After compilation, the .so file can be found as `/home/kushal/freetype2-base/objs/.libs/libfreetype.so.6.12.5'. . Compile the test FreeType version (i.e., current git) in directory `/home/kushal/freetype2'. After compilation, the .so file can be found as `/home/kushal/freetype2/objs/.libs/libfreetype.so.6.14.0'. . The glyph image tests should now be run with something similar to the following cd /home/kushal/freetype2 FREETYPE_TEST_BASE_DLL="/home/kushal/freetype2-base/objs/.libs/libfreetype.so.6.12.5" \ FREETYPE_TEST_FONT="/home/kushal/foo.ttf" \ FREETYPE_TEST_PT_SIZES="12 15 18" \ FREETYPE_TEST_MODES="aa mono" \ make tests Of course, there is no need to explicitly specify the second DLL because `make tests' can find it by itself. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] problems with `kushal-work' branch
> > What GNU/Linux distribution are you using? Most distros come with a > 32bit and 64bit version; however, the former is going extinct almost > everywhere today. I am using a 64-bit Ubuntu in a Virtual Machine on a Mac. > Be inventive :-) I suggest that you use names not too different from > the strings used in `ftview.c', for example. Ok. On Tue, Aug 8, 2017 at 11:44 AM, Werner LEMBERG wrote: > > > How to build the FreeType library in 64-bit? > > If you are on a 64bit platform (i.e., using a computer that isn't much > older than five years or so), this should be done automatically. > Otherwise, you have to install a cross compiler. > > > I've applied the above patch but there is no lib64/ directory. > > What GNU/Linux distribution are you using? Most distros come with a > 32bit and 64bit version; however, the former is going extinct almost > everywhere today. > > >> Rendering modes should be names, not numbers – please adjust your > >> `sprite' program accordingly. > > > > What should be the names for the LCD rendering modes ? > > Be inventive :-) I suggest that you use names not too different from > the strings used in `ftview.c', for example. > > > Werner > > > PS: Any results regarding the comparison of my log file with your > setup? I would *really* like to see generated images... > ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] problems with `kushal-work' branch
$ uname -a Linux ubuntu 4.4.0-87-generic #110-Ubuntu SMP Tue Jul 18 12:55:35 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux On Tue, Aug 8, 2017 at 11:54 AM, Kushal K S V S wrote: > What GNU/Linux distribution are you using? Most distros come with a >> 32bit and 64bit version; however, the former is going extinct almost >> everywhere today. > > I am using a 64-bit Ubuntu in a Virtual Machine on a Mac. > >> Be inventive :-) I suggest that you use names not too different from >> the strings used in `ftview.c', for example. > > Ok. > > On Tue, Aug 8, 2017 at 11:44 AM, Werner LEMBERG wrote: > >> >> > How to build the FreeType library in 64-bit? >> >> If you are on a 64bit platform (i.e., using a computer that isn't much >> older than five years or so), this should be done automatically. >> Otherwise, you have to install a cross compiler. >> >> > I've applied the above patch but there is no lib64/ directory. >> >> What GNU/Linux distribution are you using? Most distros come with a >> 32bit and 64bit version; however, the former is going extinct almost >> everywhere today. >> >> >> Rendering modes should be names, not numbers – please adjust your >> >> `sprite' program accordingly. >> > >> > What should be the names for the LCD rendering modes ? >> >> Be inventive :-) I suggest that you use names not too different from >> the strings used in `ftview.c', for example. >> >> >> Werner >> >> >> PS: Any results regarding the comparison of my log file with your >> setup? I would *really* like to see generated images... >> > > ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] problems with `kushal-work' branch
> How to build the FreeType library in 64-bit? If you are on a 64bit platform (i.e., using a computer that isn't much older than five years or so), this should be done automatically. Otherwise, you have to install a cross compiler. > I've applied the above patch but there is no lib64/ directory. What GNU/Linux distribution are you using? Most distros come with a 32bit and 64bit version; however, the former is going extinct almost everywhere today. >> Rendering modes should be names, not numbers – please adjust your >> `sprite' program accordingly. > > What should be the names for the LCD rendering modes ? Be inventive :-) I suggest that you use names not too different from the strings used in `ftview.c', for example. Werner PS: Any results regarding the comparison of my log file with your setup? I would *really* like to see generated images... ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] problems with `kushal-work' branch
> > . As a prerequisite (documented in the README) the user must compile > the `base' version of FreeType manually so that a DLL gets > created. This should *not* be handled automatically. And no need > to install them. > . Similarly, the `test' version of FreeType should be built with a > simple call to `make'. Again there should be no need to install > it. > . The user should then specify the `base' FreeType `.so' file using > a variable, say, `FREETYPE_BASE_DLL'. After compiling both the libraries, I am doing this in objs/ folder. libtool --mode=install cp libfreetype.la /home/ksvsk/working-repo/tests/make_png/test/libfreetype.la And using the .so file generated in the test/ folder. Similarly doing this for the 'base' version as well. I am getting the correct result. Is this what is needed to be done ? On Tue, Aug 8, 2017 at 11:02 AM, Kushal K S V S wrote: > How to build the FreeType library in 64-bit ? > I've applied the above patch but there is no lib64/ directory. > >> Another issue: I think `base' and `test' must be reversed, at least in >> `runme.sh': `base' is the old, previous version and `test' the current >> one... > > Yeah, the actual usage is like this. > For now as the older version has errors,So I put this (old version) as > test. > >> Rendering modes should be names, not numbers – please adjust your >> `sprite' program accordingly. > > What should be the names for the LCD rendering modes ? > > On Sun, Aug 6, 2017 at 2:26 AM, Werner LEMBERG wrote: > >> >> >> To summarize: `sprite' compiles file, it generates an HTML file but >> >> no images (yet). >> > >> > I've used the same version (2.6.5) and also the same arguments. >> > For me it loaded 95 images in the ./images folder. >> >> Tried again from scratch, to no avail. Strange. Attached is my log >> file. I've simply unpacked `freetype-2.6.5.tar.gz' in `/home/wl', >> checked out the `kushal-work' branch in >> `/home/wl/git/freetype/freetype2.kushal', applied the patch from my >> previous e-mail, changed into the `test/make_png' directory and called >> >> sh runme.sh /home/wl/freetype-2.6.5 test.ttf 20 1 &> log >> >> Attached is the log file. >> >> I'm quite sure if `sprite' would be more verbose, the problem could be >> identified more rapidly... >> >> >> Werner >> > > ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] problems with `kushal-work' branch
How to build the FreeType library in 64-bit ? I've applied the above patch but there is no lib64/ directory. > Another issue: I think `base' and `test' must be reversed, at least in > `runme.sh': `base' is the old, previous version and `test' the current > one... Yeah, the actual usage is like this. For now as the older version has errors,So I put this (old version) as test. > Rendering modes should be names, not numbers – please adjust your > `sprite' program accordingly. What should be the names for the LCD rendering modes ? On Sun, Aug 6, 2017 at 2:26 AM, Werner LEMBERG wrote: > > >> To summarize: `sprite' compiles file, it generates an HTML file but > >> no images (yet). > > > > I've used the same version (2.6.5) and also the same arguments. > > For me it loaded 95 images in the ./images folder. > > Tried again from scratch, to no avail. Strange. Attached is my log > file. I've simply unpacked `freetype-2.6.5.tar.gz' in `/home/wl', > checked out the `kushal-work' branch in > `/home/wl/git/freetype/freetype2.kushal', applied the patch from my > previous e-mail, changed into the `test/make_png' directory and called > > sh runme.sh /home/wl/freetype-2.6.5 test.ttf 20 1 &> log > > Attached is the log file. > > I'm quite sure if `sprite' would be more verbose, the problem could be > identified more rapidly... > > > Werner > ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] problems with `kushal-work' branch
>> To summarize: `sprite' compiles file, it generates an HTML file but >> no images (yet). > > I've used the same version (2.6.5) and also the same arguments. > For me it loaded 95 images in the ./images folder. Tried again from scratch, to no avail. Strange. Attached is my log file. I've simply unpacked `freetype-2.6.5.tar.gz' in `/home/wl', checked out the `kushal-work' branch in `/home/wl/git/freetype/freetype2.kushal', applied the patch from my previous e-mail, changed into the `test/make_png' directory and called sh runme.sh /home/wl/freetype-2.6.5 test.ttf 20 1 &> log Attached is the log file. I'm quite sure if `sprite' would be more verbose, the problem could be identified more rapidly... Werner log.xz Description: Binary data ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] problems with `kushal-work' branch
> Attached you can find a quick patch that I used to make it work (more > or less). Oops, here's the patch. Another issue: I think `base' and `test' must be reversed, at least in `runme.sh': `base' is the old, previous version and `test' the current one... And I forgot to mention that later on FreeType's `builds/unix/configure.ac' script must be extended with checks for `-ldl'. For `-lpng', etc. there are already tests available. Werner diff --git a/tests/make_png/Makefile b/tests/make_png/Makefile index b742dbff7..b82b6aeb3 100644 --- a/tests/make_png/Makefile +++ b/tests/make_png/Makefile @@ -1,22 +1,30 @@ # Define required macros here -SHELL = /bin/sh +all: sprite + +# Load the upper level configuration makefile snippet to get the lib +# directory and other configuration stuff. +# +# Note that `unix-def.mk' is generated by the `configure' script; to make +# the code below work it is expected that you called `make install' in the +# upper level. +TOP_DIR := ../.. +BUILD_DIR := $(TOP_DIR)/builds/unix +include $(TOP_DIR)/builds/unix/unix-def.mk SRC_SPRITE = make_sprite.c bitmap.c murmur3.c -SRC_LIB = ./base/lib/libfreetype.a +SRC_LIB = $(libdir)/libfreetype.a OBJS = $(src:.c=.o) CFLAGS = -Wall -g CC = gcc -INCLUDE = -I ./base/include/freetype2/ +INCLUDE = -I$(includedir)/freetype2 LIBS = -lpng -lharfbuzz -lbz2 -ldl DPI = 72 -all: sprite - -sprite:$(SRC_SPRITE) +sprite: $(SRC_SPRITE) $(CC) $(CFLAGS) $(INCLUDE) -DDPI=$(DPI) -o $@ $(SRC_SPRITE) $(SRC_LIB) $(OBJS) $(LIBS) .PHONY: clean diff --git a/tests/make_png/runme.sh b/tests/make_png/runme.sh index 9761ad7a2..41f4ca116 100644 --- a/tests/make_png/runme.sh +++ b/tests/make_png/runme.sh @@ -4,27 +4,38 @@ BASE_DIR=$PWD cd $TEST_DIR/include/freetype/config/ sed -i 's/\/\* #define FT_CONFIG_OPTION_SUBPIXEL_RENDERING \*\//#define FT_CONFIG_OPTION_SUBPIXEL_RENDERING /g' ftoption.h +echo +echo +echo "*** building test FreeType in $TEST_DIR *** " cd $TEST_DIR ./autogen.sh -./configure --prefix=$BASE_DIR/test/ +./configure --prefix=$BASE_DIR/test/ --disable-static make make install +echo +echo +echo "*** building base FreeType in $BASE_DIR *** " cd $BASE_DIR/../.. ./autogen.sh ./configure --prefix=$BASE_DIR/base/ make make install +echo +echo +echo "*** building \`sprite' test program *** " cd $BASE_DIR make -BASE_LIB=./base/lib/libfreetype.so -TEST_LIB=./test/lib/libfreetype.so +BASE_LIB=./base/lib64/libfreetype.so +TEST_LIB=./test/lib64/libfreetype.so FONT_FILE=$2 PT_SIZE=$3 RENDER_MODE=$4 +echo +echo +echo "*** executing ./sprite $BASE_LIB $TEST_LIB $FONT_FILE $PT_SIZE $RENDER_MODE ***" ./sprite $BASE_LIB $TEST_LIB $FONT_FILE $PT_SIZE $RENDER_MODE - ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] problems with `kushal-work' branch
> > . What values have you used for executing `runme.sh'? I tried > sh runme.sh /home/wl/freetype-2.6.5 test.ttf 20 1 > and I only got > Empty Glyph in glyph-index 1 > Empty Glyph in glyph-index 2 > Empty Glyph in glyph-index 3 > without a single image. Maybe I did something wrong? > To summarize: `sprite' compiles file, it generates an HTML file but no > images (yet). I've used the same version (2.6.5) and also the same arguments. For me it loaded 95 images in the ./images folder. On Sun, Aug 6, 2017 at 12:43 AM, Werner LEMBERG wrote: > > Kushal, > > > there are a bunch of problems with your branch due to 32bit vs. 64bit > libraries. The main issue is that in recent GNU/Linux distributions > it is common that 64bit libraries are installed in `lib64', not `lib'. > Your current setup covers `lib' only. > > Attached you can find a quick patch that I used to make it work (more > or less). As you can see, I loaded a top-level snippet to get access > to the installation directories. Note, however, that this is an > ad-hoc hack that you should not commit. > > What you *really* should do is to actually use the already existing > FreeType infrastructure! It is now time that you add a `tests' target > (or proper `test-xxx' subtargets – whatever you need) to a new file > `builds/tests.mk', which must be properly included in `toplevel.mk'. > > . As a prerequisite (documented in the README) the user must compile > the `base' version of FreeType manually so that a DLL gets > created. This should *not* be handled automatically. And no need > to install them. > > . Similarly, the `test' version of FreeType should be built with a > simple call to `make'. Again there should be no need to install > it. > > . The user should then specify the `base' FreeType `.so' file using > a variable, say, `FREETYPE_BASE_DLL'. > > . Similarly, I suggest to use variables for the other test > parameters. Example: > > FREETYPE_BASE_DLL="/home/wl/base/libfreetype.so.6.12.5" \ > PT_SIZE="15 16 17 18 19 20 22 25 30" \ > DPI="72 96" \ > RENDER_MODE="mono aa" \ > make tests > > . Alternatively, a makefile snippet, say, `tests.mk', might be > loaded that contains the above variables. > > Some more issues that I've noticed. > > . `sprite' should be more verbose; it should report which files are > created where. > > . I think that the HTML files created by `sprite' should be put into > a separate directory, say, `make_png/html'. Maybe you are going > to create more HTML subfiles later on (e.g., one file per font)... > > . Rendering modes should be names, not numbers – please adjust your > `sprite' program accordingly. [I know that the FreeType demo > programs are a bad example for this :-)] > > . Please add *a lot* of comments to the C source code files so that > it is easy to understand its features. > > . What values have you used for executing `runme.sh'? I tried > > sh runme.sh /home/wl/freetype-2.6.5 test.ttf 20 1 > > and I only got > > Empty Glyph in glyph-index 1 > Empty Glyph in glyph-index 2 > Empty Glyph in glyph-index 3 > > without a single image. Maybe I did something wrong? > > To summarize: `sprite' compiles file, it generates an HTML file but no > images (yet). > > > Werner > ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
