Menu
▾
▴
tcl-core — Tcl Core Team discussions about Tcl development
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(19) |
Jul
(96) |
Aug
(144) |
Sep
(222) |
Oct
(496) |
Nov
(171) |
Dec
(6) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(4) |
Feb
(4) |
Mar
(9) |
Apr
(4) |
May
(12) |
Jun
(6) |
Jul
|
Aug
|
Sep
(1) |
Oct
(2) |
Nov
|
Dec
|
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(52) |
Aug
(47) |
Sep
(47) |
Oct
(95) |
Nov
(56) |
Dec
(34) |
| 2003 |
Jan
(99) |
Feb
(116) |
Mar
(125) |
Apr
(99) |
May
(123) |
Jun
(69) |
Jul
(110) |
Aug
(130) |
Sep
(289) |
Oct
(211) |
Nov
(98) |
Dec
(140) |
| 2004 |
Jan
(85) |
Feb
(87) |
Mar
(342) |
Apr
(125) |
May
(101) |
Jun
(60) |
Jul
(151) |
Aug
(118) |
Sep
(162) |
Oct
(117) |
Nov
(125) |
Dec
(95) |
| 2005 |
Jan
(141) |
Feb
(54) |
Mar
(79) |
Apr
(83) |
May
(74) |
Jun
(125) |
Jul
(63) |
Aug
(89) |
Sep
(130) |
Oct
(89) |
Nov
(34) |
Dec
(39) |
| 2006 |
Jan
(98) |
Feb
(62) |
Mar
(56) |
Apr
(94) |
May
(169) |
Jun
(41) |
Jul
(34) |
Aug
(35) |
Sep
(132) |
Oct
(722) |
Nov
(381) |
Dec
(36) |
| 2007 |
Jan
(34) |
Feb
(174) |
Mar
(15) |
Apr
(35) |
May
(74) |
Jun
(15) |
Jul
(8) |
Aug
(18) |
Sep
(39) |
Oct
(125) |
Nov
(89) |
Dec
(129) |
| 2008 |
Jan
(176) |
Feb
(91) |
Mar
(69) |
Apr
(178) |
May
(310) |
Jun
(434) |
Jul
(171) |
Aug
(73) |
Sep
(187) |
Oct
(132) |
Nov
(259) |
Dec
(292) |
| 2009 |
Jan
(27) |
Feb
(54) |
Mar
(35) |
Apr
(54) |
May
(93) |
Jun
(10) |
Jul
(36) |
Aug
(36) |
Sep
(93) |
Oct
(52) |
Nov
(45) |
Dec
(74) |
| 2010 |
Jan
(20) |
Feb
(120) |
Mar
(165) |
Apr
(101) |
May
(56) |
Jun
(12) |
Jul
(73) |
Aug
(306) |
Sep
(154) |
Oct
(82) |
Nov
(63) |
Dec
(42) |
| 2011 |
Jan
(176) |
Feb
(86) |
Mar
(199) |
Apr
(86) |
May
(237) |
Jun
(50) |
Jul
(26) |
Aug
(56) |
Sep
(42) |
Oct
(62) |
Nov
(62) |
Dec
(52) |
| 2012 |
Jan
(35) |
Feb
(33) |
Mar
(128) |
Apr
(152) |
May
(133) |
Jun
(21) |
Jul
(74) |
Aug
(423) |
Sep
(165) |
Oct
(129) |
Nov
(387) |
Dec
(276) |
| 2013 |
Jan
(105) |
Feb
(30) |
Mar
(130) |
Apr
(42) |
May
(60) |
Jun
(79) |
Jul
(101) |
Aug
(46) |
Sep
(81) |
Oct
(14) |
Nov
(43) |
Dec
(4) |
| 2014 |
Jan
(25) |
Feb
(32) |
Mar
(30) |
Apr
(80) |
May
(42) |
Jun
(23) |
Jul
(68) |
Aug
(127) |
Sep
(112) |
Oct
(72) |
Nov
(29) |
Dec
(69) |
| 2015 |
Jan
(35) |
Feb
(49) |
Mar
(95) |
Apr
(10) |
May
(70) |
Jun
(64) |
Jul
(93) |
Aug
(85) |
Sep
(43) |
Oct
(38) |
Nov
(124) |
Dec
(29) |
| 2016 |
Jan
(253) |
Feb
(181) |
Mar
(132) |
Apr
(419) |
May
(68) |
Jun
(90) |
Jul
(52) |
Aug
(142) |
Sep
(131) |
Oct
(80) |
Nov
(84) |
Dec
(192) |
| 2017 |
Jan
(329) |
Feb
(842) |
Mar
(248) |
Apr
(85) |
May
(247) |
Jun
(186) |
Jul
(37) |
Aug
(73) |
Sep
(98) |
Oct
(108) |
Nov
(143) |
Dec
(143) |
| 2018 |
Jan
(155) |
Feb
(139) |
Mar
(72) |
Apr
(112) |
May
(82) |
Jun
(119) |
Jul
(24) |
Aug
(33) |
Sep
(179) |
Oct
(295) |
Nov
(111) |
Dec
(34) |
| 2019 |
Jan
(20) |
Feb
(29) |
Mar
(49) |
Apr
(89) |
May
(185) |
Jun
(131) |
Jul
(9) |
Aug
(59) |
Sep
(30) |
Oct
(44) |
Nov
(118) |
Dec
(53) |
| 2020 |
Jan
(70) |
Feb
(108) |
Mar
(50) |
Apr
(9) |
May
(70) |
Jun
(24) |
Jul
(103) |
Aug
(82) |
Sep
(132) |
Oct
(119) |
Nov
(174) |
Dec
(169) |
| 2021 |
Jan
(75) |
Feb
(51) |
Mar
(76) |
Apr
(73) |
May
(53) |
Jun
(120) |
Jul
(114) |
Aug
(73) |
Sep
(70) |
Oct
(18) |
Nov
(26) |
Dec
|
| 2022 |
Jan
(26) |
Feb
(63) |
Mar
(64) |
Apr
(64) |
May
(48) |
Jun
(74) |
Jul
(129) |
Aug
(106) |
Sep
(238) |
Oct
(169) |
Nov
(149) |
Dec
(111) |
| 2023 |
Jan
(110) |
Feb
(47) |
Mar
(82) |
Apr
(106) |
May
(168) |
Jun
(101) |
Jul
(155) |
Aug
(35) |
Sep
(51) |
Oct
(55) |
Nov
(134) |
Dec
(202) |
| 2024 |
Jan
(103) |
Feb
(129) |
Mar
(154) |
Apr
(89) |
May
(60) |
Jun
(162) |
Jul
(201) |
Aug
(61) |
Sep
(167) |
Oct
(111) |
Nov
(133) |
Dec
(141) |
| 2025 |
Jan
(122) |
Feb
(88) |
Mar
(106) |
Apr
(113) |
May
(203) |
Jun
(185) |
Jul
(124) |
Aug
(140) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: elns <el...@xs...> - 2024-09-10 07:29:15
|
On 9/10/24 02:24, Francois Vogel wrote: > > In the meantime I see that Don has added a > > *** POTENTIAL INCOMPATIBILITY *** > > line in the changes file of core-8-6-15-rc, which should close the case I think. > OK, regarding the notification. However, when looking at the change to which this applies, I see the following description: 2024-03-15 (bug)[47d4f2] Throw focus events if marked by X11 as inferior (leunissen) I'm sorry to say (but I hope no offense): this description is both incorrect and non-sensical. My proposal: 2024-03-15 (bug)[47d4f2] Invoke binding scripts for events with detail field NotifyInferior (leunissen, vogel) Best regards, Erik. __ > Regards, > > Francois > |
|
From: Francois V. <fvo...@fr...> - 2024-09-10 00:25:12
|
Le 09/09/2024 à 23:05, Erik Leunissen a écrit : > On 9/9/24 22:19 , Francois Vogel wrote: >> >>> Nevertheless, Csaba Nemethi made adaptations to one of his packages >>> because of this fix. >> I would be interested to know what had to be adapted here (especially >> considering that Csaba tested the changes before we merged). > > Please see the 5th entry in this changes file: > > What is new in Tablelist 7.3? Found! https://core.tcl-lang.org/tklib/info/8eee6fc51de614e3 Unfortunately this is a large commit with all the changes from Tablelist 7.2 to 7.3, not just the adaptation of Tablelist to the Tk change we're discussing now. I think the relevant part of this commit is what changed in lines 911-918 of modules/tablelist/scripts/tablelistBind.tcl, along with two lines removal in modules/tablelist/scripts/tablelistWidget.tcl. Perhaps the only relevant part is the check on if {"%d" ne "NotifyInferior"} {... In the meantime I see that Don has added a *** POTENTIAL INCOMPATIBILITY *** line in the changes file of core-8-6-15-rc, which should close the case I think. Regards, Francois |
|
From: Erik L. <el...@xs...> - 2024-09-09 21:05:11
|
On 9/9/24 22:19 , Francois Vogel wrote:
>
>> Nevertheless, Csaba Nemethi made adaptations to one of his packages
>> because of this fix.
> I would be interested to know what had to be adapted here (especially
> considering that Csaba tested the changes before we merged).
Please see the 5th entry in this changes file:
What is new in Tablelist 7.3?
-----------------------------
1. Added the virtual events <<TablelistXViewChanged>> and
<<TablelistYViewChanged>>, generated when the horizontal/vertical
view in the tablelist widget's window changes.
2. Significantly improved the performance of "cellconfigure ... -text"
(thanks to Paul Obermeier for his valuable contribution).
3. Guarded against the case that an embedded image was deleted (thanks
to Paul Obermeier for his proposal).
4. Made sure that the handling of the <TouchpadScroll> event won't
pollute the global namespace (thanks to Rolf Ade for drawing my
attention to this issue).
5. Adapted the handling of the <FocusIn> and <FocusOut> events to recent
changes made in Tk related to these events and the detail field
"NotifyInferior".
> Regards,
>
> Francois
>
> |
|
From: Francois V. <fvo...@fr...> - 2024-09-09 20:20:11
|
Le 09/09/2024 à 09:53, elns a écrit : > On 9/9/24 09:38, Harald Oehlmann wrote: >> I did not get where the issue is. We have a good fix. >> Is the mentioning in the changes file ok? > I wouldn't do anything before knowing the opinion of Francois, in this > case. The changes introduced by the ticket in question are the following (consolidated) ones: https://core.tcl-lang.org/tk/vdiff?from=71f581f3e731e7c2&to=3cc37438bb772ef2 They modify the behavior of the binding mechanism by no longer discarding <Enter> or <Leave> events having LeaveNotify or NotifyInferior detail field. Tk did this since the beginning of time, or almost, for an obscure reason linked to megawidgets that I finally have dug out (see discussion in the ticket) here: https://core.tcl-lang.org/tk/artifact/b3340eb2?ln=2079,2085 And this old behavior was undocumented. So the change made by this ticket is a rather obscure thing, and the ancestral behavior of Tk probably never found a use case for it. But to be on the safe side one can add a *** POTENTIAL INCOMPATIBILITY *** line in the changes file. Finally, if anyone is not comfortable in having this change in a patch release, then just revert it and keep it in trunk (9.0) only, that's also possible. Note however that this was discussed in the ticket, that we first decided to merge in trunk only (with Csaba's positive tests with Tablelist, Mentry and Scrollutil packages). Then Erik brought reasons to include the fix in core-8-6-branch, which was done. > Nevertheless, Csaba Nemethi made adaptations to one of his packages > because of this fix. I would be interested to know what had to be adapted here (especially considering that Csaba tested the changes before we merged). Regards, Francois |
|
From: Harald O. <har...@el...> - 2024-09-09 08:17:37
|
Am 06.09.2024 um 20:32 schrieb Donald G Porter via Tcl-Core: > > Now available at > > https://sourceforge.net/projects/tcl/files/Tcl/8.6.15/ > > are RC0 candidate source code distribution pre-releases of Tcl and Tk > 8.6.15. Hi Don, I appreciate the release candidate. Here are the results on archaic MS-VC 6 compiler. We know, that this is old any low priority. Jan said, that we can not make sqlite compile any more. Nevertheless, here are the results. A lot of compiler warnings (and errors for sqlite) are listed below. Test suite compared to 8.6.14: all clean TDBC: in the test case, the DLL does not load. This is ok for mysql, postgres, but odbc should always load. Nevertheless, a "package require tdbc::odbc" succeeds when installed. The test error is: Test file error: couldn't load library "C:/test/tcl8.6.15rc0/tcl8.6.15/pkgs/tdbc1.1.9/win/Release/tdbc119.dll": this library or a dependent library could not be found in library path -> There is the "t" missing within the path. It should be tdbc119t.dll instead tdbc119.dll. All other binary modules have the same issue (mysql, postgresql). HTMLHELP: clean Practical test with complex application: ok Thank you for all, Harald --COMPILE ERRORS-- TCL C:\test\tcl8.6.15rc0\tcl8.6.15\win\..\generic\tclProc.c(2275) : warning C4550: expression evaluates to a function which is missing an argument list TK C:\test\tcl8.6.15rc0\tk8.6.15\win\..\generic\tkCanvas.c(4241) : warning C4022: 'memcpy' : pointer mismatch for actual parameter 1 C:\test\tcl8.6.15rc0\tk8.6.15\win\..\win\tkWinFont.c(1499) : warning C4761: integral size mismatch in argument; conversion supplied C:\test\tcl8.6.15rc0\tk8.6.15\win\..\win\tkWinFont.c(1521) : warning C4761: integral size mismatch in argument; conversion supplied C:\test\tcl8.6.15rc0\tk8.6.15\win\..\generic\ttk\ttkFrame.c(175) : warning C4005: 'DEFAULT_BORDERWIDTH' : macro redefinition C:\test\tcl8.6.15rc0\tk8.6.15\win\..\generic\ttk\ttkClassicTheme.c(0) : see previous definition of 'DEFAULT_BORDERWIDTH' SQLITE C:\test\tcl8.6.15rc0\tcl8.6.15\pkgs\sqlite3.45.3\win\..\generic\../compat/sqlite3/sqlite3.c(35143) : error C2059: syntax error : 'bad suffix on number' C:\test\tcl8.6.15rc0\tcl8.6.15\pkgs\sqlite3.45.3\win\..\generic\../compat/sqlite3/sqlite3.c(35143) : error C2146: syntax error : missing ';' before identifier 'L' C:\test\tcl8.6.15rc0\tcl8.6.15\pkgs\sqlite3.45.3\win\..\generic\../compat/sqlite3/sqlite3.c(35143) : error C2065: 'L' : undeclared identifier C:\test\tcl8.6.15rc0\tcl8.6.15\pkgs\sqlite3.45.3\win\..\generic\../compat/sqlite3/sqlite3.c(35147) : error C2059: syntax error : 'bad suffix on number' C:\test\tcl8.6.15rc0\tcl8.6.15\pkgs\sqlite3.45.3\win\..\generic\../compat/sqlite3/sqlite3.c(35147) : error C2146: syntax error : missing ';' before identifier 'L' C:\test\tcl8.6.15rc0\tcl8.6.15\pkgs\sqlite3.45.3\win\..\generic\../compat/sqlite3/sqlite3.c(35334) : warning C4056: overflow in floating-point constant arithmetic C:\test\tcl8.6.15rc0\tcl8.6.15\pkgs\sqlite3.45.3\win\..\generic\../compat/sqlite3/sqlite3.c(35345) : error C2059: syntax error : 'bad suffix on number' C:\test\tcl8.6.15rc0\tcl8.6.15\pkgs\sqlite3.45.3\win\..\generic\../compat/sqlite3/sqlite3.c(35345) : error C2146: syntax error : missing ')' before identifier 'L' C:\test\tcl8.6.15rc0\tcl8.6.15\pkgs\sqlite3.45.3\win\..\generic\../compat/sqlite3/sqlite3.c(35345) : error C2059: syntax error : ')' C:\test\tcl8.6.15rc0\tcl8.6.15\pkgs\sqlite3.45.3\win\..\generic\../compat/sqlite3/sqlite3.c(35345) : error C2143: syntax error : missing ';' before '{' C:\test\tcl8.6.15rc0\tcl8.6.15\pkgs\sqlite3.45.3\win\..\generic\../compat/sqlite3/sqlite3.c(35376) : warning C4056: overflow in floating-point constant arithmetic C:\test\tcl8.6.15rc0\tcl8.6.15\pkgs\sqlite3.45.3\win\..\generic\../compat/sqlite3/sqlite3.c(35715) : error C2059: syntax error : 'bad suffix on number' C:\test\tcl8.6.15rc0\tcl8.6.15\pkgs\sqlite3.45.3\win\..\generic\../compat/sqlite3/sqlite3.c(35715) : error C2146: syntax error : missing ')' before identifier 'L' C:\test\tcl8.6.15rc0\tcl8.6.15\pkgs\sqlite3.45.3\win\..\generic\../compat/sqlite3/sqlite3.c(35715) : error C2059: syntax error : ')' C:\test\tcl8.6.15rc0\tcl8.6.15\pkgs\sqlite3.45.3\win\..\generic\../compat/sqlite3/sqlite3.c(65536) : warning C4049: compiler limit : terminating line number emission C:\test\tcl8.6.15rc0\tcl8.6.15\pkgs\sqlite3.45.3\win\..\generic\../compat/sqlite3/sqlite3.c(89719) : warning C4550: expression evaluates to a function which is missing an argument list C:\test\tcl8.6.15rc0\tcl8.6.15\pkgs\sqlite3.45.3\win\..\generic\../compat/sqlite3/sqlite3.c(89729) : warning C4550: expression evaluates to a function which is missing an argument list C:\test\tcl8.6.15rc0\tcl8.6.15\pkgs\sqlite3.45.3\win\..\generic\../compat/sqlite3/sqlite3.c(89740) : warning C4550: expression evaluates to a function which is missing an argument list C:\test\tcl8.6.15rc0\tcl8.6.15\pkgs\sqlite3.45.3\win\..\generic\../compat/sqlite3/sqlite3.c(89744) : warning C4550: expression evaluates to a function which is missing an argument list C:\test\tcl8.6.15rc0\tcl8.6.15\pkgs\sqlite3.45.3\win\..\generic\../compat/sqlite3/sqlite3.c(103943) : warning C4550: expression evaluates to a function which is missing an argument list C:\test\tcl8.6.15rc0\tcl8.6.15\pkgs\sqlite3.45.3\win\..\generic\../compat/sqlite3/sqlite3.c(103945) : warning C4550: expression evaluates to a function which is missing an argument list C:\test\tcl8.6.15rc0\tcl8.6.15\pkgs\sqlite3.45.3\win\..\generic\../compat/sqlite3/sqlite3.c(103947) : warning C4550: expression evaluates to a function which is missing an argument list C:\test\tcl8.6.15rc0\tcl8.6.15\pkgs\sqlite3.45.3\win\..\generic\../compat/sqlite3/sqlite3.c(130040) : error C2059: syntax error : 'bad suffix on number' C:\test\tcl8.6.15rc0\tcl8.6.15\pkgs\sqlite3.45.3\win\..\generic\../compat/sqlite3/sqlite3.c(130040) : error C2146: syntax error : missing ')' before identifier 'L' C:\test\tcl8.6.15rc0\tcl8.6.15\pkgs\sqlite3.45.3\win\..\generic\../compat/sqlite3/sqlite3.c(130040) : error C2059: syntax error : 'bad suffix on number' C:\test\tcl8.6.15rc0\tcl8.6.15\pkgs\sqlite3.45.3\win\..\generic\../compat/sqlite3/sqlite3.c(130040) : error C2146: syntax error : missing ';' before identifier 'L' C:\test\tcl8.6.15rc0\tcl8.6.15\pkgs\sqlite3.45.3\win\..\generic\../compat/sqlite3/sqlite3.c(130040) : error C2059: syntax error : ')' C:\test\tcl8.6.15rc0\tcl8.6.15\pkgs\sqlite3.45.3\win\..\generic\../compat/sqlite3/sqlite3.c(130040) : error C2143: syntax error : missing ';' before '{' C:\test\tcl8.6.15rc0\tcl8.6.15\pkgs\sqlite3.45.3\win\..\generic\../compat/sqlite3/sqlite3.c(130046) : error C2181: illegal else without matching if C:\test\tcl8.6.15rc0\tcl8.6.15\pkgs\sqlite3.45.3\win\..\generic\../compat/sqlite3/sqlite3.c(130058) : error C2059: syntax error : 'bad suffix on number' C:\test\tcl8.6.15rc0\tcl8.6.15\pkgs\sqlite3.45.3\win\..\generic\../compat/sqlite3/sqlite3.c(130058) : error C2146: syntax error : missing ')' before identifier 'L' C:\test\tcl8.6.15rc0\tcl8.6.15\pkgs\sqlite3.45.3\win\..\generic\../compat/sqlite3/sqlite3.c(130058) : error C2059: syntax error : 'bad suffix on number' C:\test\tcl8.6.15rc0\tcl8.6.15\pkgs\sqlite3.45.3\win\..\generic\../compat/sqlite3/sqlite3.c(130058) : error C2146: syntax error : missing ';' before identifier 'L' C:\test\tcl8.6.15rc0\tcl8.6.15\pkgs\sqlite3.45.3\win\..\generic\../compat/sqlite3/sqlite3.c(130058) : error C2059: syntax error : ')' C:\test\tcl8.6.15rc0\tcl8.6.15\pkgs\sqlite3.45.3\win\..\generic\../compat/sqlite3/sqlite3.c(130058) : error C2143: syntax error : missing ';' before '{' C:\test\tcl8.6.15rc0\tcl8.6.15\pkgs\sqlite3.45.3\win\..\generic\../compat/sqlite3/sqlite3.c(130062) : error C2181: illegal else without matching if TDBCODBC C:\test\tcl8.6.15rc0\tcl8.6.15\pkgs\tdbcodbc1.1.9\win\..\generic\tdbcodbc.c(2720) : warning C4761: integral size mismatch in argument; conversion supplied C:\test\tcl8.6.15rc0\tcl8.6.15\pkgs\tdbcodbc1.1.9\win\..\generic\tdbcodbc.c(4050) : warning C4761: integral size mismatch in argument; conversion supplied C:\test\tcl8.6.15rc0\tcl8.6.15\pkgs\tdbcodbc1.1.9\win\..\generic\tdbcodbc.c(4095) : warning C4761: integral size mismatch in argument; conversion supplied C:\test\tcl8.6.15rc0\tcl8.6.15\pkgs\tdbcodbc1.1.9\win\..\generic\tdbcodbc.c(1474) : warning C4761: integral size mismatch in argument; conversion supplied C:\test\tcl8.6.15rc0\tcl8.6.15\pkgs\tdbcodbc1.1.9\win\..\generic\tdbcodbc.c(4530) : warning C4761: integral size mismatch in argument; conversion supplied C:\test\tcl8.6.15rc0\tcl8.6.15\pkgs\tdbcodbc1.1.9\win\..\generic\tdbcodbc.c(4550) : warning C4761: integral size mismatch in argument; conversion supplied C:\test\tcl8.6.15rc0\tcl8.6.15\pkgs\tdbcodbc1.1.9\win\..\generic\tdbcodbc.c(4588) : warning C4761: integral size mismatch in argument; conversion supplied C:\test\tcl8.6.15rc0\tcl8.6.15\pkgs\tdbcodbc1.1.9\win\..\generic\tdbcodbc.c(4646) : warning C4761: integral size mismatch in argument; conversion supplied C:\test\tcl8.6.15rc0\tcl8.6.15\pkgs\tdbcodbc1.1.9\win\..\generic\tdbcodbc.c(5297) : warning C4761: integral size mismatch in argument; conversion supplied C:\test\tcl8.6.15rc0\tcl8.6.15\pkgs\tdbcodbc1.1.9\win\..\generic\tdbcodbc.c(5489) : warning C4761: integral size mismatch in argument; conversion supplied |
|
From: elns <el...@xs...> - 2024-09-09 07:53:32
|
On 9/9/24 09:38, Harald Oehlmann wrote: > Erik, > (sorry, to have used the French spelling and not the nordic one) > I did not get where the issue is. We have a good fix. > Is the mentioning in the changes file ok? I wouldn't do anything before knowing the opinion of Francois, in this case. Erik. -- > Other improvements to propose? > > Your analysis, bugfixes and texts are always great and detailed, but need a long time to read. And > there are 5 linked tickets. I am so happy, that this stuff is addressed and fixed and at least > Francois and you still understand what is happening. Events (cross platform) are so difficult. > You remember perhaps my intention to let a frame shrink to 1x1, if the last child is unpacked -> did > not work, we have implemented a workaround notification event.... > > Anyway, thanks for all, > Harald > > Am 09.09.2024 um 09:00 schrieb elns: >> On 9/9/24 08:31, Harald Oehlmann wrote: >>> Dear Eric, >>> thank you for pointing this out. The ticket is: >>> https://core.tcl-lang.org/tk/info/47d4f29159 >>> Perhaps, Francois may give a comment on this. >>> I am ready to help. >>> What user documentation should be changed ? >>> >> >> Oh, the problem isn't the documentation. No need to change anything. >> >> I just wanted to point out the argument that a notification about a potential incompatibility may >> NOT be necessary because the behaviour that the fix corrects wasn't documented in the first place. >> >> Erik. >> __ >> >> >>> Thank you for all, >>> Harald >>> >>> Am 07.09.2024 um 18:25 schrieb elns: >>>> On 9/7/24 17:42, elns wrote: >>>>> W.r.t. the upcoming releases 8.6.15 and 9.0.0: >>>>> >>>>> These releases are the first ones that include the fix for Tk ticket #47d4f29159. >>>>> >>>>> That fix addressed an unfortunate policy decision rather than an inadvertency. >>>> >>>> Maybe relevant: that policy decision wasn't mentioned in any user documentation. >>>> So, users couldn't have relied on that. Nevertheless, Csaba Nemethi made adaptations to one of >>>> his packages because of this fix. >>>> >>>>> So there is a slim chance of surprise here. Shouldn't users of the new releases >>>>> be made aware of the potential incompatibility introduced by that fix ? >>>>> >>>>> Best regards, >>>>> Erik Leunissen. >>>>> -- >>>> >>> >>> >>> >>> _______________________________________________ >>> Tcl-Core mailing list >>> Tcl...@li... >>> https://lists.sourceforge.net/lists/listinfo/tcl-core >> >> >> >> _______________________________________________ >> Tcl-Core mailing list >> Tcl...@li... >> https://lists.sourceforge.net/lists/listinfo/tcl-core > > > > _______________________________________________ > Tcl-Core mailing list > Tcl...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-core |
|
From: Harald O. <har...@el...> - 2024-09-09 07:39:19
|
Erik, (sorry, to have used the French spelling and not the nordic one) I did not get where the issue is. We have a good fix. Is the mentioning in the changes file ok? Other improvements to propose? Your analysis, bugfixes and texts are always great and detailed, but need a long time to read. And there are 5 linked tickets. I am so happy, that this stuff is addressed and fixed and at least Francois and you still understand what is happening. Events (cross platform) are so difficult. You remember perhaps my intention to let a frame shrink to 1x1, if the last child is unpacked -> did not work, we have implemented a workaround notification event.... Anyway, thanks for all, Harald Am 09.09.2024 um 09:00 schrieb elns: > On 9/9/24 08:31, Harald Oehlmann wrote: >> Dear Eric, >> thank you for pointing this out. The ticket is: >> https://core.tcl-lang.org/tk/info/47d4f29159 >> Perhaps, Francois may give a comment on this. >> I am ready to help. >> What user documentation should be changed ? >> > > Oh, the problem isn't the documentation. No need to change anything. > > I just wanted to point out the argument that a notification about a > potential incompatibility may NOT be necessary because the behaviour > that the fix corrects wasn't documented in the first place. > > Erik. > __ > > >> Thank you for all, >> Harald >> >> Am 07.09.2024 um 18:25 schrieb elns: >>> On 9/7/24 17:42, elns wrote: >>>> W.r.t. the upcoming releases 8.6.15 and 9.0.0: >>>> >>>> These releases are the first ones that include the fix for Tk ticket >>>> #47d4f29159. >>>> >>>> That fix addressed an unfortunate policy decision rather than an >>>> inadvertency. >>> >>> Maybe relevant: that policy decision wasn't mentioned in any user >>> documentation. >>> So, users couldn't have relied on that. Nevertheless, Csaba Nemethi >>> made adaptations to one of his packages because of this fix. >>> >>>> So there is a slim chance of surprise here. Shouldn't users of the >>>> new releases >>>> be made aware of the potential incompatibility introduced by that fix ? >>>> >>>> Best regards, >>>> Erik Leunissen. >>>> -- >>> >> >> >> >> _______________________________________________ >> Tcl-Core mailing list >> Tcl...@li... >> https://lists.sourceforge.net/lists/listinfo/tcl-core > > > > _______________________________________________ > Tcl-Core mailing list > Tcl...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-core |
|
From: Pietro C. <ga...@ga...> - 2024-09-09 07:31:19
|
On Sep 06 2024, 18:32 +0000, Donald G Porter via Tcl-Core <tcl...@li...> wrote: > >Now available at > >https://sourceforge.net/projects/tcl/files/Tcl/8.6.15/ > >are RC0 candidate source code distribution pre-releases of Tcl and Tk 8.6.15. Looks good on FreeBSD, thanks! -- Pietro Cerutti I have pledged to give 10% of income to effective charities and invite you to join me - https://givingwhatwecan.org |
|
From: Steve L. <st...@di...> - 2024-09-09 07:19:39
|
A reminder that the September Tcl virtual meetup will be held Tuesday September 10th 2024 at [clock format 1725962400] - Tuesday 3am US West, 5am US Central, 6am US East, 10am UTC, 11am UK, 12pm Western Europe, 3:30pm India, 6pm Australia West / Singapore / China, 7pm Japan, 8pm Australia East, 10pm New Zealand Details (including how to connect) are available via https://wiki.tcl-lang.org/page/Monthly+Virtual+Meetup -- Steve |
|
From: elns <el...@xs...> - 2024-09-09 07:00:29
|
On 9/9/24 08:31, Harald Oehlmann wrote: > Dear Eric, > thank you for pointing this out. The ticket is: > https://core.tcl-lang.org/tk/info/47d4f29159 > Perhaps, Francois may give a comment on this. > I am ready to help. > What user documentation should be changed ? > Oh, the problem isn't the documentation. No need to change anything. I just wanted to point out the argument that a notification about a potential incompatibility may NOT be necessary because the behaviour that the fix corrects wasn't documented in the first place. Erik. __ > Thank you for all, > Harald > > Am 07.09.2024 um 18:25 schrieb elns: >> On 9/7/24 17:42, elns wrote: >>> W.r.t. the upcoming releases 8.6.15 and 9.0.0: >>> >>> These releases are the first ones that include the fix for Tk ticket #47d4f29159. >>> >>> That fix addressed an unfortunate policy decision rather than an inadvertency. >> >> Maybe relevant: that policy decision wasn't mentioned in any user documentation. >> So, users couldn't have relied on that. Nevertheless, Csaba Nemethi made adaptations to one of his >> packages because of this fix. >> >>> So there is a slim chance of surprise here. Shouldn't users of the new releases >>> be made aware of the potential incompatibility introduced by that fix ? >>> >>> Best regards, >>> Erik Leunissen. >>> -- >> > > > > _______________________________________________ > Tcl-Core mailing list > Tcl...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-core |
|
From: Harald O. <har...@el...> - 2024-09-09 06:31:27
|
Dear Eric, thank you for pointing this out. The ticket is: https://core.tcl-lang.org/tk/info/47d4f29159 Perhaps, Francois may give a comment on this. I am ready to help. What user documentation should be changed ? Thank you for all, Harald Am 07.09.2024 um 18:25 schrieb elns: > On 9/7/24 17:42, elns wrote: >> W.r.t. the upcoming releases 8.6.15 and 9.0.0: >> >> These releases are the first ones that include the fix for Tk ticket >> #47d4f29159. >> >> That fix addressed an unfortunate policy decision rather than an >> inadvertency. > > Maybe relevant: that policy decision wasn't mentioned in any user > documentation. > So, users couldn't have relied on that. Nevertheless, Csaba Nemethi made > adaptations to one of his packages because of this fix. > >> So there is a slim chance of surprise here. Shouldn't users of the new >> releases >> be made aware of the potential incompatibility introduced by that fix ? >> >> Best regards, >> Erik Leunissen. >> -- > |
|
From: Paul O. <pa...@po...> - 2024-09-08 18:32:26
|
Hi Don, thanks for the new release candidate. Builds fine on my BAWT build environments using Windows, Linux, Mac, Raspi, RiscV. If a warning-free build is desired, take a look at the following warnings: Warnings Mac-M2 Sonoma gcc 15.0: ./generic/itclInfo.c:1710:7: warning: variable 'numElems' set but not used [-Wunused-but-set-variable] int numElems; ld: warning: -single_module is obsolete ld: warning: -s is obsolete ld: warning: ignoring duplicate libraries: '-ltdbcstub1.1.9' Warnings Windows11 VS2022 64-bit build: Messages in German mean: Conversion from size_t to int, possible data loss pkgs\tdbc1.1.9\win\..\generic\tdbcTokenize.c(123): warning C4267: "Funktion": Konvertierung von "size_t" nach "int", Datenverlust m”glich pkgs\tdbc1.1.9\win\..\generic\tdbcTokenize.c(150): warning C4267: "Funktion": Konvertierung von "size_t" nach "int", Datenverlust m”glich pkgs\tdbc1.1.9\win\..\generic\tdbcTokenize.c(159): warning C4267: "Funktion": Konvertierung von "size_t" nach "int", Datenverlust m”glich pkgs\tdbc1.1.9\win\..\generic\tdbcTokenize.c(167): warning C4267: "Funktion": Konvertierung von "size_t" nach "int", Datenverlust m”glich pkgs\tdbcodbc1.1.9\win\..\generic\tdbcodbc.c(888): warning C4267: "=": Konvertierung von "size_t" nach "int", Datenverlust m”glich pkgs\tdbcodbc1.1.9\win\..\generic\tdbcodbc.c(2655): warning C4267: "Funktion": Konvertierung von "size_t" nach "int", Datenverlust m”glich pkgs\tdbcodbc1.1.9\win\..\generic\tdbcodbc.c(2659): warning C4267: "Funktion": Konvertierung von "size_t" nach "int", Datenverlust m”glich pkgs\tdbcodbc1.1.9\win\..\generic\tdbcodbc.c(4006): warning C4267: "=": Konvertierung von "size_t" nach "int", Datenverlust m”glich pkgs\tdbcodbc1.1.9\win\..\generic\tdbcodbc.c(4701): warning C4267: "Funktion": Konvertierung von "size_t" nach "int", Datenverlust m”glich pkgs\tdbcodbc1.1.9\win\..\generic\tdbcodbc.c(5138): warning C4267: "Funktion": Konvertierung von "size_t" nach "int", Datenverlust m”glich pkgs\tdbcodbc1.1.9\win\..\generic\tdbcodbc.c(5440): warning C4267: "Funktion": Konvertierung von "size_t" nach "int", Datenverlust m”glich pkgs\tdbcodbc1.1.9\win\..\generic\tdbcodbc.c(5461): warning C4267: "Funktion": Konvertierung von "size_t" nach "int", Datenverlust m”glich Regards, Paul Am 06.09.2024 um 20:32 schrieb Donald G Porter via Tcl-Core: > > Now available at > > https://sourceforge.net/projects/tcl/files/Tcl/8.6.15/ > > are RC0 candidate source code distribution pre-releases of Tcl and Tk 8.6.15. > > This is the first of a sequence of candidate releases leading to the release of > Tcl/Tk 8.6.15. Testing of builds and operations on multiple platforms is invited. Open > tickets on any problems discovered, or raise the issue in a reply to this message. > > The Tcl pre-release includes pre-releases of the packages Thread 2.8.10, Itcl 4.3.0, > and TDBC* 1.1.9. The same level of vetting on them is also appreciated. > > Unless severe problems are discovered with these RCs, expect them to become the > Tcl/Tk 8.6.15 releases next week. > > Thank you for your contributions and assistance. > |
|
From: Francois V. <fvo...@fr...> - 2024-09-08 15:21:19
|
Le 07/09/2024 à 08:58, Francois Vogel a écrit : > So the question now is: what part of the code calls > TkrTextIndexForwBytes() with such a byteCount? Follow-up to : https://core.tcl-lang.org/tk/tktview/1871581951 Francois |
|
From: elns <el...@xs...> - 2024-09-07 16:26:11
|
On 9/7/24 17:42, elns wrote: > W.r.t. the upcoming releases 8.6.15 and 9.0.0: > > These releases are the first ones that include the fix for Tk ticket #47d4f29159. > > That fix addressed an unfortunate policy decision rather than an inadvertency. Maybe relevant: that policy decision wasn't mentioned in any user documentation. So, users couldn't have relied on that. Nevertheless, Csaba Nemethi made adaptations to one of his packages because of this fix. > So there is a slim chance of surprise here. Shouldn't users of the new releases > be made aware of the potential incompatibility introduced by that fix ? > > Best regards, > Erik Leunissen. > -- |
|
From: elns <el...@xs...> - 2024-09-07 15:42:31
|
W.r.t. the upcoming releases 8.6.15 and 9.0.0: These releases are the first ones that include the fix for Tk ticket #47d4f29159. That fix addressed an unfortunate policy decision rather than an inadvertency. So there is a slim chance of surprise here. Shouldn't users of the new releases be made aware of the potential incompatibility introduced by that fix ? Best regards, Erik Leunissen. -- |
|
From: Francois V. <fvo...@fr...> - 2024-09-07 06:58:42
|
Le 07/09/2024 à 00:31, Francois Vogel a écrit : > At this point, byteCount is... -1 !! Correction. That's what printf'ing byteCount says with %d. At this point, byteCount is 0xffffffff. So the question now is: what part of the code calls TkrTextIndexForwBytes() with such a byteCount? Francois |
|
From: Francois V. <fvo...@fr...> - 2024-09-06 22:31:21
|
Le 06/09/2024 à 22:15, Francois Vogel a écrit :
>
> However the assert triggers on macOS when configuring Tk with
> --enable-symbols=mem --disable-aqua and running textIndex.test _under
> xvfb_.
>
Some news:
- This is not always reproducible. Sometimes the assert triggers
sometimes not. But it's easy to get (happens ~50% of the runs).
- When the assert triggers during textIndex-19.12.2, string values of
indexPtr1 and indexPtr2 in TkTextIndexCountBytes() are 3.40 and 3.39
respectively. This is indeed not supposed to happen (one should have
TkTextIndexCompare(indexPtr1, indexPtr2) <= 0, i.e. ordered indices).
- The call to TkTextIndexCountBytes() that leads to the assert
triggering is in TkrTextIndexForwBytes() (tkTextIndex.c:3085). This line
reads:
assert(!rc || (int) TkTextIndexCountBytes(&index, dstPtr) == byteCount);
- At this point, the string values are index = 3.40 and dstPtr = 3.39.
dstPtr is computed the line just before by:
rc = TkBTreeMoveForward(dstPtr, byteCount);
At this point, byteCount is... -1 !!
This is not supposed to happen. Never. Because the case byteCount < 0 is
ruled out a bit before in that same function TkrTextIndexForwBytes() as
follows:
if (byteCount < 0) {
TkrTextIndexBackBytes(textPtr, srcPtr, -byteCount, dstPtr);
return 0;
}
This is very mysterious to me. Any idea?
Regards,
Francois
|
|
From: Francois V. <fvo...@fr...> - 2024-09-06 20:15:57
|
Le 06/09/2024 à 11:12, Jan Nijtmans a écrit : > Still, there appears to be something wrong in tkTextIndex.c, which > sometimes even shows on Windows: > <https://github.com/tcltk/tk/actions/runs/10733861191/job/29767962454> > Any idea? No. I can't reproduce on Windows, nor on Linux (even with PURIFY defined, mem, and valgrind). However the assert triggers on macOS when configuring Tk with --enable-symbols=mem --disable-aqua and running textIndex.test _under xvfb_. If you run the tests without xvfb the assert does not trigger. Running textIndex.test under xvfb and ASan (with CFLAGS='-DPURIFY -fsanitize=address -fsanitize=undefined' LDFLAGS='-fsanitize=address') does not reveal anything (at least during the test, but before the test there are undefined behavior warnings in tkConfig.c). Regards, Francois |
|
From: Donald G P. <don...@ni...> - 2024-09-06 18:47:44
|
Now available at https://sourceforge.net/projects/tcl/files/Tcl/8.6.15/ are RC0 candidate source code distribution pre-releases of Tcl and Tk 8.6.15. This is the first of a sequence of candidate releases leading to the release of Tcl/Tk 8.6.15. Testing of builds and operations on multiple platforms is invited. Open tickets on any problems discovered, or raise the issue in a reply to this message. The Tcl pre-release includes pre-releases of the packages Thread 2.8.10, Itcl 4.3.0, and TDBC* 1.1.9. The same level of vetting on them is also appreciated. Unless severe problems are discovered with these RCs, expect them to become the Tcl/Tk 8.6.15 releases next week. Thank you for your contributions and assistance. -- | Don Porter Applied and Computational Mathematics Division | | don...@ni... Information Technology Laboratory | | http://math.nist.gov/~DPorter/ NIST | |______________________________________________________________________| |
|
From: Jan N. <jan...@gm...> - 2024-09-06 09:12:18
|
Op wo 4 sep 2024 om 23:29 schreef Francois Vogel <fvo...@fr...>:
> BTW, with your assert change, the test suite triggers it a huge lot (for
> me on Windows). Did you run the test suite before committing this:
>
No, I didn't. I was simply lazy, letting GITHUB actions testing it for
me on all platforms. I brought back mac-build.yml as it was, since
textIndex-19.14 appears to be the only testcase broken by
the XQuartz bug. And the assert change was clearly a mistake ....
Still, there appears to be something wrong in tkTextIndex.c, which
sometimes even shows on Windows:
<https://github.com/tcltk/tk/actions/runs/10733861191/job/29767962454>
Any idea?
Hope this helps,
Jan Nijtmans
|
|
From: Francois V. <fvo...@fr...> - 2024-09-04 21:29:17
|
BTW, with your assert change, the test suite triggers it a huge lot (for me on Windows). Did you run the test suite before committing this: https://core.tcl-lang.org/tk/info/e27c4627670e0ec1 ? Le 04/09/2024 à 23:11, Francois Vogel a écrit : > Hi Jan, > > I see you changed the assert condition in the commit below. Maybe > you're right. I agree the code in TkTextIndexCountBytes() seems to > only require that the two indices arguments only need to be ordered > and the equality case seems to be handled, so that your change in the > assert should be okay, but: > > - How do you explain this assert triggered only for the macOS > --disable-aqua CI runner and not with any other platform runner, > whereas this assert is in generic code? > > - How come that this assert triggers today at CI but not yesterday? > > I cannot reproduce this assert triggering on Windows, and neither on > macOS with XQuartz (the same configuration as at CI!). Without being > comfortable answering the above questions and having an understanding > I wouldn't have changed anything in the code. I hope you can explain. > > > Regarding your quest for which tests triggers the BadValue error, I > can reproduce on the mac with XQuartz (don't you?): > > ---- textIndex-19.14 start > X Error of failed request: BadValue (integer parameter out of range > for operation) > Major opcode of failed request: 45 (X_OpenFont) > Value in failed request: 0xa000a7 > Serial number of failed request: 1364 > Current serial number in output stream: 1365 > > > Finally, no, I'm still interested by xcode builds. > > > Regards, > > Francois > > Le 04/09/2024 à 16:07, no...@tc... a écrit : >> Automated mail by fx, on behalf of no...@tc... >> >> Commit >> [e27c4627670e0ec1abfb6f31e791b081b20ef454753c6010c6c5b281d4834642] >> By jan.nijtmans >> For Tk (branch: revised_text) >> On 2024-09-04T14:07:00.429 >> Details >> https://core.tcl-lang.org/tk/info/e27c4627670e0ec1abfb6f31e791b081b20ef454753c6010c6c5b281d4834642 >> >> Description >> Is this assert correct? And we are (for now) only interested in >> --disable-aqua builds >> >> Changed Files >> 2 edited >> .github/workflows/mac-build.yml >> generic/tkTextIndex.c >> >> ------------------------------------------------------------ >> See Tcl/Tk development @ http://core.tcl-lang.org/ >> ------------------------------------------------------------ >> >> >> _______________________________________________ >> Tcl-Bugs mailing list >> Tcl...@li... >> https://lists.sourceforge.net/lists/listinfo/tcl-bugs > > > _______________________________________________ > Tcl-Core mailing list > Tcl...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-core |
|
From: Francois V. <fvo...@fr...> - 2024-09-04 21:11:54
|
Hi Jan, I see you changed the assert condition in the commit below. Maybe you're right. I agree the code in TkTextIndexCountBytes() seems to only require that the two indices arguments only need to be ordered and the equality case seems to be handled, so that your change in the assert should be okay, but: - How do you explain this assert triggered only for the macOS --disable-aqua CI runner and not with any other platform runner, whereas this assert is in generic code? - How come that this assert triggers today at CI but not yesterday? I cannot reproduce this assert triggering on Windows, and neither on macOS with XQuartz (the same configuration as at CI!). Without being comfortable answering the above questions and having an understanding I wouldn't have changed anything in the code. I hope you can explain. Regarding your quest for which tests triggers the BadValue error, I can reproduce on the mac with XQuartz (don't you?): ---- textIndex-19.14 start X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 45 (X_OpenFont) Value in failed request: 0xa000a7 Serial number of failed request: 1364 Current serial number in output stream: 1365 Finally, no, I'm still interested by xcode builds. Regards, Francois Le 04/09/2024 à 16:07, no...@tc... a écrit : > Automated mail by fx, on behalf of no...@tc... > > Commit [e27c4627670e0ec1abfb6f31e791b081b20ef454753c6010c6c5b281d4834642] > By jan.nijtmans > For Tk (branch: revised_text) > On 2024-09-04T14:07:00.429 > Details https://core.tcl-lang.org/tk/info/e27c4627670e0ec1abfb6f31e791b081b20ef454753c6010c6c5b281d4834642 > > Description > Is this assert correct? And we are (for now) only interested in > --disable-aqua builds > > Changed Files > 2 edited > .github/workflows/mac-build.yml > generic/tkTextIndex.c > > ------------------------------------------------------------ > See Tcl/Tk development @ http://core.tcl-lang.org/ > ------------------------------------------------------------ > > > _______________________________________________ > Tcl-Bugs mailing list > Tcl...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-bugs |
|
From: Jan N. <jan...@gm...> - 2024-09-04 08:02:16
|
Op di 3 sep 2024 om 20:14 schreef Jan Mercl <0x...@gm...>:
> tclWin32Dll.c:472:2: error: unknown register name '%eax' in asm
> 472 | "%eax", "%ebx", "%ecx", "%edx", "%esi", "%edi",
> "memory");
> | ^
> 1 error generated.
> make: *** [Makefile:758: tclWin32Dll.o] Error 1
>
The problem (still) here is the -DHAVE_CPUID=1 in the makefile.
If you change that (manually) to 0, that should be a functioning
workaround, since aarch64 doesn't support the __cpuid function.
Still some work to do.
Thanks!
Jan Nijtmans
|
|
From: Jan M. <0x...@gm...> - 2024-09-03 18:14:50
|
On Tue, Sep 3, 2024 at 6:34 PM Jan Nijtmans <jan...@gm...> wrote:
> Can you try
> ./configure --enable-64bit=aarch64
Thanks for your help. ./configure happily accepts that option:
jnml@pi64 CLANGARM64 ~/src/modernc.org/tk9.0/tcl9.0b3/win (dev)
$ ./configure --enable-64bit=aarch64
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.exe
checking for suffix of executables... .exe
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether the compiler supports GNU C... yes
checking whether gcc accepts -g... yes
checking for gcc option to enable C11 features... none needed
checking for inline... inline
checking for ar... ar
checking for ranlib... ranlib
checking for windres... windres
checking whether make sets $(MAKE)... yes
checking how to build libraries... shared
checking for stdio.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for strings.h... yes
checking for sys/stat.h... yes
checking for sys/types.h... yes
checking for unistd.h... yes
checking if 64bit support is requested... aarch64
checking for cygpath... cygpath -m
checking for wine... no
checking for cross-compile version of gcc... no
checking for Windows native path bug in windres... no
checking for mingw32 version of gcc... yes
checking for working -municode linker flag... yes
checking for working -fno-lto... yes
checking if the compiler understands -finput-charset... yes
checking for working --enable-auto-image-base... yes
checking compiler flags... using shared flags
Using ARM64 ARM64 mode
checking for SEH support in compiler... no
checking for EXCEPTION_DISPOSITION support in include files... yes
checking for stdbool.h... yes
checking for cast to union support... yes
checking for intptr_t... yes
checking for uintptr_t... yes
checking for tclsh... /mingw32/bin/tclsh86.exe
checking for zip... No zip found on PATH building minizip
checking for building with zipfs... yes
checking for FINDEX_INFO_LEVELS in winbase.h... yes
checking for intrinsics support in compiler... no
checking for wspiapi.h... yes
checking for FINDEX_INFO_LEVELS in winbase.h... (cached) yes
checking for build with symbols... no
checking how to run the C preprocessor... gcc -E
checking for egrep -e... /usr/bin/grep -E
checking whether to embed manifest... no
configure: creating ./config.status
config.status: creating Makefile
config.status: creating tclConfig.sh
config.status: creating tclsh.exe.manifest
jnml@pi64 CLANGARM64 ~/src/modernc.org/tk9.0/tcl9.0b3/win (dev)
> The current configure method is not so good in detecting
> the correct cross-compile environment.
Wrt cross-compile, I noticed the above says
checking whether we are cross compiling... no
Indeed, I'm running this on a RPi with Windows10/arm64 installed.
Anyway, the subsequent 'make` fails in the the same place/file as
before, now with a different error:
gcc -c -I"."
-I"C:/Users/jnml/src/modernc.org/tk9.0/tcl9.0b3/generic"
-I"C:/Users/jnml/src/modernc.org/tk9.0/tcl9.0b3/libtommath"
-I"C:/Users/jnml/src/modernc.org/tk9.0/tcl9.0b3/compat/zlib"
-I"C:/Users/jnml/src/modernc.org/tk9.0/tcl9.0b3/win" -O2
-fomit-frame-pointer -DMP_FIXED_CUTOFFS -D__USE_MINGW_ANSI_STDIO=0
-Wall -Wextra -Wshadow -Wundef -Wwrite-strings -Wpointer-arith
-Wc++-compat -fextended-identifiers -DMP_PREC=4 -pipe -DHAVE_CPUID=1
-finput-charset=UTF-8 -DPACKAGE_NAME=\"tcl\" -DPACKAGE_TARNAME=\"tcl\"
-DPACKAGE_VERSION=\"9.0\" -DPACKAGE_STRING=\"tcl\ 9.0\"
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\"
-DTCL_CFGVAL_ENCODING=\"utf-8\" -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 -DMODULE_SCOPE=extern
-DTCL_CFG_DO64BIT=1 -DHAVE_NO_SEH=1 -DHAVE_STDBOOL_H=1
-DHAVE_CAST_TO_UNION=1 -DTCL_WITH_EXTERNAL_TOMMATH=1 -DMP_64BIT=1
-DHAVE_ZLIB=1 -DHAVE_INTPTR_T=1 -DHAVE_UINTPTR_T=1 -DZIPFS_BUILD=1
-DHAVE_WSPIAPI_H=1 -DNDEBUG=1 -DTCL_CFG_OPTIMIZED=1 -DBUILD_tcl
"tclWin32Dll.c" -o tclWin32Dll.o
tclWin32Dll.c:472:2: error: unknown register name '%eax' in asm
472 | "%eax", "%ebx", "%ecx", "%edx", "%esi", "%edi", "memory");
| ^
1 error generated.
make: *** [Makefile:758: tclWin32Dll.o] Error 1
jnml@pi64 CLANGARM64 ~/src/modernc.org/tk9.0/tcl9.0b3/win (dev)
$ gcc -dumpmachine
aarch64-w64-windows-gnu
jnml@pi64 CLANGARM64 ~/src/modernc.org/tk9.0/tcl9.0b3/win (dev)
$ gcc --version
clang version 19.1.0-rc3 (https://github.com/llvm/llvm-project.git
437434df21d839becb453f6821564662e9824f02)
Target: aarch64-w64-windows-gnu
Thread model: posix
InstalledDir: C:/mingw/bin
jnml@pi64 CLANGARM64 ~/src/modernc.org/tk9.0/tcl9.0b3/win (dev)
$
FTR: I started the build in a freshly un-tarred folder before
./configure-ing it.
Thanks again for your help.
Best,
Jan
|
|
From: Jan N. <jan...@gm...> - 2024-09-03 16:35:09
|
Op di 3 sep 2024 om 16:51 schreef Jan Mercl:
> When trying to build tcl9.0b3 on Windows 10/aarch64.
>
> Invoking ./configure and make fails after a while with this message
> (many preceding lines omitted):
>
Can you try
./configure --enable-64bit=aarch64
The current configure method is not so good in detecting
the correct cross-compile environment.
Feel free to file a ticket about this
Hope this helps,
Jan Nijtmans
|
26 messages has been excluded from this view by a project administrator.
