From Newsgroup: comp.lang.tcl

I replied to the announcement of this release back in February to say
that I couldn't build it, but I seem to have given up after a couple of
very useful suggestions from the author.

After seeing the announcement of Tcl 9.0.2 earlier this week, I am
trying again...

I'm running Linux Mint, 64-bit. I have built Tcl 9.0.2 in /opt/tcl9.0.2
and it seems to be working fine, so it's just(?!) a question of
rebuilding the external and homebrew packages that the half-dozen
scripts I use regularly rely on.

I've downloaded tcltls-2.0b1.tar.gz (to Downloads) and untarred it (to Downloads/tcltls-2.0b1)

Using my preferred workflow, I'm sitting in my home directory (the
parent of Downloads) and have typed

(cd Downloads/tcltls-2.0b1; ./configure --enable-64bit
--prefix=/opt/tcl9.0.2 --with-tcl=/opt/tcl9.0.1/lib --with-openssl-includedir=/usr/include)

followed by

(cd Downloads/tcltls-2.0b1; make)

This fails quickly with a compilation error:

./generic/tlsBIO.c: In function ‘BioOutput’:
./generic/tlsBIO.c:117:32: error: ‘BIO_FLAGS_IN_EOF’ undeclared (first
use in this function); did you mean ‘BIO_FLAGS_READ’?
117 | BIO_set_flags(bio, BIO_FLAGS_IN_EOF);
| ^~~~~~~~~~~~~~~~

The compilation command was

