From Newsgroup: comp.lang.tcl

I built and installed Tcl and Tk 8.6.13 from source. And it works.

Except the fonts. The fonts look awful. Maybe they don't have antialias,
maybe it's something else, I'm not sure. I just know they look awful.
Really awful.

I also have 8.6.6 from my distro's repository and a compact/portable
version of 8.6.13 in FreeWrap, and their fonts look fine. Only my
compiled Tk looks bad.

Then I tried 8.6.14 and had the exact same problem.

Do you people have any idea why? What do you suggest I do to pinpoint
the cause of the problem?

In case you're wondering, I configured it like this:

$ ./configure --disable-symbols --enable-shared --enable-threads --enable-64bit --prefix /opt/tcltk8614 --with-tcl=/home/luc/newtcl/tcl8.6.14/unix
--
Luc

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.tcl

Luc <luc@sep.invalid> wrote:

I built and installed Tcl and Tk 8.6.13 from source. And it works.

Except the fonts. The fonts look awful. Maybe they don't have antialias, maybe it's something else, I'm not sure. I just know they look awful.
Really awful.

I also have 8.6.6 from my distro's repository and a compact/portable
version of 8.6.13 in FreeWrap, and their fonts look fine. Only my
compiled Tk looks bad.

Then I tried 8.6.14 and had the exact same problem.

Do you people have any idea why?

Run an ldd on the wish which has "good fonts" and on the one that has
"bad fonts". Compare what is linked. I bet you find the "bad fonts"
wish does not link to libfreetype.

What do you suggest I do to pinpoint the cause of the problem?

The above.

In case you're wondering, I configured it like this:

$ ./configure --disable-symbols --enable-shared --enable-threads --enable-64bit --prefix /opt/tcltk8614 --with-tcl=/home/luc/newtcl/tcl8.6.14/unix

Check ./configure --help.

See if there is an "enable truetype" or "enable freetype" option.

