From Newsgroup: comp.lang.tcl

Hello all,

I'm running into a very annoying issue: I have a macOS application that includes the dynamic library for tcl 9.0.3 (libtcl9.0.dylib). To allow
users to run the application directly, I need to "codesign" the application with a certificate issued by Apple before distributing it. This used to
work without issues with older tcl/tk versions (e.g, 8.6.x). But now, when
I try to run the "codesign" command on the executable, it refuses to put
the signature into it, saying the problematic file is libtcl9.0.dylib

Sadly, I tried to get more information about why this file prevented the
code signing process to succeed, but I couldn't. Whatever option I pass to
the "codesign" command, it doesn't include any reason why the file would be problematic. Now I saw that on Linux, the equivalent .so file also included the tcl library into it, somehow appended to the shared object file as a
zip file. And I'm wondering if this could be the reason why the code-
signing fails on macOS: if the same thing has been done to the .dylib, the "codesign" utility may detect that the file is "polluted" with additional contents and could refuse to sign it.

So I'm wondering: is there any additional contents appended to the libtcl9.0.dylib file on macOS as there is to the .so file on Linux? And if there is, is there any way to disable this behavior when building tcl/tk 9.0.3? I'm already building from the source code, so rebuilding everything with other configuration flags is not a problem. I've checked the available options to the "configure" script, but I couldn't really see anything
obvious. The only option that might be relevant would be "--disable-zipfs", since the tcl library is in a zip file, but that looks like a bit of a stretch, not sure if that would change anything. Any hint?

Thanks!
--
Eric
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Am 02.06.2026 um 10:48 schrieb Eric Brunel:

Hello all,

I'm running into a very annoying issue: I have a macOS application that includes the dynamic library for tcl 9.0.3 (libtcl9.0.dylib). To allow
users to run the application directly, I need to "codesign" the application with a certificate issued by Apple before distributing it. This used to
work without issues with older tcl/tk versions (e.g, 8.6.x). But now, when
I try to run the "codesign" command on the executable, it refuses to put
the signature into it, saying the problematic file is libtcl9.0.dylib

In ETCL in Bologna, Manfred Rosenberger has dedicated his speach on this issue.

Maybe, there are some ideas?

https://www.eurotcl.eu/presentations/EuroTcl2025-Rosenberger-DesktopAppsForMacOS.pdf

Harald
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On Tue, 2 Jun 2026 12:54:13 +0200, Harald Oehlmann wrote:

Am 02.06.2026 um 10:48 schrieb Eric Brunel:

Hello all,

I'm running into a very annoying issue: I have a macOS application that
includes the dynamic library for tcl 9.0.3 (libtcl9.0.dylib). To allow
users to run the application directly, I need to "codesign" the
application with a certificate issued by Apple before distributing it.
This used to work without issues with older tcl/tk versions (e.g,
8.6.x). But now, when I try to run the "codesign" command on the
executable, it refuses to put the signature into it, saying the
problematic file is libtcl9.0.dylib

In ETCL in Bologna, Manfred Rosenberger has dedicated his speach on this issue.

Maybe, there are some ideas?

https://www.eurotcl.eu/presentations/EuroTcl2025-Rosenberger-

DesktopAppsForMacOS.pdf

Harald

Thanks a lot for the pointer, Harald, it does seem it addresses a very
similar issue indeed. Sadly, it looks like my situation is not exactly the same one: I had all this codesigning and notarization process figured out,
and it was working, until tcl/tk 9.0.

I did check my initial hypothesis by running the command "unzip -l libtcl9.0.dylib" in a terminal, and it does seem the zipped contents of the tcl libray is indeed appended to the dynamic library file, as the command issues a warning "1937924 extra bytes at beginning or within zipfile", but then does print a list of files starting with the directory "tcl_library".
And it wouldn't be a surprise if the "codesign" utility identified that as
a corrupted file and therefore refused to sign the application.

I also found this ticket which seems to point out the very same issue, although for a different reason: https://core.tcl-lang.org/tcl/tktview/113be1991e7262479a18

So it seems all of this is related to the support of zipfs in tcl, so I'll
try to rebuild on macOS turning it off, and I'll see if it solves the
issue.

Thanks again!
--
Eric
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Eric Brunel <eric.brunel@pragmadev.invalid.com> wrote:

I did check my initial hypothesis by running the command "unzip -l libtcl9.0.dylib" in a terminal, and it does seem the zipped contents of the tcl libray is indeed appended to the dynamic library file, as the command issues a warning "1937924 extra bytes at beginning or within zipfile", but

This is likely the cause. Appending extra data to a shared object file
is unusual enough (and, sadly, likely used by malware often enough)
that "scans for unusual things" for code signing purposes might include
"look for extra data appended to binary files" to use as a flag to
"reject" signing the batch of code.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On Tue, 2 Jun 2026 17:55:09 -0000 (UTC), Rich wrote:

Eric Brunel <eric.brunel@pragmadev.invalid.com> wrote:

I did check my initial hypothesis by running the command "unzip -l
libtcl9.0.dylib" in a terminal, and it does seem the zipped contents of
the tcl libray is indeed appended to the dynamic library file, as the
command issues a warning "1937924 extra bytes at beginning or within
zipfile", but

This is likely the cause. Appending extra data to a shared object file
is unusual enough (and, sadly, likely used by malware often enough) that "scans for unusual things" for code signing purposes might include "look
for extra data appended to binary files" to use as a flag to "reject"
signing the batch of code.

Thanks for your answer. And it was indeed the culprit: I rebuilt tcl & tk passing the option --disable-zipfs to the configure script, so the
libraries were built without the appended zip-file, and now everything's working, the "codesign" utility accepted to sign my application.

Considering how macOS handles applications, I find it a bit weird that
having that zip-file appended to the library is the default behavior: applications bundles being directories on macOS, there doesn't seem to be
any reason to do things this way. But well, I guess it is for consistency
with other platforms.

Anyway, thanks again!
--
Eric
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

Am 03.06.2026 um 11:00 schrieb Eric Brunel:

On Tue, 2 Jun 2026 17:55:09 -0000 (UTC), Rich wrote:

Eric Brunel <eric.brunel@pragmadev.invalid.com> wrote:

I did check my initial hypothesis by running the command "unzip -l
libtcl9.0.dylib" in a terminal, and it does seem the zipped contents of
the tcl libray is indeed appended to the dynamic library file, as the
command issues a warning "1937924 extra bytes at beginning or within
zipfile", but

This is likely the cause. Appending extra data to a shared object file
is unusual enough (and, sadly, likely used by malware often enough) that
"scans for unusual things" for code signing purposes might include "look
for extra data appended to binary files" to use as a flag to "reject"
signing the batch of code.

Thanks for your answer. And it was indeed the culprit: I rebuilt tcl & tk passing the option --disable-zipfs to the configure script, so the
libraries were built without the appended zip-file, and now everything's working, the "codesign" utility accepted to sign my application.

Considering how macOS handles applications, I find it a bit weird that
having that zip-file appended to the library is the default behavior: applications bundles being directories on macOS, there doesn't seem to be
any reason to do things this way. But well, I guess it is for consistency with other platforms.

Anyway, thanks again!

Eric,
great that it works!
Please submit a Tcl ticket, if you think it would be better the other
way. I am sure, the configure machinery has many platform dependent
points and this will be possible for sure...

Thanks,
Harald
--- Synchronet 3.22a-Linux NewsLink 1.2