gcc -DPACKAGE_NAME=\"tls\" -DPACKAGE_TARNAME=\"tls\" -DPACKAGE_VERSION=\"2.0b1\" -DPACKAGE_STRING=\"tls\ 2.0b1\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DBUILD_tls=/\*\*/ -DHAVE_STDIO_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_STRINGS_H=1 -DHAVE_SYS_STAT_H=1
-DHAVE_SYS_TYPES_H=1 -DHAVE_UNISTD_H=1 -DSTDC_HEADERS=1
-DUSE_THREAD_ALLOC=1 -D_REENTRANT=1 -D_THREAD_SAFE=1 -DTCL_THREADS=1 -DUSE_TCL_STUBS=1 -DUSE_TCLOO_STUBS=1 -DMODULE_SCOPE=extern\ __attribute__\(\(__visibility__\(\"hidden\"\)\)\) -DHAVE_HIDDEN=1 -DHAVE_CAST_TO_UNION=1 -DHAVE_STDBOOL_H=1 -DTCL_WIDE_INT_IS_LONG=1 -DTCL_CFG_OPTIMIZED=1 -DUSE_TCL_STUBS=1 -DNO_SSL3=1 -D_FORTIFY_SOURCE=2 -fstack-protector-all -fno-strict-overflow -I/usr/include -Wno-deprecated-declarations -I/usr/include -I"/opt/tcl9.0.2/include"
-I. -O2 -fomit-frame-pointer -DNDEBUG -Wall -fPIC -pipe -m64 -O2 -fomit-frame-pointer -DNDEBUG -Wall -fPIC -c `echo ./generic/tlsBIO.c`
-o tlsBIO.o

Now, line 30 of Downloads/tcltls-2.0b1/generic/tlsBIO.c is

#include <openssl/bio.h>

and line 209 of /usr/include/openssl/bio.h is

# define BIO_FLAGS_IN_EOF 0x800

What's going on?

Following the advice in February, I believe I am now putting the right
value on the --with-openssl-includedir flag to configure (I no longer
include /openssl). I'm suspicious that make includes

-I/usr/include

twice in the compile command but I don't think it's causing a problem.

Help!

Alan
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Usually this means it found an older version of OpenSSL. Check which
version of OpenSSL you have on your system. You need 1.1.1 or later. On
the command line:

openssl --version


Also you mixed 9.0.1 and 9.0.2. in your paths. When you run the
configure script, check the configure output to see what it found. A
blank means it will use the default path. The key is that it says it
found the ssl.h file. For example:

...
checking for Tcl configuration... found /opt/tcl9/lib64/tcl/tclConfig.sh
...
checking for Tcl public headers... /opt/tcl9/include
...
checking for OpenSSL directory... /usr
checking for OpenSSL include directory... /usr/include
checking for ssl.h... yes
checking for OpenSSL lib directory... /usr/lib64
checking for OpenSSL pkgconfig...
checking for tclsh... /opt/tcl9/bin/tclsh9.0


If the OpenSSL is installed in /usr, then the command line args aren't
needed. You also don't need them if you have pkgconfig on your system configured. However if you want to be sure to use the right version,
here's what I use on OpenSuSe:

./configure --enable-64bit --prefix=/opt/tcl9 --exec-prefix=/opt/tcl9 --libdir=/opt/tcl9/lib64/tcl --with-openssl-dir=/usr --with-openssl-includedir=/usr/include --with-openssl-libdir=/usr/lib64




On 7/4/25 5:40 PM, Alan Grunwald wrote:

I replied to the announcement of this release back in February to say
that I couldn't build it, but I seem to have given up after a couple of
very useful suggestions from the author.

After seeing the announcement of Tcl 9.0.2 earlier this week, I am
trying again...

I'm running Linux Mint, 64-bit. I have built Tcl 9.0.2 in /opt/tcl9.0.2
and it seems to be working fine, so it's just(?!) a question of
rebuilding the external and homebrew packages that the half-dozen
scripts I use regularly rely on.

I've downloaded tcltls-2.0b1.tar.gz (to Downloads) and untarred it (to Downloads/tcltls-2.0b1)

Using my preferred workflow, I'm sitting in my home directory (the
parent of Downloads) and have typed

(cd Downloads/tcltls-2.0b1; ./configure --enable-64bit --prefix=/opt/ tcl9.0.2 --with-tcl=/opt/tcl9.0.1/lib --with-openssl-includedir=/usr/ include)

followed by

(cd Downloads/tcltls-2.0b1; make)

This fails quickly with a compilation error:

./generic/tlsBIO.c: In function ‘BioOutput’:
./generic/tlsBIO.c:117:32: error: ‘BIO_FLAGS_IN_EOF’ undeclared (first use in this function); did you mean ‘BIO_FLAGS_READ’?
  117 |             BIO_set_flags(bio, BIO_FLAGS_IN_EOF);
      |                                ^~~~~~~~~~~~~~~~

The compilation command was

gcc -DPACKAGE_NAME=\"tls\" -DPACKAGE_TARNAME=\"tls\" - DPACKAGE_VERSION=\"2.0b1\" -DPACKAGE_STRING=\"tls\ 2.0b1\" - DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DBUILD_tls=/\*\*/ - DHAVE_STDIO_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_STRINGS_H=1 -DHAVE_SYS_STAT_H=1 - DHAVE_SYS_TYPES_H=1 -DHAVE_UNISTD_H=1 -DSTDC_HEADERS=1 -
DUSE_THREAD_ALLOC=1 -D_REENTRANT=1 -D_THREAD_SAFE=1 -DTCL_THREADS=1 - DUSE_TCL_STUBS=1 -DUSE_TCLOO_STUBS=1 -DMODULE_SCOPE=extern\ __attribute__\(\(__visibility__\(\"hidden\"\)\)\) -DHAVE_HIDDEN=1 - DHAVE_CAST_TO_UNION=1 -DHAVE_STDBOOL_H=1 -DTCL_WIDE_INT_IS_LONG=1 - DTCL_CFG_OPTIMIZED=1 -DUSE_TCL_STUBS=1 -DNO_SSL3=1 -D_FORTIFY_SOURCE=2 - fstack-protector-all -fno-strict-overflow -I/usr/include -Wno- deprecated-declarations -I/usr/include -I"/opt/tcl9.0.2/include" -I.
-O2 -fomit-frame-pointer -DNDEBUG -Wall -fPIC -pipe -m64 -O2 -fomit- frame-pointer -DNDEBUG -Wall -fPIC  -c `echo ./generic/tlsBIO.c` -o tlsBIO.o

Now, line 30 of Downloads/tcltls-2.0b1/generic/tlsBIO.c is

#include <openssl/bio.h>

and line 209 of /usr/include/openssl/bio.h is

# define BIO_FLAGS_IN_EOF        0x800

What's going on?

Following the advice in February, I believe I am now putting the right
value on the --with-openssl-includedir flag to configure (I no longer include /openssl). I'm suspicious that make includes

-I/usr/include

twice in the compile command but I don't think it's causing a problem.

Help!

Alan

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 06/07/2025 02:09, Brian wrote:

Usually this means it found an older version of OpenSSL. Check which
version of OpenSSL you have on your system. You need 1.1.1 or later. On
the command line:

openssl --version

Also you mixed 9.0.1 and 9.0.2. in your paths. When you run the
configure script, check the configure output to see what it found. A
blank means it will use the default path. The key is that it says it
found the ssl.h file. For example:

...
checking for Tcl configuration... found /opt/tcl9/lib64/tcl/tclConfig.sh
...
checking for Tcl public headers... /opt/tcl9/include
...
checking for OpenSSL directory... /usr
checking for OpenSSL include directory... /usr/include
checking for ssl.h... yes
checking for OpenSSL lib directory... /usr/lib64
checking for OpenSSL pkgconfig...
checking for tclsh... /opt/tcl9/bin/tclsh9.0

If the OpenSSL is installed in /usr, then the command line args aren't needed. You also don't need them if you have pkgconfig on your system configured. However if you want to be sure to use the right version,
here's what I use on OpenSuSe:

./configure --enable-64bit --prefix=/opt/tcl9 --exec-prefix=/opt/tcl9 --libdir=/opt/tcl9/lib64/tcl --with-openssl-dir=/usr --with-openssl-includedir=/usr/include --with-openssl-libdir=/usr/lib64

On 7/4/25 5:40 PM, Alan Grunwald wrote:

I replied to the announcement of this release back in February to say
that I couldn't build it, but I seem to have given up after a couple
of very useful suggestions from the author.

After seeing the announcement of Tcl 9.0.2 earlier this week, I am
trying again...

I'm running Linux Mint, 64-bit. I have built Tcl 9.0.2 in
/opt/tcl9.0.2 and it seems to be working fine, so it's just(?!) a
question of rebuilding the external and homebrew packages that the
half-dozen scripts I use regularly rely on.

I've downloaded tcltls-2.0b1.tar.gz (to Downloads) and untarred it (to
Downloads/tcltls-2.0b1)

Using my preferred workflow, I'm sitting in my home directory (the
parent of Downloads) and have typed

(cd Downloads/tcltls-2.0b1; ./configure --enable-64bit --prefix=/opt/
tcl9.0.2 --with-tcl=/opt/tcl9.0.1/lib --with-openssl-includedir=/usr/
include)

followed by

(cd Downloads/tcltls-2.0b1; make)

This fails quickly with a compilation error:

./generic/tlsBIO.c: In function ‘BioOutput’:
./generic/tlsBIO.c:117:32: error: ‘BIO_FLAGS_IN_EOF’ undeclared (first >> use in this function); did you mean ‘BIO_FLAGS_READ’?
   117 |             BIO_set_flags(bio, BIO_FLAGS_IN_EOF);
       |                                ^~~~~~~~~~~~~~~~

The compilation command was

gcc -DPACKAGE_NAME=\"tls\" -DPACKAGE_TARNAME=\"tls\" -
DPACKAGE_VERSION=\"2.0b1\" -DPACKAGE_STRING=\"tls\ 2.0b1\" -
DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DBUILD_tls=/\*\*/ -
DHAVE_STDIO_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
-DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_STRINGS_H=1
-DHAVE_SYS_STAT_H=1 - DHAVE_SYS_TYPES_H=1 -DHAVE_UNISTD_H=1
-DSTDC_HEADERS=1 - DUSE_THREAD_ALLOC=1 -D_REENTRANT=1 -D_THREAD_SAFE=1
-DTCL_THREADS=1 - DUSE_TCL_STUBS=1 -DUSE_TCLOO_STUBS=1
-DMODULE_SCOPE=extern\
__attribute__\(\(__visibility__\(\"hidden\"\)\)\) -DHAVE_HIDDEN=1 -
DHAVE_CAST_TO_UNION=1 -DHAVE_STDBOOL_H=1 -DTCL_WIDE_INT_IS_LONG=1 -
DTCL_CFG_OPTIMIZED=1 -DUSE_TCL_STUBS=1 -DNO_SSL3=1 -D_FORTIFY_SOURCE=2
- fstack-protector-all -fno-strict-overflow -I/usr/include -Wno-
deprecated-declarations -I/usr/include -I"/opt/tcl9.0.2/include" -I.
-O2 -fomit-frame-pointer -DNDEBUG -Wall -fPIC -pipe -m64 -O2 -fomit-
frame-pointer -DNDEBUG -Wall -fPIC  -c `echo ./generic/tlsBIO.c` -o
tlsBIO.o

Now, line 30 of Downloads/tcltls-2.0b1/generic/tlsBIO.c is

#include <openssl/bio.h>

and line 209 of /usr/include/openssl/bio.h is

# define BIO_FLAGS_IN_EOF        0x800

What's going on?

Following the advice in February, I believe I am now putting the right
value on the --with-openssl-includedir flag to configure (I no longer
include /openssl). I'm suspicious that make includes

-I/usr/include

twice in the compile command but I don't think it's causing a problem.

Help!

Alan

Brian,

Thanks for spotting that I've mixed 9.0.1 and 9.0.2. Not clever :-(.

I've corrected that, but maybe unsurprisingly it made no difference.

openssl --version returns a syntax error, but

$ openssl version
OpenSSL 1.1.1 11 Sep 2018


I looked at the extract from the configure output you posted, and while
mine does find ssl.h, it doesn't say anything about the SSL directory:

checking for enable hardening... yes
checking for static linking of openSSL libraries... no
checking for OpenSSL directory...
checking for OpenSSL include directory... /usr/include
checking for ssl.h... yes
checking for OpenSSL lib directory...
checking for OpenSSL pkgconfig...

relevant lines from config.log:

configure:9440: checking for static linking of openSSL libraries configure:9442: result: no
configure:9461: checking for OpenSSL directory
configure:9463: result:
configure:9485: checking for OpenSSL include directory
configure:9487: result: /usr/include
configure:9491: checking for ssl.h
configure:9496: result: yes
configure:9528: checking for OpenSSL lib directory
configure:9530: result:
configure:9567: checking for OpenSSL pkgconfig
configure:9569: result:

and lines 9461-3 of configure are

{ printf "%s\n" "$as_me:${as_lineno-$LINENO}: checking for OpenSSL directory" >&5
printf %s "checking for OpenSSL directory... " >&6; }
{ printf "%s\n" "$as_me:${as_lineno-$LINENO}: result: $openssldir" >&5 printf "%s\n" "$openssldir" >&6; }

It seems that configure isn't setting 'openssl' properly which is likely
to be a bad thing.


I regret I don't remember installing OpenSSL so can't say where it is,

$ which openssl
/usr/local/bin/openssl

What files are you pointing to with --libdir, --with-openssl-dir and --with-openssl-libdir? I can searhc for them and specify the flags appropriately.

Alan

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 06/07/2025 14:22, Alan Grunwald wrote:

On 06/07/2025 02:09, Brian wrote:

Usually this means it found an older version of OpenSSL. Check which
version of OpenSSL you have on your system. You need 1.1.1 or later.
On the command line:

openssl --version


Also you mixed 9.0.1 and 9.0.2. in your paths. When you run the
configure script, check the configure output to see what it found. A
blank means it will use the default path. The key is that it says it
found the ssl.h file. For example:

...
checking for Tcl configuration... found /opt/tcl9/lib64/tcl/tclConfig.sh
...
checking for Tcl public headers... /opt/tcl9/include
...
checking for OpenSSL directory... /usr
checking for OpenSSL include directory... /usr/include
checking for ssl.h... yes
checking for OpenSSL lib directory... /usr/lib64
checking for OpenSSL pkgconfig...
checking for tclsh... /opt/tcl9/bin/tclsh9.0


If the OpenSSL is installed in /usr, then the command line args aren't
needed. You also don't need them if you have pkgconfig on your system
configured. However if you want to be sure to use the right version,
here's what I use on OpenSuSe:

./configure --enable-64bit --prefix=/opt/tcl9 --exec-prefix=/opt/tcl9
--libdir=/opt/tcl9/lib64/tcl --with-openssl-dir=/usr
--with-openssl-includedir=/usr/include --with-openssl-libdir=/usr/lib64




On 7/4/25 5:40 PM, Alan Grunwald wrote:

I replied to the announcement of this release back in February to say
that I couldn't build it, but I seem to have given up after a couple
of very useful suggestions from the author.

After seeing the announcement of Tcl 9.0.2 earlier this week, I am
trying again...

I'm running Linux Mint, 64-bit. I have built Tcl 9.0.2 in
/opt/tcl9.0.2 and it seems to be working fine, so it's just(?!) a
question of rebuilding the external and homebrew packages that the
half-dozen scripts I use regularly rely on.

I've downloaded tcltls-2.0b1.tar.gz (to Downloads) and untarred it
(to Downloads/tcltls-2.0b1)

Using my preferred workflow, I'm sitting in my home directory (the
parent of Downloads) and have typed

(cd Downloads/tcltls-2.0b1; ./configure --enable-64bit --prefix=/opt/
tcl9.0.2 --with-tcl=/opt/tcl9.0.1/lib --with-openssl-includedir=/usr/
include)

followed by

(cd Downloads/tcltls-2.0b1; make)

This fails quickly with a compilation error:

./generic/tlsBIO.c: In function ‘BioOutput’:
./generic/tlsBIO.c:117:32: error: ‘BIO_FLAGS_IN_EOF’ undeclared
(first use in this function); did you mean ‘BIO_FLAGS_READ’?
   117 |             BIO_set_flags(bio, BIO_FLAGS_IN_EOF); >>>        |                                ^~~~~~~~~~~~~~~~

The compilation command was

gcc -DPACKAGE_NAME=\"tls\" -DPACKAGE_TARNAME=\"tls\" -
DPACKAGE_VERSION=\"2.0b1\" -DPACKAGE_STRING=\"tls\ 2.0b1\" -
DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DBUILD_tls=/\*\*/ -
DHAVE_STDIO_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
-DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_STRINGS_H=1
-DHAVE_SYS_STAT_H=1 - DHAVE_SYS_TYPES_H=1 -DHAVE_UNISTD_H=1
-DSTDC_HEADERS=1 - DUSE_THREAD_ALLOC=1 -D_REENTRANT=1
-D_THREAD_SAFE=1 -DTCL_THREADS=1 - DUSE_TCL_STUBS=1
-DUSE_TCLOO_STUBS=1 -DMODULE_SCOPE=extern\
__attribute__\(\(__visibility__\(\"hidden\"\)\)\) -DHAVE_HIDDEN=1 -
DHAVE_CAST_TO_UNION=1 -DHAVE_STDBOOL_H=1 -DTCL_WIDE_INT_IS_LONG=1 -
DTCL_CFG_OPTIMIZED=1 -DUSE_TCL_STUBS=1 -DNO_SSL3=1
-D_FORTIFY_SOURCE=2 - fstack-protector-all -fno-strict-overflow
-I/usr/include -Wno- deprecated-declarations -I/usr/include
-I"/opt/tcl9.0.2/include" -I. -O2 -fomit-frame-pointer -DNDEBUG -Wall
-fPIC -pipe -m64 -O2 -fomit- frame-pointer -DNDEBUG -Wall -fPIC  -c
`echo ./generic/tlsBIO.c` -o tlsBIO.o

Now, line 30 of Downloads/tcltls-2.0b1/generic/tlsBIO.c is

#include <openssl/bio.h>

and line 209 of /usr/include/openssl/bio.h is

# define BIO_FLAGS_IN_EOF        0x800

What's going on?

Following the advice in February, I believe I am now putting the
right value on the --with-openssl-includedir flag to configure (I no
longer include /openssl). I'm suspicious that make includes

-I/usr/include

twice in the compile command but I don't think it's causing a problem.

Help!

Alan

Brian,

Thanks for spotting that I've mixed 9.0.1 and 9.0.2. Not clever :-(.

I've corrected that, but maybe unsurprisingly it made no difference.

openssl --version returns a syntax error, but

$ openssl version
OpenSSL 1.1.1  11 Sep 2018

I looked at the extract from the configure output you posted, and while
mine does find ssl.h, it doesn't say anything about the SSL directory:

checking for enable hardening... yes
checking for static linking of openSSL libraries... no
checking for OpenSSL directory...
checking for OpenSSL include directory... /usr/include
checking for ssl.h... yes
checking for OpenSSL lib directory...
checking for OpenSSL pkgconfig...

relevant lines from config.log:

configure:9440: checking for static linking of openSSL libraries configure:9442: result: no
configure:9461: checking for OpenSSL directory
configure:9463: result:
configure:9485: checking for OpenSSL include directory
configure:9487: result: /usr/include
configure:9491: checking for ssl.h
configure:9496: result: yes
configure:9528: checking for OpenSSL lib directory
configure:9530: result:
configure:9567: checking for OpenSSL pkgconfig
configure:9569: result:

and lines 9461-3 of configure are

    { printf "%s\n" "$as_me:${as_lineno-$LINENO}: checking for OpenSSL directory" >&5
printf %s "checking for OpenSSL directory... " >&6; }
    { printf "%s\n" "$as_me:${as_lineno-$LINENO}: result: $openssldir" >&5
printf "%s\n" "$openssldir" >&6; }

It seems that configure isn't setting 'openssl' properly which is likely
to be a bad thing.

I regret I don't remember installing OpenSSL so can't say where it is,

$ which openssl
/usr/local/bin/openssl

What files are you pointing to with --libdir, --with-openssl-dir and --with-openssl-libdir? I can searhc for them and specify the flags appropriately.

Alan

Sorry, ...isn't setting 'openssldir' ...

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 7/6/25 12:35 PM, Alan Grunwald wrote:

On 06/07/2025 14:22, Alan Grunwald wrote:

On 06/07/2025 02:09, Brian wrote:

Usually this means it found an older version of OpenSSL. Check which
version of OpenSSL you have on your system. You need 1.1.1 or later.
On the command line:

openssl --version


Also you mixed 9.0.1 and 9.0.2. in your paths. When you run the
configure script, check the configure output to see what it found. A
blank means it will use the default path. The key is that it says it
found the ssl.h file. For example:

...
checking for Tcl configuration... found /opt/tcl9/lib64/tcl/tclConfig.sh >>> ...
checking for Tcl public headers... /opt/tcl9/include
...
checking for OpenSSL directory... /usr
checking for OpenSSL include directory... /usr/include
checking for ssl.h... yes
checking for OpenSSL lib directory... /usr/lib64
checking for OpenSSL pkgconfig...
checking for tclsh... /opt/tcl9/bin/tclsh9.0


If the OpenSSL is installed in /usr, then the command line args
aren't needed. You also don't need them if you have pkgconfig on your
system configured. However if you want to be sure to use the right
version, here's what I use on OpenSuSe:

./configure --enable-64bit --prefix=/opt/tcl9 --exec-prefix=/opt/tcl9
--libdir=/opt/tcl9/lib64/tcl --with-openssl-dir=/usr --with-openssl-
includedir=/usr/include --with-openssl-libdir=/usr/lib64




On 7/4/25 5:40 PM, Alan Grunwald wrote:

I replied to the announcement of this release back in February to
say that I couldn't build it, but I seem to have given up after a
couple of very useful suggestions from the author.

After seeing the announcement of Tcl 9.0.2 earlier this week, I am
trying again...

I'm running Linux Mint, 64-bit. I have built Tcl 9.0.2 in /opt/
tcl9.0.2 and it seems to be working fine, so it's just(?!) a
question of rebuilding the external and homebrew packages that the
half-dozen scripts I use regularly rely on.

I've downloaded tcltls-2.0b1.tar.gz (to Downloads) and untarred it
(to Downloads/tcltls-2.0b1)

Using my preferred workflow, I'm sitting in my home directory (the
parent of Downloads) and have typed

(cd Downloads/tcltls-2.0b1; ./configure --enable-64bit --prefix=/
opt/ tcl9.0.2 --with-tcl=/opt/tcl9.0.1/lib --with-openssl-
includedir=/usr/ include)

followed by

(cd Downloads/tcltls-2.0b1; make)

This fails quickly with a compilation error:

./generic/tlsBIO.c: In function ‘BioOutput’:
./generic/tlsBIO.c:117:32: error: ‘BIO_FLAGS_IN_EOF’ undeclared
(first use in this function); did you mean ‘BIO_FLAGS_READ’?
   117 |             BIO_set_flags(bio, BIO_FLAGS_IN_EOF); >>>>        |                                ^~~~~~~~~~~~~~~~

The compilation command was

gcc -DPACKAGE_NAME=\"tls\" -DPACKAGE_TARNAME=\"tls\" -
DPACKAGE_VERSION=\"2.0b1\" -DPACKAGE_STRING=\"tls\ 2.0b1\" -
DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DBUILD_tls=/\*\*/ -
DHAVE_STDIO_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -
DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_STRINGS_H=1 -
DHAVE_SYS_STAT_H=1 - DHAVE_SYS_TYPES_H=1 -DHAVE_UNISTD_H=1 -
DSTDC_HEADERS=1 - DUSE_THREAD_ALLOC=1 -D_REENTRANT=1 -
D_THREAD_SAFE=1 -DTCL_THREADS=1 - DUSE_TCL_STUBS=1 -
DUSE_TCLOO_STUBS=1 -DMODULE_SCOPE=extern\
__attribute__\(\(__visibility__\(\"hidden\"\)\)\) -DHAVE_HIDDEN=1 -
DHAVE_CAST_TO_UNION=1 -DHAVE_STDBOOL_H=1 -DTCL_WIDE_INT_IS_LONG=1 -
DTCL_CFG_OPTIMIZED=1 -DUSE_TCL_STUBS=1 -DNO_SSL3=1 -
D_FORTIFY_SOURCE=2 - fstack-protector-all -fno-strict-overflow -I/
usr/include -Wno- deprecated-declarations -I/usr/include -I"/opt/
tcl9.0.2/include" -I. -O2 -fomit-frame-pointer -DNDEBUG -Wall -fPIC
-pipe -m64 -O2 -fomit- frame-pointer -DNDEBUG -Wall -fPIC  -c
`echo ./generic/tlsBIO.c` -o tlsBIO.o

Now, line 30 of Downloads/tcltls-2.0b1/generic/tlsBIO.c is

#include <openssl/bio.h>

and line 209 of /usr/include/openssl/bio.h is

# define BIO_FLAGS_IN_EOF        0x800

What's going on?

Following the advice in February, I believe I am now putting the
right value on the --with-openssl-includedir flag to configure (I no
longer include /openssl). I'm suspicious that make includes

-I/usr/include

twice in the compile command but I don't think it's causing a problem. >>>>
Help!

Alan

Brian,

Thanks for spotting that I've mixed 9.0.1 and 9.0.2. Not clever :-(.

I've corrected that, but maybe unsurprisingly it made no difference.

openssl --version returns a syntax error, but

$ openssl version
OpenSSL 1.1.1  11 Sep 2018


I looked at the extract from the configure output you posted, and
while mine does find ssl.h, it doesn't say anything about the SSL
directory:

checking for enable hardening... yes
checking for static linking of openSSL libraries... no
checking for OpenSSL directory...
checking for OpenSSL include directory... /usr/include
checking for ssl.h... yes
checking for OpenSSL lib directory...
checking for OpenSSL pkgconfig...

relevant lines from config.log:

configure:9440: checking for static linking of openSSL libraries
configure:9442: result: no
configure:9461: checking for OpenSSL directory
configure:9463: result:
configure:9485: checking for OpenSSL include directory
configure:9487: result: /usr/include
configure:9491: checking for ssl.h
configure:9496: result: yes
configure:9528: checking for OpenSSL lib directory
configure:9530: result:
configure:9567: checking for OpenSSL pkgconfig
configure:9569: result:

and lines 9461-3 of configure are

     { printf "%s\n" "$as_me:${as_lineno-$LINENO}: checking for
OpenSSL directory" >&5
printf %s "checking for OpenSSL directory... " >&6; }
     { printf "%s\n" "$as_me:${as_lineno-$LINENO}: result:
$openssldir" >&5
printf "%s\n" "$openssldir" >&6; }

It seems that configure isn't setting 'openssl' properly which is
likely to be a bad thing.


I regret I don't remember installing OpenSSL so can't say where it is,

$ which openssl
/usr/local/bin/openssl

What files are you pointing to with --libdir, --with-openssl-dir and
--with-openssl-libdir? I can searhc for them and specify the flags
appropriately.

Alan

Sorry, ...isn't setting 'openssldir' ...

So the configure script worked exactly as you specified. You only
provided the --with-openssl-includedir option, so only that path was overridden from the default. The default is a blank which means find it
in the default paths.

However, I don't think that's your issue. The issue is you don't know
where you installed OpenSSL. From your emails it could be the default
one in /usr and your email today suggests it could be in /usr/local. You
need to find where the openssl executable, ssl.h, and libssl.so are
located, then use the 3 options to point to those locations. Make sure
not to include /openssl in the include path since its in the #include
already. My example provided the location where these are in OpenSUSE.
The README.txt file has more info on all of the options.

I'd also suggest doing a 'make clean' and 'make distclean' to remove any
temp files with old path config info. I also suggest using all of the
TCL options to point to the TCL 9.0.2 directory so it doesn't
accidentally find the TCL 8.6 install. The tcl.m4 file is configured to
be very aggressive about using wherever is in the default paths.


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 06/07/2025 20:35, Brian wrote:

On 7/6/25 12:35 PM, Alan Grunwald wrote:

On 06/07/2025 14:22, Alan Grunwald wrote:

On 06/07/2025 02:09, Brian wrote:

Usually this means it found an older version of OpenSSL. Check which
version of OpenSSL you have on your system. You need 1.1.1 or later.
On the command line:

openssl --version


Also you mixed 9.0.1 and 9.0.2. in your paths. When you run the
configure script, check the configure output to see what it found. A
blank means it will use the default path. The key is that it says it
found the ssl.h file. For example:

...
checking for Tcl configuration... found
/opt/tcl9/lib64/tcl/tclConfig.sh
...
checking for Tcl public headers... /opt/tcl9/include
...
checking for OpenSSL directory... /usr
checking for OpenSSL include directory... /usr/include
checking for ssl.h... yes
checking for OpenSSL lib directory... /usr/lib64
checking for OpenSSL pkgconfig...
checking for tclsh... /opt/tcl9/bin/tclsh9.0


If the OpenSSL is installed in /usr, then the command line args
aren't needed. You also don't need them if you have pkgconfig on
your system configured. However if you want to be sure to use the
right version, here's what I use on OpenSuSe:

./configure --enable-64bit --prefix=/opt/tcl9
--exec-prefix=/opt/tcl9 --libdir=/opt/tcl9/lib64/tcl
--with-openssl-dir=/usr --with-openssl- includedir=/usr/include
--with-openssl-libdir=/usr/lib64




On 7/4/25 5:40 PM, Alan Grunwald wrote:

I replied to the announcement of this release back in February to
say that I couldn't build it, but I seem to have given up after a
couple of very useful suggestions from the author.

After seeing the announcement of Tcl 9.0.2 earlier this week, I am
trying again...

I'm running Linux Mint, 64-bit. I have built Tcl 9.0.2 in /opt/
tcl9.0.2 and it seems to be working fine, so it's just(?!) a
question of rebuilding the external and homebrew packages that the
half-dozen scripts I use regularly rely on.

I've downloaded tcltls-2.0b1.tar.gz (to Downloads) and untarred it
(to Downloads/tcltls-2.0b1)

Using my preferred workflow, I'm sitting in my home directory (the
parent of Downloads) and have typed

(cd Downloads/tcltls-2.0b1; ./configure --enable-64bit --prefix=/
opt/ tcl9.0.2 --with-tcl=/opt/tcl9.0.1/lib --with-openssl-
includedir=/usr/ include)

followed by

(cd Downloads/tcltls-2.0b1; make)

This fails quickly with a compilation error:

./generic/tlsBIO.c: In function ‘BioOutput’:
./generic/tlsBIO.c:117:32: error: ‘BIO_FLAGS_IN_EOF’ undeclared >>>>> (first use in this function); did you mean ‘BIO_FLAGS_READ’?
   117 |             BIO_set_flags(bio, BIO_FLAGS_IN_EOF); >>>>>        |                                ^~~~~~~~~~~~~~~~

The compilation command was

gcc -DPACKAGE_NAME=\"tls\" -DPACKAGE_TARNAME=\"tls\" -
DPACKAGE_VERSION=\"2.0b1\" -DPACKAGE_STRING=\"tls\ 2.0b1\" -
DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DBUILD_tls=/\*\*/ -
DHAVE_STDIO_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -
DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_STRINGS_H=1 -
DHAVE_SYS_STAT_H=1 - DHAVE_SYS_TYPES_H=1 -DHAVE_UNISTD_H=1 -
DSTDC_HEADERS=1 - DUSE_THREAD_ALLOC=1 -D_REENTRANT=1 -
D_THREAD_SAFE=1 -DTCL_THREADS=1 - DUSE_TCL_STUBS=1 -
DUSE_TCLOO_STUBS=1 -DMODULE_SCOPE=extern\
__attribute__\(\(__visibility__\(\"hidden\"\)\)\) -DHAVE_HIDDEN=1 - >>>>> DHAVE_CAST_TO_UNION=1 -DHAVE_STDBOOL_H=1 -DTCL_WIDE_INT_IS_LONG=1 - >>>>> DTCL_CFG_OPTIMIZED=1 -DUSE_TCL_STUBS=1 -DNO_SSL3=1 -
D_FORTIFY_SOURCE=2 - fstack-protector-all -fno-strict-overflow -I/
usr/include -Wno- deprecated-declarations -I/usr/include -I"/opt/
tcl9.0.2/include" -I. -O2 -fomit-frame-pointer -DNDEBUG -Wall -fPIC >>>>> -pipe -m64 -O2 -fomit- frame-pointer -DNDEBUG -Wall -fPIC  -c `echo >>>>> ./generic/tlsBIO.c` -o tlsBIO.o

Now, line 30 of Downloads/tcltls-2.0b1/generic/tlsBIO.c is

#include <openssl/bio.h>

and line 209 of /usr/include/openssl/bio.h is

# define BIO_FLAGS_IN_EOF        0x800

What's going on?

Following the advice in February, I believe I am now putting the
right value on the --with-openssl-includedir flag to configure (I
no longer include /openssl). I'm suspicious that make includes

-I/usr/include

twice in the compile command but I don't think it's causing a problem. >>>>>
Help!

Alan

Brian,

Thanks for spotting that I've mixed 9.0.1 and 9.0.2. Not clever :-(.

I've corrected that, but maybe unsurprisingly it made no difference.

openssl --version returns a syntax error, but

$ openssl version
OpenSSL 1.1.1  11 Sep 2018


I looked at the extract from the configure output you posted, and
while mine does find ssl.h, it doesn't say anything about the SSL
directory:

checking for enable hardening... yes
checking for static linking of openSSL libraries... no
checking for OpenSSL directory...
checking for OpenSSL include directory... /usr/include
checking for ssl.h... yes
checking for OpenSSL lib directory...
checking for OpenSSL pkgconfig...

relevant lines from config.log:

configure:9440: checking for static linking of openSSL libraries
configure:9442: result: no
configure:9461: checking for OpenSSL directory
configure:9463: result:
configure:9485: checking for OpenSSL include directory
configure:9487: result: /usr/include
configure:9491: checking for ssl.h
configure:9496: result: yes
configure:9528: checking for OpenSSL lib directory
configure:9530: result:
configure:9567: checking for OpenSSL pkgconfig
configure:9569: result:

and lines 9461-3 of configure are

     { printf "%s\n" "$as_me:${as_lineno-$LINENO}: checking for
OpenSSL directory" >&5
printf %s "checking for OpenSSL directory... " >&6; }
     { printf "%s\n" "$as_me:${as_lineno-$LINENO}: result:
$openssldir" >&5
printf "%s\n" "$openssldir" >&6; }

It seems that configure isn't setting 'openssl' properly which is
likely to be a bad thing.


I regret I don't remember installing OpenSSL so can't say where it is,

$ which openssl
/usr/local/bin/openssl

What files are you pointing to with --libdir, --with-openssl-dir and
--with-openssl-libdir? I can searhc for them and specify the flags
appropriately.

Alan

Sorry, ...isn't setting 'openssldir' ...

So the configure script worked exactly as you specified. You only
provided the --with-openssl-includedir option, so only that path was overridden from the default. The default is a blank which means find it
in the default paths.

However, I don't think that's your issue. The issue is you don't know
where you installed OpenSSL. From your emails it could be the default
one in /usr and your email today suggests it could be in /usr/local. You need to find where the openssl executable, ssl.h, and libssl.so are
located, then use the 3 options to point to those locations. Make sure
not to include /openssl in the include path since its in the #include already. My example provided the location where these are in OpenSUSE.
The README.txt file has more info on all of the options.

I'd also suggest doing a 'make clean' and 'make distclean' to remove any temp files with old path config info. I also suggest using all of the
TCL options to point to the TCL 9.0.2 directory so it doesn't
accidentally find the TCL 8.6 install. The tcl.m4 file is configured to
be very aggressive about using wherever is in the default paths.

Hi Brian,

I think I have two versions of OpenSSL installed -

I have two openssl executables - /usr/bin/openssl and
/usr/local/bin/openssl,

two copies of ssl.h - /usr/local/include/openssl/ssl.h and /usr/include/openssl/ssl.h

and two copies of libssl.so - /usr/lib/x86_64-linux-gnu/libssl.so and /usr/local/lib/libssl.so

Looking at the versions of the two openssl executables,

$ /usr/local/bin/openssl version
OpenSSL 1.1.1 11 Sep 2018
$ /usr/bin/openssl version
OpenSSL 3.0.2 15 Mar 2022 (Library: OpenSSL 3.0.2 15 Mar 2022)

Checking the content of the two bio.h files that sit alongside the ssl.h files, only /usr/include/openssl/bio.h defines BIO_FLAGS_IN_EOF

FWIW /usr/local/bin appears before /usr/bin in my PATH.

$ ls -l /usr/bin/openssl /usr/local/bin/openssl /usr/lib/x86_64-linux-gnu/libssl.so /usr/local/lib/libssl.so /usr/local/include/openssl/ssl.h /usr/include/openssl/ssl.h /usr/lib/x86_64-linux-gnu/libssl.so.3 /usr/local/lib/libssl.so.1.1
-rwxr-xr-x 1 root root 1001272 Feb 5 13:19 /usr/bin/openssl
-rw-r--r-- 1 root root 124376 Feb 5 13:19 /usr/include/openssl/ssl.h lrwxrwxrwx 1 root root 11 Feb 5 13:19 /usr/lib/x86_64-linux-gnu/libssl.so -> libssl.so.3
-rw-r--r-- 1 root root 667864 Feb 5 13:19 /usr/lib/x86_64-linux-gnu/libssl.so.3
-rwxr-xr-x 1 root root 870432 Jan 16 2023 /usr/local/bin/openssl
-rw-r--r-- 1 root root 110319 Jan 16 2023 /usr/local/include/openssl/ssl.h lrwxrwxrwx 1 root root 13 Jan 16 2023 /usr/local/lib/libssl.so -> libssl.so.1.1
-rwxr-xr-x 1 root root 700296 Jan 16 2023 /usr/local/lib/libssl.so.1.1

What do you recommend I use as a configure command line, judging by the location of the various openssl files, I think the following is
suitable, although I haven't addressed your concerns about getting the
right Tcl installation.

./configure --enable-64bit --prefix=/opt.tcl9.0.2
--exec-prefix=/opt/tcl9.0.2 --with-openssl-includedir=/usr/ --with-openssl-libdir=/usr/lib/x86_64-linux-gnu --with-openssl-dir=/usr/bin


It's getting too late for me to trust myself to type this command in
before tomorrow morning, but I am concerned that as far as I can make
out, the changes you've recommended affect the *link* part of the
process, but I am seeing problems with the *compile* steps.

Many thanks - I'll see what I see tomorrow :-)

Alan

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 7/7/25 4:53 PM, Alan Grunwald wrote:

On 06/07/2025 20:35, Brian wrote:

On 7/6/25 12:35 PM, Alan Grunwald wrote:

On 06/07/2025 14:22, Alan Grunwald wrote:

On 06/07/2025 02:09, Brian wrote:

So the configure script worked exactly as you specified. You only
provided the --with-openssl-includedir option, so only that path was
overridden from the default. The default is a blank which means find
it in the default paths.

However, I don't think that's your issue. The issue is you don't know
where you installed OpenSSL. From your emails it could be the default
one in /usr and your email today suggests it could be in /usr/local.
You need to find where the openssl executable, ssl.h, and libssl.so
are located, then use the 3 options to point to those locations. Make
sure not to include /openssl in the include path since its in the
#include already. My example provided the location where these are in
OpenSUSE. The README.txt file has more info on all of the options.

I'd also suggest doing a 'make clean' and 'make distclean' to remove
any temp files with old path config info. I also suggest using all of
the TCL options to point to the TCL 9.0.2 directory so it doesn't
accidentally find the TCL 8.6 install. The tcl.m4 file is configured
to be very aggressive about using wherever is in the default paths.

Hi Brian,

I think I have two versions of OpenSSL installed -

I have two openssl executables - /usr/bin/openssl and /usr/local/bin/ openssl,

two copies of ssl.h -            /usr/local/include/openssl/ssl.h and /
usr/include/openssl/ssl.h

and two copies of libssl.so -    /usr/lib/x86_64-linux-gnu/libssl.so
and /usr/local/lib/libssl.so

Looking at the versions of the two openssl executables,

$ /usr/local/bin/openssl version
OpenSSL 1.1.1  11 Sep 2018
$ /usr/bin/openssl version
OpenSSL 3.0.2 15 Mar 2022 (Library: OpenSSL 3.0.2 15 Mar 2022)

Checking the content of the two bio.h files that sit alongside the ssl.h files, only /usr/include/openssl/bio.h defines BIO_FLAGS_IN_EOF

FWIW /usr/local/bin appears before /usr/bin in my PATH.

$ ls -l /usr/bin/openssl /usr/local/bin/openssl /usr/lib/x86_64-linux- gnu/libssl.so /usr/local/lib/libssl.so /usr/local/include/openssl/
ssl.h /usr/include/openssl/ssl.h /usr/lib/x86_64-linux-gnu/libssl.so.3 / usr/local/lib/libssl.so.1.1
-rwxr-xr-x 1 root root 1001272 Feb  5 13:19 /usr/bin/openssl
-rw-r--r-- 1 root root  124376 Feb  5 13:19 /usr/include/openssl/ssl.h lrwxrwxrwx 1 root root      11 Feb  5 13:19 /usr/lib/x86_64-linux-gnu/ libssl.so -> libssl.so.3
-rw-r--r-- 1 root root  667864 Feb  5 13:19 /usr/lib/x86_64-linux-gnu/ libssl.so.3
-rwxr-xr-x 1 root root  870432 Jan 16  2023 /usr/local/bin/openssl -rw-r--r-- 1 root root  110319 Jan 16  2023 /usr/local/include/openssl/ ssl.h
lrwxrwxrwx 1 root root      13 Jan 16  2023 /usr/local/lib/libssl.so ->
libssl.so.1.1
-rwxr-xr-x 1 root root  700296 Jan 16  2023 /usr/local/lib/libssl.so.1.1

What do you recommend I use as a configure command line, judging by the location of the various openssl files, I think the following is
suitable, although I haven't addressed your concerns about getting the
right Tcl installation.

./configure --enable-64bit --prefix=/opt.tcl9.0.2 --exec-prefix=/opt/ tcl9.0.2 --with-openssl-includedir=/usr/ --with-openssl-libdir=/usr/lib/ x86_64-linux-gnu --with-openssl-dir=/usr/bin

It's getting too late for me to trust myself to type this command in
before tomorrow morning, but I am concerned that as far as I can make
out, the changes you've recommended affect the *link* part of the
process, but I am seeing problems with the *compile* steps.

Many thanks - I'll see what I see tomorrow :-)

Alan

Yes, that's it. You have 2 versions and the ancient 1.1.1 version is in /usr/local, which appears before /usr in the path. So you need to
override that. I seem to recall from the earlier discussion that may
have been the first 1.1.1 release which is missing some things. Anyway,
I would not use such an outdated and insecure version. I'd suggest the following for the configure options, though check if --libdir is correct
for you. You want it to point to the location of the tclConfig.sh file.

./configure --enable-64bit --prefix=/opt/tcl9.0.2
--exec-prefix=/opt/tcl9.0.2 --libdir=/opt/tcl9.0.2/lib64/tcl --with-openssl-dir=/usr --with-openssl-includedir=/usr/include --with-openssl-libdir=/usr/lib/x86_64-linux-gnu

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 08/07/2025 00:03, Brian wrote:

On 7/7/25 4:53 PM, Alan Grunwald wrote:

On 06/07/2025 20:35, Brian wrote:

On 7/6/25 12:35 PM, Alan Grunwald wrote:

On 06/07/2025 14:22, Alan Grunwald wrote:

On 06/07/2025 02:09, Brian wrote:

So the configure script worked exactly as you specified. You only
provided the --with-openssl-includedir option, so only that path was
overridden from the default. The default is a blank which means find
it in the default paths.

However, I don't think that's your issue. The issue is you don't know
where you installed OpenSSL. From your emails it could be the default
one in /usr and your email today suggests it could be in /usr/local.
You need to find where the openssl executable, ssl.h, and libssl.so
are located, then use the 3 options to point to those locations. Make
sure not to include /openssl in the include path since its in the
#include already. My example provided the location where these are in
OpenSUSE. The README.txt file has more info on all of the options.

I'd also suggest doing a 'make clean' and 'make distclean' to remove
any temp files with old path config info. I also suggest using all of
the TCL options to point to the TCL 9.0.2 directory so it doesn't
accidentally find the TCL 8.6 install. The tcl.m4 file is configured
to be very aggressive about using wherever is in the default paths.

Hi Brian,

I think I have two versions of OpenSSL installed -

I have two openssl executables - /usr/bin/openssl and /usr/local/bin/
openssl,

two copies of ssl.h -            /usr/local/include/openssl/ssl.h and
/ usr/include/openssl/ssl.h

and two copies of libssl.so -    /usr/lib/x86_64-linux-gnu/libssl.so
and /usr/local/lib/libssl.so

Looking at the versions of the two openssl executables,

$ /usr/local/bin/openssl version
OpenSSL 1.1.1  11 Sep 2018
$ /usr/bin/openssl version
OpenSSL 3.0.2 15 Mar 2022 (Library: OpenSSL 3.0.2 15 Mar 2022)

Checking the content of the two bio.h files that sit alongside the
ssl.h files, only /usr/include/openssl/bio.h defines BIO_FLAGS_IN_EOF

FWIW /usr/local/bin appears before /usr/bin in my PATH.

$ ls -l /usr/bin/openssl /usr/local/bin/openssl /usr/lib/x86_64-linux-
gnu/libssl.so /usr/local/lib/libssl.so /usr/local/include/openssl/
ssl.h /usr/include/openssl/ssl.h /usr/lib/x86_64-linux-gnu/libssl.so.3
/ usr/local/lib/libssl.so.1.1
-rwxr-xr-x 1 root root 1001272 Feb  5 13:19 /usr/bin/openssl
-rw-r--r-- 1 root root  124376 Feb  5 13:19 /usr/include/openssl/ssl.h
lrwxrwxrwx 1 root root      11 Feb  5 13:19 /usr/lib/x86_64-linux-gnu/
libssl.so -> libssl.so.3
-rw-r--r-- 1 root root  667864 Feb  5 13:19 /usr/lib/x86_64-linux-gnu/
libssl.so.3
-rwxr-xr-x 1 root root  870432 Jan 16  2023 /usr/local/bin/openssl
-rw-r--r-- 1 root root  110319 Jan 16  2023
/usr/local/include/openssl/ ssl.h
lrwxrwxrwx 1 root root      13 Jan 16  2023 /usr/local/lib/libssl.so >> -> libssl.so.1.1
-rwxr-xr-x 1 root root  700296 Jan 16  2023 /usr/local/lib/libssl.so.1.1 >>
What do you recommend I use as a configure command line, judging by
the location of the various openssl files, I think the following is
suitable, although I haven't addressed your concerns about getting the
right Tcl installation.

./configure --enable-64bit --prefix=/opt.tcl9.0.2 --exec-prefix=/opt/
tcl9.0.2 --with-openssl-includedir=/usr/
--with-openssl-libdir=/usr/lib/ x86_64-linux-gnu
--with-openssl-dir=/usr/bin


It's getting too late for me to trust myself to type this command in
before tomorrow morning, but I am concerned that as far as I can make
out, the changes you've recommended affect the *link* part of the
process, but I am seeing problems with the *compile* steps.

Many thanks - I'll see what I see tomorrow :-)

Alan

Yes, that's it. You have 2 versions and the ancient 1.1.1 version is in /usr/local, which appears before /usr in the path. So you need to
override that. I seem to recall from the earlier discussion that may
have been the first 1.1.1 release which is missing some things. Anyway,
I would not use such an outdated and insecure version. I'd suggest the following for the configure options, though check if --libdir is correct
for you. You want it to point to the location of the tclConfig.sh file.

./configure --enable-64bit --prefix=/opt/tcl9.0.2 --exec-prefix=/opt/tcl9.0.2 --libdir=/opt/tcl9.0.2/lib64/tcl --with-openssl-dir=/usr --with-openssl-includedir=/usr/include --with-openssl-libdir=/usr/lib/x86_64-linux-gnu

I went with

$ ./configure --enable-64bit --prefix=/opt/tcl9.0.2 --exec-prefix=/opt/tcl9.0.2 --libdir=/opt/tcl9.0.2/lib
--with-openssl-dir=/usr --with-openssl-includedir=/usr/include --with-openssl-libdir=/usr/lib/x86_64-linux-gnu

(Your prediction of where tclConfig.sh ended up was wide of the mark.)

Sadly this still made no difference and I still get compilation errors
from tlsBIO.c saying that BIO_FLAGS_IN_EOF is undefined.

After reading the top answer to this question on StackOverflow

https://stackoverflow.com/questions/10343950/c-what-option-do-i-use-to-produce-a-listing-file

I tried executing

(cd Downloads/tcltls-2.0b1; gcc -DPACKAGE_NAME=\"tls\" -DPACKAGE_TARNAME=\"tls\" -DPACKAGE_VERSION=\"2.0b1\"
-DPACKAGE_STRING=\"tls\ 2.0b1\" -DPACKAGE_BUGREPORT=\"\"
-DPACKAGE_URL=\"\" -DBUILD_tls=/\*\*/ -DHAVE_STDIO_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1
-DHAVE_STRINGS_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TYPES_H=1
-DHAVE_UNISTD_H=1 -DSTDC_HEADERS=1 -DUSE_THREAD_ALLOC=1 -D_REENTRANT=1 -D_THREAD_SAFE=1 -DTCL_THREADS=1 -DUSE_TCL_STUBS=1 -DUSE_TCLOO_STUBS=1 -DMODULE_SCOPE=extern\ __attribute__\(\(__visibility__\(\"hidden\"\)\)\) -DHAVE_HIDDEN=1 -DHAVE_CAST_TO_UNION=1 -DHAVE_STDBOOL_H=1 -DTCL_WIDE_INT_IS_LONG=1 -DTCL_CFG_OPTIMIZED=1 -DUSE_TCL_STUBS=1
-DNO_SSL3=1 -D_FORTIFY_SOURCE=2 -fstack-protector-all
-fno-strict-overflow -I/usr/include -Wno-deprecated-declarations -I/usr/include -I"/home/alan/Downloads/tcl9.0.2/generic" -I. -O2 -fomit-frame-pointer -DNDEBUG -Wall -fPIC -pipe -m64 -O2
-fomit-frame-pointer -DNDEBUG -Wall -fPIC -c `echo ./generic/tlsBIO.c`
-E -otlsBIO.lis)

(which is derived from the failing compilation command, with
"-otlsBIO.c" replaced by "-E -otlsBIO.lis")

Poking around in the pre-processed generated source I found, around line
5047

# 31 "./generic/tlsInt.h" 2
# 1 "/usr/local/include/openssl/ssl.h" 1 3
# 15 "/usr/local/include/openssl/ssl.h" 3

Now, line 31 of tlsInt.h is

#include <openssl/ssl.h>

so I *think* I can understand the preprocessor output. What I am
powerless to explain is why it then appears to pick up the old version
of ssl.h; later in the prepreocessor output, it also appears to pick up
the old version of bio.h which doesn't #define BIO_FLAGS_IN_EOF

(I'm also curious as to why configure has decided to point to my Tcl
download location rather than the installation location.)

Alan
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Alan,

A shot in the dark...from the gcc docs:

If a standard system include directory, or a directory specified with `-isystem', is also specified with `-I', the `-I' option will be
ignored. The directory will still be searched but as a system directory
at its normal position in the system include chain. This is to ensure
that GCC's procedure to fix buggy system headers and the ordering for
the include_next directive are not inadvertently changed. If you really
need to change the search order for system directories, use the
`-nostdinc' and/or `-isystem' options.

Key phrase - "-I option will be ignored"

So I'm guessing that /usr/include is already in the default system
include search path and therefore gets ignored when specified as the -I option. Additionally, /usr/local/include appears before /usr/include in
the default search path. That might explain what you are seeing.

/Ashok
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

* Ashok <apnmbx-public@yahoo.com>
| So I'm guessing that /usr/include is already in the default system
| include search path and therefore gets ignored when specified as the
| -I
| option. Additionally, /usr/local/include appears before /usr/include
| in the default search path. That might explain what you are seeing.

https://stackoverflow.com/questions/4980819/what-are-the-gcc-default-include-directories

suggests to use

echo | gcc -xc -E -v -

to see the defaults plus any effect of environment variables like CPATH

% echo | gcc -xc -E -v -
[...]
#include "..." search starts here:
#include <...> search starts here:
/usr/lib64/gcc/x86_64-suse-linux/7/include
/usr/local/include
/usr/lib64/gcc/x86_64-suse-linux/7/include-fixed
/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/include
/usr/include
End of search list.

So indeed /usr/local/include is listed *before* /usr/include.

One could use -isystem/usr/include to change that order:

% echo | gcc -isystem/usr/include -xc -E -v -
[...]
#include "..." search starts here:
#include <...> search starts here:
/usr/include
/usr/lib64/gcc/x86_64-suse-linux/7/include
/usr/local/include
/usr/lib64/gcc/x86_64-suse-linux/7/include-fixed
/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/include
End of search list.


HTH
R'
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 7/8/25 12:08 PM, Ralf Fassel wrote:

* Ashok <apnmbx-public@yahoo.com>
| So I'm guessing that /usr/include is already in the default system
| include search path and therefore gets ignored when specified as the
| -I
| option. Additionally, /usr/local/include appears before /usr/include
| in the default search path. That might explain what you are seeing.

https://stackoverflow.com/questions/4980819/what-are-the-gcc-default-include-directories

suggests to use

echo | gcc -xc -E -v -

to see the defaults plus any effect of environment variables like CPATH

% echo | gcc -xc -E -v -
[...]
#include "..." search starts here:
#include <...> search starts here:
/usr/lib64/gcc/x86_64-suse-linux/7/include
/usr/local/include
/usr/lib64/gcc/x86_64-suse-linux/7/include-fixed
/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/include
/usr/include
End of search list.

So indeed /usr/local/include is listed *before* /usr/include.

One could use -isystem/usr/include to change that order:

% echo | gcc -isystem/usr/include -xc -E -v -
[...]
#include "..." search starts here:
#include <...> search starts here:
/usr/include
/usr/lib64/gcc/x86_64-suse-linux/7/include
/usr/local/include
/usr/lib64/gcc/x86_64-suse-linux/7/include-fixed
/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/include
End of search list.

HTH
R'

Another option is to remove the standard include paths. So use the
"-nostdinc" option and add back the "-I/usr/include" path too via the
CFLAGS env var.

See https://commandlinefanatic.com/cgi-bin/showarticle.cgi?article=art026

The last option is just delete that old version of OpenSSL.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

* Brian <brian199@comcast.net>
| The last option is just delete that old version of OpenSSL.

Which seems a reasonable solution anyway IMHO :-)

R'
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 09/07/2025 08:55, Ralf Fassel wrote:

* Brian <brian199@comcast.net>
| The last option is just delete that old version of OpenSSL.

Which seems a reasonable solution anyway IMHO :-)

R'

Isn't this fun?!

In a private email (apologies for the slight breach of protocol), Ralf
pointed out that specifying CFLAGS was only appropriate if the makefile honours it; experience suggests that it doesn't and a check through the makefile doesn't present any obvious way to supply extra flags. Ralf
also recommended defining C_INCLUDE_PATH, a gcc-specific environment
variable, to be /usr/include, which does get original problem.

But...

$ (cd Downloads/tcltls-2.0b1/; C_INCLUDE_PATH=/usr/include make)
.
.
.
gcc -DPACKAGE_NAME=\"tls\" -DPACKAGE_TARNAME=\"tls\" -DPACKAGE_VERSION=\"2.0b1\" -DPACKAGE_STRING=\"tls\ 2.0b1\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DBUILD_tls=/\*\*/ -DHAVE_STDIO_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_STRINGS_H=1 -DHAVE_SYS_STAT_H=1
-DHAVE_SYS_TYPES_H=1 -DHAVE_UNISTD_H=1 -DSTDC_HEADERS=1
-DUSE_THREAD_ALLOC=1 -D_REENTRANT=1 -D_THREAD_SAFE=1 -DTCL_THREADS=1 -DUSE_TCL_STUBS=1 -DUSE_TCLOO_STUBS=1 -DMODULE_SCOPE=extern\ __attribute__\(\(__visibility__\(\"hidden\"\)\)\) -DHAVE_HIDDEN=1 -DHAVE_CAST_TO_UNION=1 -DHAVE_STDBOOL_H=1 -DTCL_WIDE_INT_IS_LONG=1 -DTCL_CFG_OPTIMIZED=1 -DUSE_TCL_STUBS=1 -DNO_SSL3=1 -D_FORTIFY_SOURCE=2 -fstack-protector-all -fno-strict-overflow -I/usr/include -Wno-deprecated-declarations -I/usr/include -I"/home/alan/Downloads/tcl9.0.2/generic" -I. -O2
-fomit-frame-pointer -DNDEBUG -Wall -fPIC -pipe -m64 -O2
-fomit-frame-pointer -DNDEBUG -Wall -fPIC -c `echo ./generic/tls.c` -o
tls.o
In file included from /usr/include/openssl/ssl.h:21,
from ./generic/tlsInt.h:31,
from ./generic/tls.c:26:
/usr/include/openssl/macros.h:155:4: error: #error "OPENSSL_API_COMPAT expresses an impossible API compatibility level"
155 | # error "OPENSSL_API_COMPAT expresses an impossible API compatibility level"
| ^~~~~

Good news - no trace of /usr/local/include
Bad news is obvious.

I've had a poke around /usr/include/openssl/macros.h, but I regret I
can't properly make out how it encodes OPENSSL_API_COMPAT and friends,
and since I'm not sure level of compatability is required, I'm unwilling
to try specifying it. The following comment occurs at line 84 of macros.h

* Applications should use -DOPENSSL_API_COMPAT=<version> to suppress the
* declarations of functions deprecated in or before <version>. If this is
* undefined, the value of the macro OPENSSL_CONFIGURED_API (defined in
* <openssl/opensslconf.h>) is the default.

OPENSSL_CONFIGURED_API is defined to be 30000 (in /usr/include/x86_64-linix-gnu/openssl/configuration.h).

There are three places where macros.h might produce this error message -
the first (at line 139) occurs if OPENSSL_API_LEVEL >
OPENSSL_VERSION_MAJOR * 10000 + OPENSSL_MINOR_VERSION * 100. Now,
according to /usr/include.openssl/opensslv.h, the major and minor
versions are 3 and 0 respectively. The error doesn't trigger, which is
what I'd expect.

The next (at line 151) occurs if OPENSSL_API_LEVEL < 30000 && OPENSSL_API_LEVEL >= 20000. This doesn't trigger either.

The error (at line 155) that does trigger indicates that
OPENSSL_API_LEVEL < 908 which I don't understand, since it seems to me
after reading macros.h several times in different directions that since OPENSSL_API_COMPAT isn't defined, OPENSSL_API_LEVEL should be set to OPENSSL_CONFIGURED_API, i.e. 30000.


I am loth to follow the otherwise very reasonable suggestion that I just remove the old openssl installation, since I'm not sure how it got there
or what relies upon it. Granted, I could simply rename, the offending directories to, say old_openssl, but I fear that if I did that, then by
the time whatever it is blows up, I will have forgotten about the
renaming exercise.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

* Alan Grunwald <nospam.nurdglaw@gmail.com>
| In file included from /usr/include/openssl/ssl.h:21,
| from ./generic/tlsInt.h:31,
| from ./generic/tls.c:26:
| /usr/include/openssl/macros.h:155:4: error: #error "OPENSSL_API_COMPAT
| expresses an impossible API compatibility level"
| 155 | # error "OPENSSL_API_COMPAT expresses an impossible API
| compatibility level"
| | ^~~~~

| Good news - no trace of /usr/local/include
| Bad news is obvious.
--<snip-snip>--

| The error (at line 155) that does trigger indicates that
| OPENSSL_API_LEVEL < 908 which I don't understand, since it seems to me
| after reading macros.h several times in different directions that
| since OPENSSL_API_COMPAT isn't defined, OPENSSL_API_LEVEL should be
| set to
| OPENSSL_CONFIGURED_API, i.e. 30000.

- Start from scratch (delete and re-extract the tcltls sources, make
absolutely sure to use only one TCL version, re-configure tcltls).

- Temporarily rename the /usr/local/include/openssl (probably add a
00README.txt in /usr/local/include)

- if the error persists, try to find out what the macro
OPENSSL_API_LEVEL is set to:

use this little hack from Stackoverflow:

#define STR_HELPER(x) #x
#define STR(x) STR_HELPER(x)

#define AAA 123
#pragma message "content of AAA: " STR(AAA)

(just make a backup copy of openssl/macros.h and add that #pragma at
strategic places)

- or just #define OPENSSL_API_COMPAT to the default value (30000)

Needless to say that on my system (opensuse 15.6, gcc 7.5.0), tcltls
2.0b1 configured and compiled with no problem against either tcl8.6 or tcl9.0.2.

R'
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 09/07/2025 18:47, Ralf Fassel wrote:

* Alan Grunwald <nospam.nurdglaw@gmail.com>
| In file included from /usr/include/openssl/ssl.h:21,
| from ./generic/tlsInt.h:31,
| from ./generic/tls.c:26:
| /usr/include/openssl/macros.h:155:4: error: #error "OPENSSL_API_COMPAT
| expresses an impossible API compatibility level"
| 155 | # error "OPENSSL_API_COMPAT expresses an impossible API
| compatibility level"
| | ^~~~~

| Good news - no trace of /usr/local/include
| Bad news is obvious.
--<snip-snip>--

| The error (at line 155) that does trigger indicates that
| OPENSSL_API_LEVEL < 908 which I don't understand, since it seems to me
| after reading macros.h several times in different directions that
| since OPENSSL_API_COMPAT isn't defined, OPENSSL_API_LEVEL should be
| set to
| OPENSSL_CONFIGURED_API, i.e. 30000.

- Start from scratch (delete and re-extract the tcltls sources, make
absolutely sure to use only one TCL version, re-configure tcltls).

- Temporarily rename the /usr/local/include/openssl (probably add a
00README.txt in /usr/local/include)

- if the error persists, try to find out what the macro
OPENSSL_API_LEVEL is set to:

use this little hack from Stackoverflow:

#define STR_HELPER(x) #x
#define STR(x) STR_HELPER(x)

#define AAA 123
#pragma message "content of AAA: " STR(AAA)

(just make a backup copy of openssl/macros.h and add that #pragma at
strategic places)

- or just #define OPENSSL_API_COMPAT to the default value (30000)

Needless to say that on my system (opensuse 15.6, gcc 7.5.0), tcltls
2.0b1 configured and compiled with no problem against either tcl8.6 or tcl9.0.2.

R'

:blush:

While looking at what I'd need to do to clear things down and start
again from scratch, I spotted that I had downloaded openssl_1.1.1 myself
in January 2023. Buoyed by this discovery, I did

make uninstall

from the openssl_1.1.1 download directory, then started again with
tcltls 2.0b1, which... compiled and linked with no problem.

Many, many thanks to Ralf, Brian and Ashok.

Alan
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Am 09.07.25 um 19:47 schrieb Ralf Fassel:

Needless to say that on my system (opensuse 15.6, gcc 7.5.0), tcltls
2.0b1 configured and compiled with no problem against either tcl8.6 or tcl9.0.2.

I struggled with the same problem some while ago, it compiled without
problems on my local opensuse 15.6, but failed in the Github runner. I
compile the dependencies myself as static libraries and then try to link
to those, to make binaries with low dependencies.

For all other libraries (libjpeg, etc.) this works - for OpenSSL it
never worked well, I think it still doesn't work to this day and finally
I gave up on it altogether.

Christian



--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

* Alan Grunwald <nospam.nurdglaw@gmail.com>
| [...], then started again with
| tcltls 2.0b1, which... compiled and linked with no problem.

| Many, many thanks to Ralf, Brian and Ashok.

Happy to help :-)

R'
--- Synchronet 3.21a-Linux NewsLink 1.2