If yes, rebuild while specifying that option. If you get errors, then
make sure you have the freetype "development" package installed (too
many debian/ubuntu derived distros separate everything into "use" an "development" packages, and then omit installing the "development"
packages (which made /some/ sense years ago when a 4G hard drive was considered large). But now, the result is things like 'true type'
support won't be auto-detected by configure unless the development
packages for it are first installed, leading to oddness like what you
just experienced -- the distro package works fine, your custom built
one has weirdness.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.tcl

On Sat, 22 Jun 2024 01:34:44 -0000 (UTC), Rich wrote:

Check ./configure --help.

The only relevant thing I can find is

--enable-xft use freetype/fontconfig/xft (default: on)

But default is on. I recompiled with --enable-xft and the problem
persists.

Run an ldd on the wish which has "good fonts" and on the one that has
"bad fonts". Compare what is linked. I bet you find the "bad fonts"
wish does not link to libfreetype.

They have a lot in common. These are the lines that the "good" has and
the "bad" or "ugly" doesn't:

libXft.so.2 => /usr/lib/x86_64-linux-gnu/libXft.so.2
libfontconfig.so.1 => /usr/lib/x86_64-linux-gnu/libfontconfig.so.1 libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6
libXss.so.1 => /usr/lib/x86_64-linux-gnu/libXss.so.1
libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6
libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1
libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1
libpng16.so.16 => /usr/lib/x86_64-linux-gnu/libpng16.so.16

and

libXft-dev => I installed it
libfontconfig-dev => I installed it
libfreetype-dev => already had it
libXss-dev => I installed it
libXext-dev => I installed it
libXrender-dev => I installed it
libexpat-dev => already had it
libpng16-dev => already had it

I recompiled. And the problem persists. And ldd tells me that the libraries linked in the good one are still absent in my own build.

Now I have no idea what else I need to install to make fonts look good.
--
Luc

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.tcl

Luc <luc@sep.invalid> wrote:

On Sat, 22 Jun 2024 01:34:44 -0000 (UTC), Rich wrote:

Run an ldd on the wish which has "good fonts" and on the one that has
"bad fonts". Compare what is linked. I bet you find the "bad fonts"
wish does not link to libfreetype.

They have a lot in common. These are the lines that the "good" has
and the "bad" or "ugly" doesn't:

libXft.so.2 => /usr/lib/x86_64-linux-gnu/libXft.so.2
libfontconfig.so.1 => /usr/lib/x86_64-linux-gnu/libfontconfig.so.1 libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6
libXss.so.1 => /usr/lib/x86_64-linux-gnu/libXss.so.1
libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6
libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1
libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1
libpng16.so.16 => /usr/lib/x86_64-linux-gnu/libpng16.so.16

and

libXft-dev => I installed it
libfontconfig-dev => I installed it
libfreetype-dev => already had it
libXss-dev => I installed it
libXext-dev => I installed it
libXrender-dev => I installed it
libexpat-dev => already had it
libpng16-dev => already had it

I recompiled. And the problem persists. And ldd tells me that the libraries linked in the good one are still absent in my own build.

Now I have no idea what else I need to install to make fonts look
good.

Well, obviously there's still some missing critical library "dev pack". Unfortunately for you, I use a distro that does not do the stupid split
of "user" vs. "dev" for every package and instead just installs
everything needed for development with each package (Slackware) and so
I can't comment on what additional development package you may need to install. You might try googling for your distro and "how to compile a
program that needs freetype on (distro)" and see if anything recommends another dev pack that is still missing.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.tcl

Luc <luc@sep.invalid> wrote:

On Sat, 22 Jun 2024 01:34:44 -0000 (UTC), Rich wrote:

Check ./configure --help.

The only relevant thing I can find is

--enable-xft use freetype/fontconfig/xft (default: on)

But default is on. I recompiled with --enable-xft and the problem
persists.

Run an ldd on the wish which has "good fonts" and on the one that has
"bad fonts". Compare what is linked. I bet you find the "bad fonts"
wish does not link to libfreetype.

They have a lot in common. These are the lines that the "good" has and
the "bad" or "ugly" doesn't:

libXft.so.2 => /usr/lib/x86_64-linux-gnu/libXft.so.2
libfontconfig.so.1 => /usr/lib/x86_64-linux-gnu/libfontconfig.so.1 libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6
libXss.so.1 => /usr/lib/x86_64-linux-gnu/libXss.so.1
libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6
libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1
libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1
libpng16.so.16 => /usr/lib/x86_64-linux-gnu/libpng16.so.16

and

libXft-dev => I installed it
libfontconfig-dev => I installed it
libfreetype-dev => already had it
libXss-dev => I installed it
libXext-dev => I installed it
libXrender-dev => I installed it
libexpat-dev => already had it
libpng16-dev => already had it

I recompiled. And the problem persists. And ldd tells me that the libraries linked in the good one are still absent in my own build.

Now I have no idea what else I need to install to make fonts look good.

A few things you could check:

What does the configure output look like? Was it still unable to
find the missing libraries?

Just making sure: have you started the recompile in a clean source
tree? Safest way is to delete and unpack it again.

What do these "-dev"-packages contain? Shared objects? Header files?
Where are these installed in relation to the system development
files?
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.tcl

Am 22.06.24 um 02:11 schrieb Luc:

I built and installed Tcl and Tk 8.6.13 from source. And it works.

Except the fonts. The fonts look awful. Maybe they don't have antialias, maybe it's something else, I'm not sure. I just know they look awful.
Really awful.

I also have 8.6.6 from my distro's repository and a compact/portable
version of 8.6.13 in FreeWrap, and their fonts look fine. Only my
compiled Tk looks bad.

Then I tried 8.6.14 and had the exact same problem.

Do you people have any idea why? What do you suggest I do to pinpoint
the cause of the problem?

In case you're wondering, I configured it like this:

$ ./configure --disable-symbols --enable-shared --enable-threads --enable-64bit --prefix /opt/tcltk8614 --with-tcl=/home/luc/newtcl/tcl8.6.14/unix

Hello,
I don't know which distro you are using.
For example, with Debian I look at the tk-dev package to see what
dependencies exist.

apt-cache depends tk-dev
or
apt show tk-dev
then continue with
apt-cache depends tk8.6-dev

or with red hat
dnf repoquery --requires tcl-devel

Gregor
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.tcl

Luc <luc@sep.invalid> writes:

What do you suggest I do to pinpoint the cause of the problem?

I suggest you dig up the configure options your distro uses.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.tcl

At Sat, 22 Jun 2024 01:34:44 -0000 (UTC) Rich <rich@example.invalid> wrote:

Luc <luc@sep.invalid> wrote:

I built and installed Tcl and Tk 8.6.13 from source. And it works.

Except the fonts. The fonts look awful. Maybe they don't have antialias, maybe it's something else, I'm not sure. I just know they look awful. Really awful.

I also have 8.6.6 from my distro's repository and a compact/portable version of 8.6.13 in FreeWrap, and their fonts look fine. Only my
compiled Tk looks bad.

Then I tried 8.6.14 and had the exact same problem.

Do you people have any idea why?

Run an ldd on the wish which has "good fonts" and on the one that has
"bad fonts". Compare what is linked. I bet you find the "bad fonts"
wish does not link to libfreetype.

What do you suggest I do to pinpoint the cause of the problem?

The above.

In case you're wondering, I configured it like this:

$ ./configure --disable-symbols --enable-shared --enable-threads --enable-64bit --prefix /opt/tcltk8614 --with-tcl=/home/luc/newtcl/tcl8.6.14/unix

Check ./configure --help.

See if there is an "enable truetype" or "enable freetype" option.

If yes, rebuild while specifying that option. If you get errors, then
make sure you have the freetype "development" package installed (too
many debian/ubuntu derived distros separate everything into "use" an "development" packages, and then omit installing the "development"
packages (which made /some/ sense years ago when a 4G hard drive was considered large). But now, the result is things like 'true type'
support won't be auto-detected by configure unless the development
packages for it are first installed, leading to oddness like what you
just experienced -- the distro package works fine, your custom built
one has weirdness.

It is pretty "standard" for both Debian and RedHat based distros to split off the "development" library packages. Under Debian for most lib<mumble> package there is a corresponding lib<mumble>-dev package and under RedHat for some <mumble> packages there is a <mumble>-devel package. I helieve the idea is
the difference between a "user" experience and a "developer" experience and keeping things lean for servers and desktop users, by not cluttering things up with the header and linker files (and whatever else is needed for building applications).
Debian further complicates things but not necessarily exactly matching the lib<mumble> with the lib<mumble>-dev, which can be something of a bitch to get the -dev package you need installed. Things like lib<mumble>-dev goes with lib<mymble>N, where N is the major version number.


--
Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364
Deepwoods Software -- Custom Software Services
http://www.deepsoft.com/ -- Linux Administration Services
heller@deepsoft.com -- Webhosting Services
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.tcl

At Sat, 22 Jun 2024 12:05:01 +0200 Joerg Mertens <joerg-mertens@t-online.de> wrote:

Luc <luc@sep.invalid> wrote:

On Sat, 22 Jun 2024 01:34:44 -0000 (UTC), Rich wrote:

Check ./configure --help.

The only relevant thing I can find is

--enable-xft use freetype/fontconfig/xft (default: on)

But default is on. I recompiled with --enable-xft and the problem
persists.

Run an ldd on the wish which has "good fonts" and on the one that has >>"bad fonts". Compare what is linked. I bet you find the "bad fonts" >>wish does not link to libfreetype.

They have a lot in common. These are the lines that the "good" has and
the "bad" or "ugly" doesn't:

libXft.so.2 => /usr/lib/x86_64-linux-gnu/libXft.so.2
libfontconfig.so.1 => /usr/lib/x86_64-linux-gnu/libfontconfig.so.1 libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6
libXss.so.1 => /usr/lib/x86_64-linux-gnu/libXss.so.1
libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6
libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1
libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1
libpng16.so.16 => /usr/lib/x86_64-linux-gnu/libpng16.so.16

and

libXft-dev => I installed it
libfontconfig-dev => I installed it
libfreetype-dev => already had it
libXss-dev => I installed it
libXext-dev => I installed it
libXrender-dev => I installed it
libexpat-dev => already had it
libpng16-dev => already had it

I recompiled. And the problem persists. And ldd tells me that the libraries linked in the good one are still absent in my own build.

Now I have no idea what else I need to install to make fonts look good.

A few things you could check:

What does the configure output look like? Was it still unable to
find the missing libraries?

Just making sure: have you started the recompile in a clean source
tree? Safest way is to delete and unpack it again.

+1 +1!

What do these "-dev"-packages contain? Shared objects? Header files?
Where are these installed in relation to the system development
files?

The -dev packages contain header files, link libraries, and config files (PKG_CONFIG or something like that).


--
Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364
Deepwoods Software -- Custom Software Services
http://www.deepsoft.com/ -- Linux Administration Services
heller@deepsoft.com -- Webhosting Services
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.tcl

Look in the repo files for tk<mumble>.debian.tar.gz. In the tar archive will be the build commands (including the ./configure ... command used). Also in the tk<mumble>.debian.tar.gz will be a file containing the build deps, which you can check to see if you are still missing something.
At Sat, 22 Jun 2024 16:47:12 +0300 Anssi Saari <anssi.saari@usenet.mail.kapsi.fi> wrote:

Luc <luc@sep.invalid> writes:

What do you suggest I do to pinpoint the cause of the problem?

I suggest you dig up the configure options your distro uses.

--
Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364
Deepwoods Software -- Custom Software Services
http://www.deepsoft.com/ -- Linux Administration Services
heller@deepsoft.com -- Webhosting Services
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.tcl

On Sat, 22 Jun 2024 12:05:01 +0200, Joerg Mertens wrote:

Just making sure: have you started the recompile in a clean source
tree? Safest way is to delete and unpack it again.

I always delete and unpack again.

What does the configure output look like? Was it still unable to
find the missing libraries?

It looks bad. It says "xft is unusable." I don't understand that at all.
I don't know C. I don't understand compiling.


checking for Tcl configuration... found /home/luc/newtcl/tcl8.6.14/unix/tclConfig.sh
checking for existence of /home/luc/newtcl/tcl8.6.14/unix/tclConfig.sh... loading
checking for tclsh... /usr/bin/tclsh8.6
checking for tclsh in Tcl build directory... /home/luc/newtcl/tcl8.6.14/unix/tclsh
checking whether to use symlinks for manpages... no
checking whether to compress the manpages... no
checking whether to add a package name suffix for the manpages... no
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking for inline... inline
checking how to run the C preprocessor... gcc -E
checking for egrep... grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for stdlib.h... (cached) yes
checking if the compiler understands -pipe... yes
checking for pthread_mutex_init in -lpthread... yes
checking for pthread_attr_setstacksize... yes
checking for pthread_atfork... yes
checking for building with threads... yes (threaded core)
checking how to build libraries... shared
checking for ranlib... ranlib
checking if 64bit support is requested... yes
checking if 64bit Sparc VIS support is requested... no
checking if compiler supports visibility "hidden"... yes
checking if rpath support is requested... yes
checking system version... Linux-4.9.0-3-amd64
checking for dlopen in -ldl... yes
checking for ar... ar
checking if compiler accepts -m64 flag... yes
checking for cast to union support... yes
checking for working -fno-lto... yes
checking for build with symbols... no
checking for required early compiler flags... none
checking for 64-bit integer type... using long
checking whether byte ordering is bigendian... no
checking for fd_set in sys/types... yes
checking sys/time.h usability... yes
checking sys/time.h presence... yes
checking for sys/time.h... yes
checking whether time.h and sys/time.h may both be included... yes
checking for mode_t... yes
checking for pid_t... yes
checking for size_t... yes
checking for uid_t in sys/types.h... yes
checking for intptr_t... yes
checking for uintptr_t... yes
checking pw_gecos in struct pwd... yes
checking for X... libraries , headers
checking for main in -lXbsd... no
checking whether to use xft... no
configure: WARNING: Can't find xft configuration, or xft is unusable
checking for X11/XKBlib.h... no
checking whether XKeycodeToKeysym is deprecated... yes
checking whether to try to use XScreenSaver... yes
checking for X11/extensions/scrnsaver.h... no
checking for XScreenSaverQueryInfo... no
checking for XScreenSaverQueryInfo in -lXext... no
checking for XScreenSaverQueryInfo in -lXss... no
checking whether char is unsigned... no
configure: creating ./config.status
config.status: creating Makefile
config.status: creating tkConfig.sh
config.status: creating tk.pc
--
Luc

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.tcl

Joerg Mertens <joerg-mertens@t-online.de> wrote:

What do these "-dev"-packages contain? Shared objects? Header files?
Where are these installed in relation to the system development
files?

For distro's that do this splitting, the "-dev" packs usually contain
the header files, any *.a files (if static linking is an option), and
any other misc. "development" (i.e., needed to compile, vs. simply run
and link to the shared object) files.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.tcl

Luc <luc@sep.invalid> wrote:

On Sat, 22 Jun 2024 12:05:01 +0200, Joerg Mertens wrote:

What does the configure output look like? Was it still unable to
find the missing libraries?

It looks bad. It says "xft is unusable." I don't understand that at all.

That is why it is not linking to xft, which implies there are still one
or more *-dev packs missing.

I don't know C. I don't understand compiling.

Look at Robert Heller's post under this message id:

<z5acnQ0TVobmduv7nZ2dnZfqn_udnZ2d@giganews.com>

Then do what he suggests there. That may show which *-dev pack is
still missing, but is required.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.tcl

At Sat, 22 Jun 2024 16:49:13 -0000 (UTC) Rich <rich@example.invalid> wrote:

Luc <luc@sep.invalid> wrote:

On Sat, 22 Jun 2024 12:05:01 +0200, Joerg Mertens wrote:

What does the configure output look like? Was it still unable to
find the missing libraries?

It looks bad. It says "xft is unusable." I don't understand that at all.

That is why it is not linking to xft, which implies there are still one
or more *-dev packs missing.

I don't know C. I don't understand compiling.

Look at Robert Heller's post under this message id:

<z5acnQ0TVobmduv7nZ2dnZfqn_udnZ2d@giganews.com>

Then do what he suggests there. That may show which *-dev pack is
still missing, but is required.

I just grabed the Tk8.6 debian file for Debian Bookworm (what I am running on my Raspberry Pi 5) and the revlevant info is:
from the control file:
Build-Depends: debhelper-compat (= 13), dpkg-dev (>= 1.16.1~), x11proto-core-dev,
libx11-dev, libxss-dev, libxext-dev, libxft-dev,
tcl8.6-dev (>= 8.6.8+dfsg-3~)
So Luc needs:
sudo apt install x11proto-core-dev libx11-dev libxss-dev libxext-dev libxft-dev
(probably only libxft-dev is actually needed)
He does not need debhelper-compat and dpkg-dev, since he is not building a
deb file and does not need tcl8.6-dev, since he is building his own version
of tcl8.6 in a parallel directory and is alreaday accounting for that as explained in the Tk source tree's README.
Then in rules:
override_dh_auto_configure:
TK_LIBRARY="/usr/share/tcltk/tk$(v)" \
CC="$(CC)" \
CFLAGS="$(CFLAGS)" \
CPPFLAGS="$(CPPFLAGS)" \
TK_SHLIB_LD_EXTRAS="-Wl,-soname,\$${TK_LIB_FILE}" \
dh_auto_configure -Dunix -- \
--includedir=/usr/include/tcl$(v) \
--with-tcl=/usr/lib/$(DEB_HOST_MULTIARCH)/tcl$(v) \
--enable-shared \
This tells him what extra args to pass to configure (probably nothing he is
not already doing). It looks like all he needs to do is install libxft-dev
and he should be good to go.
I suspect that all downstream Debian based distros (Ubuntu, etc.) don't re-package Tcl/Tk, beyond just using the base Debian build files.


--
Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364
Deepwoods Software -- Custom Software Services
http://www.deepsoft.com/ -- Linux Administration Services
heller@deepsoft.com -- Webhosting Services
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.tcl

Luc <luc@sep.invalid> wrote:
[...]

checking whether to use xft... no
configure: WARNING: Can't find xft configuration, or xft is unusable
checking for X11/XKBlib.h... no
checking whether XKeycodeToKeysym is deprecated... yes

[...]

I don't know if this will help but if you want to dive deeper into
the details here is some more information.

configure executes two commands to find out if it can use xft and
fontconfig:

$ pkg-config --cflags xft fontconfig

and

$ pkg-config --libs xft fontconfig

At least one of them fails or else configure wouldn't print the
warning. You can run the commands interactiveliy to see which files
it doesn't find.

The normal output is something like

-I/usr/X11R6/include -I/usr/X11R6/include/freetype2

and

-L/usr/X11R6/lib -lXft -lfontconfig -lfreetype

respectively.

Now pkg-config gets its information from the *.pc files which are
installed with most (or at least some) libraries. If for example
you have installed all the necessary xft packages, there will be a
file named xft.pc somewhere. This is the "xft configuration"
configure says it cannot find.

One thing you could do is ask your package database where the *.pc
files should be and check if they really exist. If they do exist,
pkg-config has a problem finding them, which can probably be solved
by setting the PKG_CONFIG_PATH environment variable to expand the
search path.

HTH
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.tcl

Robert Heller <heller@deepsoft.com> wrote:
[...]

This tells him what extra args to pass to configure (probably nothing he is not already doing). It looks like all he needs to do is install libxft-dev and he should be good to go.

Interestingly, Google found an article in comp.lang.tcl from 2007
with the same `configure´ warning message [1]. This was on an
Ubuntu system but I guess the package system is the same. The
solution was indeed to install the libxft-dev package.

[1] https://groups.google.com/g/comp.lang.tcl/c/Cr0aaF8sIUs
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.tcl

At Sun, 23 Jun 2024 12:34:37 +0200 Joerg Mertens <joerg-mertens@t-online.de> wrote:

Robert Heller <heller@deepsoft.com> wrote:
[...]

This tells him what extra args to pass to configure (probably nothing he is not already doing). It looks like all he needs to do is install libxft-dev and he should be good to go.

Interestingly, Google found an article in comp.lang.tcl from 2007
with the same `configure´ warning message [1]. This was on an
Ubuntu system but I guess the package system is the same. The
solution was indeed to install the libxft-dev package.

Ubuntu is a Debian derived distro. Much of the Ubuntu repo is just rebuilds
of packages in the Debian distro.

[1] https://groups.google.com/g/comp.lang.tcl/c/Cr0aaF8sIUs

--
Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364
Deepwoods Software -- Custom Software Services
http://www.deepsoft.com/ -- Linux Administration Services
heller@deepsoft.com -- Webhosting Services
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.tcl

On Sun, 23 Jun 2024 12:16:29 +0200, Joerg Mertens wrote:

I don't know if this will help but if you want to dive deeper into
the details here is some more information.

configure executes two commands to find out if it can use xft and
fontconfig:

$ pkg-config --cflags xft fontconfig

and

$ pkg-config --libs xft fontconfig

At least one of them fails or else configure wouldn't print the
warning. You can run the commands interactiveliy to see which files
it doesn't find.

**************************

Yes, it helps although it won't solve my problem.

# > pkg-config --libs xft fontconfig
-lXft -lfontconfig -lfreetype
# > pkg-config --cflags xft fontconfig
Package 'x11' requires 'xcb >= 1.11.1' but version of xcb is 1.8.4


I give up. The entire system does a formidable job of excluding
people with older systems. The whole spaghetti entanglement of
dependencies puts in place a large number of checkpoints that
make sure violators will be caught even if they cheat. I am caught
again. I give up again.

Thank you.
--
Luc

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.tcl

Luc <luc@sep.invalid> wrote:

On Sun, 23 Jun 2024 12:16:29 +0200, Joerg Mertens wrote:

I don't know if this will help but if you want to dive deeper into
the details here is some more information.

configure executes two commands to find out if it can use xft and >>fontconfig:

$ pkg-config --cflags xft fontconfig

and

$ pkg-config --libs xft fontconfig

At least one of them fails or else configure wouldn't print the
warning. You can run the commands interactiveliy to see which files
it doesn't find.

**************************

Yes, it helps although it won't solve my problem.

# > pkg-config --libs xft fontconfig
-lXft -lfontconfig -lfreetype
# > pkg-config --cflags xft fontconfig
Package 'x11' requires 'xcb >= 1.11.1' but version of xcb is 1.8.4

Well, there's the cause, you need to upgrade to a newer xcb.

I give up. The entire system does a formidable job of excluding
people with older systems. The whole spaghetti entanglement of
dependencies puts in place a large number of checkpoints that
make sure violators will be caught even if they cheat. I am caught
again. I give up again.

Unfortunately if you want to stay with a "too old" system you do have
to accept that some things will move forward to the point that they
won't compile anymore. That's not the fault of the "system", that's a conscious choice you made to stay behind.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.tcl

Luc <luc@sep.invalid> wrote:

# > pkg-config --libs xft fontconfig
-lXft -lfontconfig -lfreetype
# > pkg-config --cflags xft fontconfig
Package 'x11' requires 'xcb >= 1.11.1' but version of xcb is 1.8.4

But 'x11' is already installed and running on your system, so how
can it have a wrong dependency? Is the output the same for
`pkg-config --cflags x11´? If yes, there is definitely something
wrong with your packages.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.tcl

Hi Robert, Luc,

Robert Heller writes:

I just grabed the Tk8.6 debian file for Debian Bookworm (what I am
running on my Raspberry Pi 5) and the revlevant info is:

from the control file:
Build-Depends: debhelper-compat (= 13), dpkg-dev (>= 1.16.1~), x11proto-core-dev,
libx11-dev, libxss-dev, libxext-dev, libxft-dev,
tcl8.6-dev (>= 8.6.8+dfsg-3~)


So Luc needs:

sudo apt install x11proto-core-dev libx11-dev libxss-dev libxext-dev libxft-dev

(probably only libxft-dev is actually needed)

Note, there is also "apt-get build-dep emacs". This just installs all
the development packages that the Debian package needed. It will
probably install more than strictly needed, but it is easier to use.

benny

--- Synchronet 3.20a-Linux NewsLink 1.114