I was able to build fontconfig 2.9.0 using mingw without any trouble. I saw
that 2.10.0 was released so I tried that. configure seems to complete without
any problem. When I run make, it seems to want to do config all over again.
make output starts like this:
CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh
/d/gtki2/fontconfig-2.10.0/missing --run aclocal-1.11
cd . && /bin/sh /d/gtki2/fontconfig-2.10.0/missing --run automake-1.11
--gnu
CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh
/d/gtki2/fontconfig-2.10.0/missing --run autoconf
/bin/sh ./config.status --recheck
running CONFIG_SHELL=/bin/sh /bin/sh ./configure --prefix=/c/gtk3
--enable-shared --disable-static CFLAGS=-g LDFLAGS=-L/c/gtk3/l
ib -L/mingw/lib CPPFLAGS=-I/c/gtk3/include -I/mingw/include
PKG_CONFIG=/c/gtk3/bin/pkg-config.exe PKG_CONFIG_PATH=/c/MinGW/lib/p
kgconfig:/c/gtk3/lib/pkgconfig --no-create --no-recursion
On this second round of configure, it gives this error
./configure: line 11925: PKG_PROG_PKG_CONFIG: command not found
and then finally fails with:
./configure: line 13010: syntax error near unexpected token `FREETYPE,''
./configure: line 13010: `PKG_CHECK_MODULES(FREETYPE, freetype2)''
I notice that version 2.9.0 also does the repeat configure on running make just
as does version 2.10.0 but unlike 2.10.0, configure completes and make also
completes. Now I do have pkg-config 0.27, ACLOCAL_FLAGS is defined and pkg.m4
is
in that directory. Just for fun I also tried starting with
autoreconf --force --install --verbose
but the end result is the same; configure dies.
ACLOCAL_FLAGS=-I /c/gtk3/share/aclocal
PKG_CONFIG_SYSTEM_LIBRARY_PATH=/c/mingw/lib
PKG_CONFIG_SYSTEM_INCLUDE_PATH=/c/mingw/include
PKG_CONFIG_PATH=/c/gtk3/lib/pkgconfig:/c/MinGW/lib/pkgconfig
PKG_CONFIG=/c/mingw/bin/pkg-config.exe
make[3]: Entering directory `/d/gtki2/fontconfig-2.10.0/fc-case''
CC fc-case.o
CCLD fc-case.exe
libtool: Version mismatch error. This is libtool 2.4.2, but the
libtool: definition of this LT_INIT comes from libtool 2.4.
libtool: You should recreate aclocal.m4 with macros from libtool 2.4.2
libtool: and run autoconf again.
I tried without ACLOCAL_FLAGS and just configure (no autoreconf)
I tried without ACLOCAL_FLAGS and autoreconf then configure.
The result is the same; make results in repeat of configure.
I took a closer look at the output of autoreconf and noticed these
libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])'' to configure.ac
and
and
libtoolize: Consider adding `-I m4'' to ACLOCAL_AMFLAGS in Makefile.am.
I looked at how those were done in other packages and addeded
new directory m4
configure.ac
AC_CONFIG_MACRO_DIR([m4])
makefile.am
ACLOCAL_AMFLAGS = -I m4 ${ACLOCAL_FLAGS}
Now autoreconf completes without warning or suggestions.
I was able to do configure, make and make install. Make does not result in a
repeat configure. So I guess I solved my own problem (maybe?) but now I am
curious why?
Should these things be added to the project?
Damon Register
On Saturday 21 July 2012 12:17:29 Damon Register wrote:> I was able to build fontconfig 2.9.0 using mingw without any trouble. I > saw that 2.10.0 was released so I tried that. configure seems to complete > without any problem. When I run make, it seems to want to do config all > over again. make output starts like this: > > CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh > /d/gtki2/fontconfig-2.10.0/missing --run aclocal-1.11your timestamps are messed up -- autotools should not be automatically regenerated. any errors after this point are irrelevant. the best way to find out which timestamps are messed up: rm -rf fontconfig-2.10.0 tar xf fontconfig-2.10.0.tar.bz2 cd fontconfig-2.10.0 ./configure <your random flags> make -d >& log then look at the log file to see why it thinks it needs to regenerate the autotools. could be your clock is messed up, or you have an old kernel or broken filesystem, or something else. -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: <http://lists.freedesktop.org/archives/fontconfig/attachments/20120721/d4ccea30/attachment.pgp>
On 7/21/2012 12:41 PM, Mike Frysinger wrote:> On Saturday 21 July 2012 12:17:29 Damon Register wrote: >> I was able to build fontconfig 2.9.0 using mingw without any trouble. I >> saw that 2.10.0 was released so I tried that. configure seems to complete >> without any problem. When I run make, it seems to want to do config all >> over again. make output starts like this: >> >> CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh >> /d/gtki2/fontconfig-2.10.0/missing --run aclocal-1.11 > > your timestamps are messed up -- autotools should not be automatically > regenerated. any errors after this point are irrelevant.Well this is embarrassing. As soon as you mentioned timestamps, I think I know what the problem is. I rebuilt tar (because I wanted a newer version). I did tar xvf fontconfig-2.10.0.tar and did a directory compare between the newly unpacked fontconfig and a previous one (as a test to see if the new tar mangled any of the files). All files were a binary match but the timestamps were different. I will toss the new tar, wipe my gtk3 build folder and start over. since I have a slow computer, maybe tomorrow I will let you know how it turned out. Thanks for your help. Damon Register
On 7/21/2012 12:41 PM, Mike Frysinger wrote:> your timestamps are messed up -- autotools should not be automatically > regenerated. any errors after this point are irrelevant.You were right. I wiped everything and started over. I got to the fontconfig and it now configures without trouble. Thanks. Now that I am past that point, I am running into a new problem. make completes but make install dies with a lot of messages like this: cd /c/gtk3/etc/fonts/conf.d rm -f 20-unhint-small-vera.conf; ln -s /c/gtk3/share/fontconfig/conf.avail/20-unhint-small-vera.conf . ln: creating symbolic link `./20-unhint-small-vera.conf'' to `/c/gtk3/share/fontconfig/conf.avail/20-unhint-small-vera.conf'': No such file or directory Something doesn''t make sense here. /c/gtk3 is the prefix were all the built projects get installed. I would expect that the source of these conf files would be the source where I am building which happens to be /d/gtki2/fontconfig-2.10.0. If I search there, I find all those conf files like the one in the above error message. It appears this operation is coming from ./conf.d/Makefile target install-data-local: I know it is a hack but I tried changing templatedir to abs_srcdir under that target. The make install completes without error. Of course I have to wonder if everything is really ok or not. Can anyone please tell me if I am on the right track with this? Damon Register
On Mon, Jul 23, 2012 at 10:50 AM, Damon Register <dregister at clear.net> wrote:> cd /c/gtk3/etc/fonts/conf.d > rm -f 20-unhint-small-vera.conf; ln -s > /c/gtk3/share/fontconfig/conf.avail/20-unhint-small-vera.conf . > ln: creating symbolic link `./20-unhint-small-vera.conf'' to > `/c/gtk3/share/fontconfig/conf.avail/20-unhint-small-vera.conf'': No > such file or directoryHmm, what the version of ln command is it? that looks like it prevents to install something with DESTDIR say. for the real install, we could use install-data-hook instead of install-data-local though, it doesn''t help when using DESTDIR with that broken ln command.> It appears this operation is coming from ./conf.d/Makefile target > install-data-local: > I know it is a hack but I tried changing templatedir to abs_srcdir under > that target. The make install completes without error.It''s wrong. installed symlinks shouldn''t be referred to the source directory. as I mentioned above, you can use install-data-hook instead of install-data-local in your case. but you better use sane ln command if any. -- Akira TAGOH
On 7/22/2012 10:47 PM, Akira TAGOH wrote:> Hmm, what the version of ln command is it? that looks like it preventsIt is version 5.97.> to install something with DESTDIR say. for the real install, we could > use install-data-hook instead of install-data-local though, it doesn''t > help when using DESTDIR with that broken ln command.I don''t follow. How is it broken? Even though the ln might be broken, I can look at the code in ./conf.d/Makefile and source directory used (ln -s source dest) just doesn''t make sense (to me anyway).>> I know it is a hack but I tried changing templatedir to abs_srcdir under >> that target. The make install completes without error. > > It''s wrong. installed symlinks shouldn''t be referred to the source > directory. as I mentioned above, you can use install-data-hook instead > of install-data-local in your case. but you better use sane ln command > if any.I am not sure what is required for "sane". Here is the setup. The destination to where I install the various packages that I am building is /c/gtk3. The source where I have unpacked the tar is /d/gtki2/fontconfig-2.10.0. source: /d/gtki2/fontconfig-2.10.0 dest: /c/gtk3 The make install target in question (install-data-local:) is trying to ln -s from to where from is a directory under /c/gtk3 (the destination) There are a few things that just don''t make sense. 1. the "from" is a non-existent folder in the destination install location 2. why should choosing a non-existent "from" be blamed on the ln command. That is operator error, is it not? 3. These files in question do exist in the source build folder. Is this not a logical place for them to be? 4. Shouldn''t the general goal be to get those files from the source to the destination through some method whether it be cp, ln or mv? 5. if "installed symlinks shouldn''t be referred to the source", then to where should they be referred? Should there perhaps have been a cp preceding the ln so that the files are copied and then linked? I do see that the make process is different in this area when compared to fontconfig-2.9.0. when I build that one, there isn''t any problem. Damon Register
On Mon, Jul 23, 2012 at 9:36 PM, Damon Register <damon.w.register at lmco.com> wrote:> On 7/22/2012 10:47 PM, Akira TAGOH wrote: >> >> Hmm, what the version of ln command is it? that looks like it prevents > > It is version 5.97. > > >> to install something with DESTDIR say. for the real install, we could >> use install-data-hook instead of install-data-local though, it doesn''t >> help when using DESTDIR with that broken ln command. > > I don''t follow. How is it broken? Even though the ln might be broken, > I can look at the code in ./conf.d/Makefile and source directory used > (ln -s source dest) just doesn''t make sense (to me anyway).I don''t see any error on Linux say... ln is capable to create a broken symlink (at that point) but it could be valid later. Anyway, on git master, installing config files happens earlier than creating symlinks now. it should works for you. try it.> The make install target in question (install-data-local:) is trying to > ln -s from to > where from is a directory under /c/gtk3 (the destination)Yes. it''s intentional, because those symlinks are referring from the installed config files. otherwise all of users has to install the source code too.> > There are a few things that just don''t make sense. > 1. the "from" is a non-existent folder in the destination install location > 2. why should choosing a non-existent "from" be blamed on the ln command. > That is operator error, is it not? > 3. These files in question do exist in the source build folder. Is this > not a logical place for them to be? > 4. Shouldn''t the general goal be to get those files from the source to > the destination through some method whether it be cp, ln or mv? > 5. if "installed symlinks shouldn''t be referred to the source", then to > where should they be referred? Should there perhaps have been a cp > preceding the ln so that the files are copied and then linked? > > I do see that the make process is different in this area when compared to > fontconfig-2.9.0. when I build that one, there isn''t any problem.Well, difference between 2.9 and 2.10 is whether the source place of ln is the relative path or the absolute path. no changes in the installation order. so any config files shouldn''t be there at that time. but your ln didn''t just complain that for the relative path I guess.> > > Damon Register > > _______________________________________________ > Fontconfig mailing list > Fontconfig at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/fontconfig-- Akira TAGOH
On 7/23/2012 1:32 PM, Akira TAGOH wrote:> I don''t see any error on Linux say... ln is capable to create a broken > symlink (at that point) but it could be valid later.Oh. I was not aware of that. Assuming then that the files in question get put there later, then it would work, right? I think I might know then why this doesn''t work with mingw on Windows. As far as I know, when using mingw/msys on windows, the ln can''t create symbolic links since that is something Windows doesn''t understand. I believe that it just does a copy instead which would mean that this anticipation type link won''t work because you can''t copy a file that doesn''t exist, right?> Anyway, on git master, installing config files happens earlier than > creating symlinks now. it should works for you. try it.fascinating. I will try it.> Yes. it''s intentional, because those symlinks are referring from the > installed config files. otherwise all of users has to install the > source code too.Ok, I think I understand all this. So, the question that remains is this: how can the code be fixed so that those files exist before making a symlink such that it won''t break on Windows?> Well, difference between 2.9 and 2.10 is whether the source place of > ln is the relative path or the absolute path. no changes in thebut regardless of relative or absolute, if the source doesn''t exist, then a copy would break, right?> installation order. so any config files shouldn''t be there at that > time. but your ln didn''t just complain that for the relative path I > guess.I don''t totally understand the differences between 2.9.0 and 2.10.0 but I do know that 2.9.0 installed without this problem. I know I could be wrong but it seems to me that the order must have been different if this worked on windows. Damon Register
On Tue, Jul 24, 2012 at 8:03 AM, Damon Register <dregister at clear.net> wrote:> Ok, I think I understand all this. So, the question that remains is this: > how can the code be fixed so that those files exist before making a > symlink such that it won''t break on Windows?I did it in git. the quote from automake info: Automake also supports two install hooks, `install-exec-hook'' and `install-data-hook''. These hooks are run after all other install rules of the appropriate type, exec or data, have completed. So now the block of creating symlinks are being invoked after all of the installation finished.> I don''t totally understand the differences between 2.9.0 and 2.10.0 > but I do know that 2.9.0 installed without this problem. I know I could > be wrong but it seems to me that the order must have been different if > this worked on windows.Hmm, rechecked the generated Makefile again. indeed, the dependencies is different between 2.9 and 2.10. but it was generated by automake due to the implicit rules maybe. I don''t see why. but it may be because the source place to create a symlink is managed under automake in 2.10 but was just hardcoding in 2.9. Using install-data-hook looks promising because it ensure the behavior. -- Akira TAGOH