Menu
▾
▴
naviserver-devel — Developer discussion
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
(53) |
Mar
(62) |
Apr
(88) |
May
(55) |
Jun
(204) |
Jul
(52) |
Aug
|
Sep
(1) |
Oct
(94) |
Nov
(15) |
Dec
(68) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(130) |
Feb
(105) |
Mar
(34) |
Apr
(61) |
May
(41) |
Jun
(92) |
Jul
(176) |
Aug
(102) |
Sep
(247) |
Oct
(69) |
Nov
(32) |
Dec
(140) |
| 2007 |
Jan
(58) |
Feb
(51) |
Mar
(11) |
Apr
(20) |
May
(34) |
Jun
(37) |
Jul
(18) |
Aug
(60) |
Sep
(41) |
Oct
(105) |
Nov
(19) |
Dec
(14) |
| 2008 |
Jan
(3) |
Feb
|
Mar
(7) |
Apr
(5) |
May
(123) |
Jun
(5) |
Jul
(1) |
Aug
(29) |
Sep
(15) |
Oct
(21) |
Nov
(51) |
Dec
(3) |
| 2009 |
Jan
|
Feb
(36) |
Mar
(29) |
Apr
|
May
|
Jun
(7) |
Jul
(4) |
Aug
|
Sep
(4) |
Oct
|
Nov
(13) |
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
(9) |
Apr
(11) |
May
(16) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
(7) |
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
(92) |
Nov
(28) |
Dec
(16) |
| 2013 |
Jan
(9) |
Feb
(2) |
Mar
|
Apr
(4) |
May
(4) |
Jun
(6) |
Jul
(14) |
Aug
(12) |
Sep
(4) |
Oct
(13) |
Nov
(1) |
Dec
(6) |
| 2014 |
Jan
(23) |
Feb
(19) |
Mar
(10) |
Apr
(14) |
May
(11) |
Jun
(6) |
Jul
(11) |
Aug
(15) |
Sep
(41) |
Oct
(95) |
Nov
(23) |
Dec
(11) |
| 2015 |
Jan
(3) |
Feb
(9) |
Mar
(19) |
Apr
(3) |
May
(1) |
Jun
(3) |
Jul
(11) |
Aug
(1) |
Sep
(15) |
Oct
(5) |
Nov
(2) |
Dec
|
| 2016 |
Jan
(7) |
Feb
(11) |
Mar
(8) |
Apr
(1) |
May
(3) |
Jun
(17) |
Jul
(12) |
Aug
(3) |
Sep
(5) |
Oct
(19) |
Nov
(12) |
Dec
(6) |
| 2017 |
Jan
(30) |
Feb
(23) |
Mar
(12) |
Apr
(32) |
May
(27) |
Jun
(7) |
Jul
(13) |
Aug
(16) |
Sep
(6) |
Oct
(11) |
Nov
|
Dec
(12) |
| 2018 |
Jan
(1) |
Feb
(5) |
Mar
(6) |
Apr
(7) |
May
(23) |
Jun
(3) |
Jul
(2) |
Aug
(1) |
Sep
(6) |
Oct
(6) |
Nov
(10) |
Dec
(3) |
| 2019 |
Jan
(26) |
Feb
(15) |
Mar
(9) |
Apr
|
May
(8) |
Jun
(14) |
Jul
(10) |
Aug
(10) |
Sep
(4) |
Oct
(2) |
Nov
(20) |
Dec
(10) |
| 2020 |
Jan
(10) |
Feb
(14) |
Mar
(29) |
Apr
(11) |
May
(25) |
Jun
(21) |
Jul
(23) |
Aug
(12) |
Sep
(19) |
Oct
(6) |
Nov
(8) |
Dec
(12) |
| 2021 |
Jan
(29) |
Feb
(9) |
Mar
(8) |
Apr
(8) |
May
(2) |
Jun
(2) |
Jul
(9) |
Aug
(9) |
Sep
(3) |
Oct
(4) |
Nov
(12) |
Dec
(13) |
| 2022 |
Jan
(4) |
Feb
|
Mar
(4) |
Apr
(12) |
May
(15) |
Jun
(7) |
Jul
(10) |
Aug
(2) |
Sep
|
Oct
(1) |
Nov
(8) |
Dec
|
| 2023 |
Jan
(15) |
Feb
|
Mar
(23) |
Apr
(1) |
May
(2) |
Jun
(10) |
Jul
|
Aug
(22) |
Sep
(19) |
Oct
(2) |
Nov
(20) |
Dec
|
| 2024 |
Jan
(1) |
Feb
|
Mar
(16) |
Apr
(15) |
May
(6) |
Jun
(4) |
Jul
(1) |
Aug
(1) |
Sep
|
Oct
(13) |
Nov
(18) |
Dec
(6) |
| 2025 |
Jan
(12) |
Feb
|
Mar
(2) |
Apr
(1) |
May
(11) |
Jun
(5) |
Jul
(4) |
Aug
(2) |
Sep
(2) |
Oct
|
Nov
|
Dec
|
|
From: Sassy N. <sa...@gm...> - 2024-11-25 17:21:53
|
Thank you for your response You were right ! as always - adding "nostrip" to DEB_BUILD_OPTIONS works. Thank you. On Mon, Nov 25, 2024 at 1:06 PM Gustaf Neumann (sslmail) <ne...@wu...> wrote: > Dear Sassy, > > not sure what’s wrong. You installed the NaviServer modules at an unusual > place, from where normally shared libraries are loaded. Can it be, that > something stripped symbols in your installation process? > > Anyhow, on a Debian like system you should have: > > $ cd /usr/local/ns/bin/ > $ for f in nsdbpg.so nsdb.so ; do echo ---$f--- && (nm $f | fgrep Module); > done > ---nsdbpg.so--- > 0000000000008598 R Ns_ModuleVersion > ---nsdb.so--- > 00000000000011a0 T Ns_ModuleInit > 0000000000002030 R Ns_ModuleVersion > > > As a reference, you find the sample configuration file for OpenACS in the > NaviServer repository, which loads per default the ndsbpg module. > > You can also check the bookworm docker images at [1]. With this, you can > do: > > docker run --rm -it --entrypoint /bin/bash > gustafn/naviserver-pg:latest-bookworm > # apt -y install binutils > > > … and the run the commands with nm above… > > All the best > -g > PS: i use normally for quick installations > https://github.com/gustafn/install-ns This gives a wide range of options > (tcl versions, naviserver versions, better malloc library, ….) > > [1] https://hub.docker.com/repository/docker/gustafn/naviserver-pg/general > > > On 25.11.2024, at 11:19, Sassy Natan <sa...@gm...> wrote: > > Sorry once again, > > I was thinking I solved it but I still have the same problem. > > I'm running head version of the repo: commit > 5232c61ff982ab232827746298257d7859010e28 (HEAD -> main, origin/main, > origin/HEAD), Author: Gustaf Neumann <ne...@wu...>, Date: Sun > Nov 3 11:33:23 2024 +0100 > > When starting the server: > > [25/Nov/2024:10:13:03][29267.7be2d5a19840][-main:localhost-] Notice: > modload: loading module nsgdchart from file > /usr/lib/x86_64-linux-gnu/naviserver/bin/nsgdchart.so > [25/Nov/2024:10:13:03][29267.7be2d5a19840][-main:localhost-] Notice: > modload: loading module nsdb from file > /usr/lib/x86_64-linux-gnu/naviserver/bin/nsdb.so > > > > > > *[25/Nov/2024:10:13:03][29267.7be2d5a19840][-main:localhost-] Debug(sql): > nsdb: Add DB pool: > main[25/Nov/2024:10:13:03][29267.7be2d5a19840][-main:localhost-] Error: > dbdrv: no such driver > 'postgres'[25/Nov/2024:10:13:03][29267.7be2d5a19840][-main:localhost-] > Debug(sql): nsdb: Add DB pool: > subquery[25/Nov/2024:10:13:03][29267.7be2d5a19840][-main:localhost-] > Debug(sql): nsdb: Add DB pool: > log[25/Nov/2024:10:13:03][29267.7be2d5a19840][-main:localhost-] Error: > dbinit: no such default pool 'main'*[25/Nov/2024:10:13:03][29267.7be2d5a19840][-main:localhost-] > Notice: modload: loading module nsdbpg from file > /usr/lib/x86_64-linux-gnu/naviserver/bin/nsdbpg.so > > > *[25/Nov/2024:10:13:03][29267.7be2d5a19840][-main:localhost-] Error: > modload: /usr/lib/x86_64-linux-gnu/naviserver/bin/nsdbpg.so: cannot find > symbol "Ns_ModuleInit": /usr/lib/x86_64-linux-gnu/naviserver/bin/nsdbpg.so: > undefined symbol: > _Ns_ModuleInit[25/Nov/2024:10:13:03][29267.7be2d5a19840][-main:localhost-] > Fatal: modload: failed to load module > '/usr/lib/x86_64-linux-gnu/naviserver/bin/nsdbpg.so'* > > > In the README file in nsdbpg git repo the config point to set the driver > like this: > ns_param driver postgres > > but in the previous version it was nsdbpg - is this valid? > > Here is my config: > > ns_section "ns/server/${server}/modules" { > ns_param nsdb ${homedir}/bin/nsdb.so > } > > ns_section "ns/server/${server}/modules" { > ns_param nsdbpg ${homedir}/bin/nsdbpg.so > } > > ns_section "ns/db/pools" { > ns_param main "Main" > ns_param subquery "Subquery" > ns_param log "Log" > } > > ns_section "ns/db/pool/main" { > ns_param driver *postgres* > ns_param datasource > ${pg_db_host}:${pg_db_port}:${pg_db_name} > ns_param user ${pg_db_user} > ns_param password ${pg_db_password} > ns_param connections 15 > ns_param LogMinDuration 0.01 > ;# when SQL logging is on, log only statements above > this duration > ns_param logsqlerrors true > ;# Verbose SQL query error logging > ns_param verbose true > ;# Verbose error logging > ns_param maxidle 10 > ;# Max time to keep idle db conn open > ns_param maxopen 10 > ;# Max time to keep active db conn open > ns_param extendedtableinfo on > } > > ns_section "ns/db/pool/subquery" { > ns_param driver *postgres* > ns_param datasource > ${pg_db_host}:${pg_db_port}:${pg_db_name} > ns_param user ${pg_db_user} > ns_param password ${pg_db_password} > ns_param connections 15 > ns_param LogMinDuration 0.01 > ;# when SQL logging is on, log only statements above > this duration > ns_param logsqlerrors true > ;# Verbose SQL query error logging > ns_param verbose true > ;# Verbose error logging > ns_param maxidle 10 > ;# Max time to keep idle db conn open > ns_param maxopen 10 > ;# Max time to keep active db conn open > ns_param extendedtableinfo on > } > > ns_section "ns/db/pool/log" { > ns_param driver *postgres* > ns_param datasource > ${pg_db_host}:${pg_db_port}:${pg_db_name} > ns_param user ${pg_db_user} > ns_param password ${pg_db_password} > ns_param connections 15 > ns_param LogMinDuration 0.01 > ;# when SQL logging is on, log only statements above > this duration > ns_param logsqlerrors true > ;# Verbose SQL query error logging > ns_param verbose true > ;# Verbose error logging > ns_param maxidle 10 > ;# Max time to keep idle db conn open > ns_param maxopen 10 > ;# Max time to keep active db conn open > ns_param extendedtableinfo on > } > > # > # > # Accessing DB pools > # > # In the case of virtual servers you can give different virtual > # servers access to different databases, or you can let them access > # them all. AOLserver 3.x does not use virtual servers so the only > # useful value is "*", but if you use one config file for multiple nsd > # processes, or you are using a version of AOLserver that supports > # virtual servers, then you should list the pools you want to access. > # > ns_section "ns/server/${server}/db" { > ns_param pools main,subquery,log > ns_param defaultpool "main" > } > > Any feedback is welcome. > > > On Mon, Nov 25, 2024 at 11:33 AM Sassy Natan <sa...@gm...> wrote: > >> Please ignore... >> >> I forgot to load the nsdb.so module... >> >> All good :-) >> >> Thank You. >> >> >> On Mon, Nov 25, 2024 at 11:22 AM Sassy Natan <sa...@gm...> wrote: >> >>> Hi Group, >>> >>> I was trying to install naviserver 4.99.31-1 on my ubuntu 24.04 server. >>> I can provide to the community a debian package I have built to support >>> this project (see attached picture). >>> >>> However, It seems that I have an issue with the naviserver-nsdbpg module. >>> >>> I'm using postgresql-17 (17.2-1.pgdg24.04) on this server, and I was >>> successfully build the nsdbpg module using "make >>> PGLIB=$/usr/lib/postgresql/17/lib/ PGINCLUDE=/usr/include/postgresql/". >>> >>> The nsdbpg.so file was created successfully with no error on the >>> compilation and linkage. >>> >>> When trying to load naviserver I'm getting the following error message: >>> >>> Error: modload: /usr/lib/x86_64-linux-gnu/naviserver/bin/nsdbpg.so: >>> cannot find symbol "Ns_ModuleInit": >>> /usr/lib/x86_64-linux-gnu/naviserver/bin/nsdbpg.so: undefined symbol: >>> _Ns_ModuleInit >>> >>> Running ldd on the file >>> /usr/lib/x86_64-linux-gnu/naviserver/bin/nsdbpg.so provide this output: >>> >>> linux-vdso.so.1 (0x00007fff676fc000) >>> libnsdb-4.99.31.so.1 => >>> /lib/x86_64-linux-gnu/libnsdb-4.99.31.so.1 (0x00007ddd751af000) >>> libpq.so.5 => /lib/x86_64-linux-gnu/libpq.so.5 >>> (0x00007ddd75158000) >>> libnsthread-4.99.31.so.1 => >>> /lib/x86_64-linux-gnu/libnsthread-4.99.31.so.1 (0x00007ddd7514c000) >>> libnsd-4.99.31.so.1 => /lib/x86_64-linux-gnu/libnsd-4.99.31.so.1 >>> (0x00007ddd75047000) >>> libtcl8.6.so => /lib/x86_64-linux-gnu/libtcl8.6.so >>> (0x00007ddd74e9a000) >>> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ddd74c00000) >>> libssl.so.3 => /lib/x86_64-linux-gnu/libssl.so.3 >>> (0x00007ddd74b56000) >>> libcrypto.so.3 => /lib/x86_64-linux-gnu/libcrypto.so.3 >>> (0x00007ddd74600000) >>> libgssapi_krb5.so.2 => /lib/x86_64-linux-gnu/libgssapi_krb5.so.2 >>> (0x00007ddd74e44000) >>> libldap.so.2 => /lib/x86_64-linux-gnu/libldap.so.2 >>> (0x00007ddd745a3000) >>> libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007ddd74e26000) >>> libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 >>> (0x00007ddd74b1c000) >>> libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ddd744ba000) >>> /lib64/ld-linux-x86-64.so.2 (0x00007ddd751d5000) >>> libkrb5.so.3 => /lib/x86_64-linux-gnu/libkrb5.so.3 >>> (0x00007ddd743f1000) >>> libk5crypto.so.3 => /lib/x86_64-linux-gnu/libk5crypto.so.3 >>> (0x00007ddd743c5000) >>> libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 >>> (0x00007ddd74e1e000) >>> libkrb5support.so.0 => /lib/x86_64-linux-gnu/libkrb5support.so.0 >>> (0x00007ddd743b8000) >>> liblber.so.2 => /lib/x86_64-linux-gnu/liblber.so.2 >>> (0x00007ddd743a8000) >>> libsasl2.so.2 => /lib/x86_64-linux-gnu/libsasl2.so.2 >>> (0x00007ddd7438e000) >>> libgnutls.so.30 => /lib/x86_64-linux-gnu/libgnutls.so.30 >>> (0x00007ddd74194000) >>> libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1 >>> (0x00007ddd74e15000) >>> libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 >>> (0x00007ddd74181000) >>> libp11-kit.so.0 => /lib/x86_64-linux-gnu/libp11-kit.so.0 >>> (0x00007ddd73fdd000) >>> libidn2.so.0 => /lib/x86_64-linux-gnu/libidn2.so.0 >>> (0x00007ddd73fbb000) >>> libunistring.so.5 => /lib/x86_64-linux-gnu/libunistring.so.5 >>> (0x00007ddd73e0e000) >>> libtasn1.so.6 => /lib/x86_64-linux-gnu/libtasn1.so.6 >>> (0x00007ddd73df8000) >>> libnettle.so.8 => /lib/x86_64-linux-gnu/libnettle.so.8 >>> (0x00007ddd73da3000) >>> libhogweed.so.6 => /lib/x86_64-linux-gnu/libhogweed.so.6 >>> (0x00007ddd73d5b000) >>> libgmp.so.10 => /lib/x86_64-linux-gnu/libgmp.so.10 >>> (0x00007ddd73cd7000) >>> libffi.so.8 => /lib/x86_64-linux-gnu/libffi.so.8 >>> (0x00007ddd73ccb000) >>> >>> >>> Running nm (list symbols from object files) on the >>> /usr/lib/x86_64-linux-gnu/naviserver/bin/nsdbpg.so doesn't provide any >>> feedback about having the the _Ns_ModuleInit symbol. >>> >>> See here: >>> .. >>> .. >>> .. >>> .. >>> >>> 0000000000004d50 t AddCmds >>> 0000000000004260 t BindRow >>> 00000000000077f0 t blob_dml_file >>> 0000000000007200 t blob_get >>> 00000000000075e0 t blob_put >>> 00000000000072e0 t blob_send_to_stream >>> 00000000000041e0 t CloseDb >>> U close@GLIBC_2.2.5 >>> 000000000000b068 b completed.0 >>> U __ctype_b_loc@GLIBC_2.3 >>> w __cxa_finalize@GLIBC_2.2.5 >>> 000000000000b070 b dateStyle >>> 0000000000006870 t DbFail >>> 0000000000003f50 t DbType >>> 0000000000007c70 t decode3 >>> 0000000000003ce0 t deregister_tm_clones >>> 0000000000003d50 t __do_global_dtors_aux >>> 000000000000a8d8 d __do_global_dtors_aux_fini_array_entry >>> 000000000000b000 d __dso_handle >>> 000000000000aa30 d _DYNAMIC >>> 0000000000007b60 t encode3 >>> 0000000000007b30 t enc_one >>> U __errno_location@GLIBC_2.2.5 >>> 0000000000004370 t Exec >>> 0000000000007d5c t _fini >>> 0000000000004980 t Flush >>> 0000000000003d90 t frame_dummy >>> 000000000000a8d0 d __frame_dummy_init_array_entry >>> 00000000000093a0 r __FRAME_END__ >>> 0000000000006fb0 t get_blob_tuples >>> U getenv@GLIBC_2.2.5 >>> 0000000000007c50 t get_one >>> 0000000000004740 t GetRow >>> 0000000000004940 t GetRowCount >>> 000000000000ac60 d _GLOBAL_OFFSET_TABLE_ >>> w __gmon_start__ >>> 0000000000008b50 r __GNU_EH_FRAME_HDR >>> 000000000000b078 b id >>> 0000000000003000 t _init >>> 000000000000b080 b intTypePtr >>> U __isoc23_strtol@GLIBC_2.38 >>> w _ITM_deregisterTMCloneTable >>> w _ITM_registerTMCloneTable >>> 0000000000007a80 t linkedListElement_new >>> 0000000000007ae0 t LinkedList_free_list >>> 0000000000007ab0 t LinkedList_len >>> 0000000000005370 t ListElementExternal >>> U ns_calloc >>> U Ns_ConfigGetValue >>> U Ns_ConnContentSent >>> U Ns_ConnWriteData >>> U Ns_Db0or1Row >>> U Ns_Db1Row >>> U Ns_DbDML >>> 0000000000003da0 T Ns_DbDriverInit >>> U Ns_DbDriverName >>> U Ns_DbExec >>> U Ns_DbGetMinDuration >>> 00000000000052c4 N nsdbpg.c.6eb8844b >>> U Ns_DbRegisterDriver >>> U Ns_DbSelect >>> U Ns_DbSetException >>> U Ns_DiffTime >>> U Ns_DStringExport >>> U Ns_DStringPrintf >>> U NS_EMPTY_STRING >>> U ns_free >>> U Ns_GetTime >>> U Ns_HttpParseHost2 >>> U Ns_Log >>> U Ns_LogSeverityEnabled >>> U Ns_LogSqlDebug >>> U ns_malloc >>> 0000000000008000 R Ns_ModuleVersion >>> U Ns_ObjvArgs >>> U Ns_ObjvObj >>> U Ns_ObjvSet >>> U Ns_ObjvString >>> U Ns_ParseObjv >>> 0000000000004d00 T Ns_PgServerInit >>> U Ns_SetClearValues >>> U Ns_SetFree >>> U Ns_SetGet >>> U Ns_SetPutSz >>> U Ns_SetPutValueSz >>> U Ns_SubcmdObjv >>> U Ns_TclDbGetHandle >>> U Ns_TclEnterSet >>> U Ns_TclGetConn >>> U Ns_TclPrintfResult >>> U Ns_TclRegisterTrace >>> 0000000000003f60 t OpenDb >>> U open@GLIBC_2.2.5 >>> 0000000000006a30 t parse_bind_variables >>> 0000000000005260 t ParsedSQLDupInternalRep >>> 00000000000051f0 t ParsedSQLFreeInternalRep >>> 000000000000b040 d ParsedSQLObjType >>> 00000000000052d0 t ParsedSQLSetFromAny >>> 00000000000058a0 t PgBindDmlObjCmd >>> 0000000000005fd0 t PgBindExecObjCmd >>> 00000000000061e0 t PgBindObjCmd >>> 0000000000005a50 t PgBindOneRowObjCmd >>> 0000000000005e10 t PgBindSelectObjCmd >>> 0000000000005c20 t PgBindZeroOrOneRowObjCmd >>> 000000000000b020 D pgDbName >>> 0000000000004dc0 t PgObjCmd >>> 0000000000006440 t PgPrepareObjCmd >>> U PQbackendPID >>> U PQclear >>> U PQcmdTuples >>> U PQdb >>> U PQerrorMessage >>> U PQexec >>> U PQfinish >>> U PQfname >>> U PQfreemem >>> U PQftype >>> U PQgetlength >>> U PQgetvalue >>> U PQhost >>> U PQlibVersion >>> U PQnfields >>> U PQntuples >>> U PQoptions >>> U PQport >>> U PQresultErrorMessage >>> U PQresultStatus >>> U PQsetdbLogin >>> U PQstatus >>> U PQunescapeBytea >>> 000000000000a960 d procs >>> U read@GLIBC_2.2.5 >>> 0000000000003d10 t register_tm_clones >>> 00000000000049f0 t ResetHandle >>> 0000000000004a90 t SetTransactionState >>> U __snprintf_chk@GLIBC_2.3.4 >>> U __sprintf_chk@GLIBC_2.3.4 >>> 00000000000053c0 t SqlObjToString >>> U __stack_chk_fail@GLIBC_2.4 >>> U strcasecmp@GLIBC_2.2.5 >>> U __strcat_chk@GLIBC_2.3.4 >>> U strchr@GLIBC_2.2.5 >>> U strcmp@GLIBC_2.2.5 >>> U __strcpy_chk@GLIBC_2.3.4 >>> U strerror@GLIBC_2.2.5 >>> U strlen@GLIBC_2.2.5 >>> U strncasecmp@GLIBC_2.2.5 >>> 000000000000a8e0 d subcmds.0 >>> 00000000000062e1 N tclcmds.c.1cb70ca1 >>> U Tcl_ConvertToType >>> U Tcl_CreateObjCommand >>> U Tcl_DictObjPut >>> U Tcl_DStringAppend >>> U Tcl_DStringFree >>> U Tcl_DStringInit >>> U Tcl_DStringResult >>> U Tcl_DStringSetLength >>> U Tcl_ExternalToUtfDString >>> U Tcl_GetByteArrayFromObj >>> U Tcl_GetIndexFromObjStruct >>> U Tcl_GetObjType >>> U Tcl_GetString >>> U Tcl_GetStringFromObj >>> U Tcl_GetVar2Ex >>> U Tcl_ListObjAppendElement >>> U Tcl_NewByteArrayObj >>> U Tcl_NewDictObj >>> U Tcl_NewIntObj >>> U Tcl_NewListObj >>> U Tcl_NewStringObj >>> U Tcl_Panic >>> U Tcl_SetObjResult >>> U Tcl_UtfToExternalDString >>> U Tcl_WrongNumArgs >>> 000000000000b068 d __TMC_END__ >>> U write@GLIBC_2.2.5 >>> 0000000000007560 t write_to_stream >>> >>> >>> Am I missing something ? or there is an issue with the Code? >>> <image.png> >>> >>> >>> Thanks >>> Regards, >>> >>> Sassy Natan >>> 972-(0)54-2203702 >>> >> >> >> -- >> Regards, >> >> Sassy Natan >> 972-(0)54-2203702 >> > > > -- > Regards, > > Sassy Natan > 972-(0)54-2203702 > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > > > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > -- Regards, Sassy Natan 972-(0)54-2203702 |
|
From: Gustaf N. (sslmail) <ne...@wu...> - 2024-11-25 11:06:06
|
Dear Sassy, not sure what’s wrong. You installed the NaviServer modules at an unusual place, from where normally shared libraries are loaded. Can it be, that something stripped symbols in your installation process? Anyhow, on a Debian like system you should have: $ cd /usr/local/ns/bin/ $ for f in nsdbpg.so nsdb.so ; do echo ---$f--- && (nm $f | fgrep Module); done ---nsdbpg.so--- 0000000000008598 R Ns_ModuleVersion ---nsdb.so--- 00000000000011a0 T Ns_ModuleInit 0000000000002030 R Ns_ModuleVersion As a reference, you find the sample configuration file for OpenACS in the NaviServer repository, which loads per default the ndsbpg module. You can also check the bookworm docker images at [1]. With this, you can do: docker run --rm -it --entrypoint /bin/bash gustafn/naviserver-pg:latest-bookworm # apt -y install binutils … and the run the commands with nm above… All the best -g PS: i use normally for quick installations https://github.com/gustafn/install-ns This gives a wide range of options (tcl versions, naviserver versions, better malloc library, ….) [1] https://hub.docker.com/repository/docker/gustafn/naviserver-pg/general > On 25.11.2024, at 11:19, Sassy Natan <sa...@gm...> wrote: > > Sorry once again, > > I was thinking I solved it but I still have the same problem. > > I'm running head version of the repo: commit 5232c61ff982ab232827746298257d7859010e28 (HEAD -> main, origin/main, origin/HEAD), Author: Gustaf Neumann <ne...@wu... <mailto:ne...@wu...>>, Date: Sun Nov 3 11:33:23 2024 +0100 > > When starting the server: > > [25/Nov/2024:10:13:03][29267.7be2d5a19840][-main:localhost-] Notice: modload: loading module nsgdchart from file /usr/lib/x86_64-linux-gnu/naviserver/bin/nsgdchart.so > [25/Nov/2024:10:13:03][29267.7be2d5a19840][-main:localhost-] Notice: modload: loading module nsdb from file /usr/lib/x86_64-linux-gnu/naviserver/bin/nsdb.so > [25/Nov/2024:10:13:03][29267.7be2d5a19840][-main:localhost-] Debug(sql): nsdb: Add DB pool: main > [25/Nov/2024:10:13:03][29267.7be2d5a19840][-main:localhost-] Error: dbdrv: no such driver 'postgres' > [25/Nov/2024:10:13:03][29267.7be2d5a19840][-main:localhost-] Debug(sql): nsdb: Add DB pool: subquery > [25/Nov/2024:10:13:03][29267.7be2d5a19840][-main:localhost-] Debug(sql): nsdb: Add DB pool: log > [25/Nov/2024:10:13:03][29267.7be2d5a19840][-main:localhost-] Error: dbinit: no such default pool 'main' > [25/Nov/2024:10:13:03][29267.7be2d5a19840][-main:localhost-] Notice: modload: loading module nsdbpg from file /usr/lib/x86_64-linux-gnu/naviserver/bin/nsdbpg.so > [25/Nov/2024:10:13:03][29267.7be2d5a19840][-main:localhost-] Error: modload: /usr/lib/x86_64-linux-gnu/naviserver/bin/nsdbpg.so: cannot find symbol "Ns_ModuleInit": /usr/lib/x86_64-linux-gnu/naviserver/bin/nsdbpg.so: undefined symbol: _Ns_ModuleInit > [25/Nov/2024:10:13:03][29267.7be2d5a19840][-main:localhost-] Fatal: modload: failed to load module '/usr/lib/x86_64-linux-gnu/naviserver/bin/nsdbpg.so' > > > In the README file in nsdbpg git repo the config point to set the driver like this: > ns_param driver postgres > > but in the previous version it was nsdbpg - is this valid? > > Here is my config: > > ns_section "ns/server/${server}/modules" { > ns_param nsdb ${homedir}/bin/nsdb.so > } > > ns_section "ns/server/${server}/modules" { > ns_param nsdbpg ${homedir}/bin/nsdbpg.so > } > > ns_section "ns/db/pools" { > ns_param main "Main" > ns_param subquery "Subquery" > ns_param log "Log" > } > > ns_section "ns/db/pool/main" { > ns_param driver postgres > ns_param datasource ${pg_db_host}:${pg_db_port}:${pg_db_name} > ns_param user ${pg_db_user} > ns_param password ${pg_db_password} > ns_param connections 15 > ns_param LogMinDuration 0.01 ;# when SQL logging is on, log only statements above this duration > ns_param logsqlerrors true ;# Verbose SQL query error logging > ns_param verbose true ;# Verbose error logging > ns_param maxidle 10 ;# Max time to keep idle db conn open > ns_param maxopen 10 ;# Max time to keep active db conn open > ns_param extendedtableinfo on > } > > ns_section "ns/db/pool/subquery" { > ns_param driver postgres > ns_param datasource ${pg_db_host}:${pg_db_port}:${pg_db_name} > ns_param user ${pg_db_user} > ns_param password ${pg_db_password} > ns_param connections 15 > ns_param LogMinDuration 0.01 ;# when SQL logging is on, log only statements above this duration > ns_param logsqlerrors true ;# Verbose SQL query error logging > ns_param verbose true ;# Verbose error logging > ns_param maxidle 10 ;# Max time to keep idle db conn open > ns_param maxopen 10 ;# Max time to keep active db conn open > ns_param extendedtableinfo on > } > > ns_section "ns/db/pool/log" { > ns_param driver postgres > ns_param datasource ${pg_db_host}:${pg_db_port}:${pg_db_name} > ns_param user ${pg_db_user} > ns_param password ${pg_db_password} > ns_param connections 15 > ns_param LogMinDuration 0.01 ;# when SQL logging is on, log only statements above this duration > ns_param logsqlerrors true ;# Verbose SQL query error logging > ns_param verbose true ;# Verbose error logging > ns_param maxidle 10 ;# Max time to keep idle db conn open > ns_param maxopen 10 ;# Max time to keep active db conn open > ns_param extendedtableinfo on > } > > # > # > # Accessing DB pools > # > # In the case of virtual servers you can give different virtual > # servers access to different databases, or you can let them access > # them all. AOLserver 3.x does not use virtual servers so the only > # useful value is "*", but if you use one config file for multiple nsd > # processes, or you are using a version of AOLserver that supports > # virtual servers, then you should list the pools you want to access. > # > ns_section "ns/server/${server}/db" { > ns_param pools main,subquery,log > ns_param defaultpool "main" > } > > Any feedback is welcome. > > > On Mon, Nov 25, 2024 at 11:33 AM Sassy Natan <sa...@gm... <mailto:sa...@gm...>> wrote: >> Please ignore... >> >> I forgot to load the nsdb.so module... >> >> All good :-) >> >> Thank You. >> >> >> On Mon, Nov 25, 2024 at 11:22 AM Sassy Natan <sa...@gm... <mailto:sa...@gm...>> wrote: >>> Hi Group, >>> >>> I was trying to install naviserver 4.99.31-1 on my ubuntu 24.04 server. >>> I can provide to the community a debian package I have built to support this project (see attached picture). >>> >>> However, It seems that I have an issue with the naviserver-nsdbpg module. >>> >>> I'm using postgresql-17 (17.2-1.pgdg24.04) on this server, and I was successfully build the nsdbpg module using "make PGLIB=$/usr/lib/postgresql/17/lib/ PGINCLUDE=/usr/include/postgresql/". >>> >>> The nsdbpg.so file was created successfully with no error on the compilation and linkage. >>> >>> When trying to load naviserver I'm getting the following error message: >>> >>> Error: modload: /usr/lib/x86_64-linux-gnu/naviserver/bin/nsdbpg.so: cannot find symbol "Ns_ModuleInit": /usr/lib/x86_64-linux-gnu/naviserver/bin/nsdbpg.so: undefined symbol: _Ns_ModuleInit >>> >>> Running ldd on the file /usr/lib/x86_64-linux-gnu/naviserver/bin/nsdbpg.so provide this output: >>> >>> linux-vdso.so.1 (0x00007fff676fc000) >>> libnsdb-4.99.31.so.1 => /lib/x86_64-linux-gnu/libnsdb-4.99.31.so.1 (0x00007ddd751af000) >>> libpq.so.5 => /lib/x86_64-linux-gnu/libpq.so.5 (0x00007ddd75158000) >>> libnsthread-4.99.31.so.1 => /lib/x86_64-linux-gnu/libnsthread-4.99.31.so.1 (0x00007ddd7514c000) >>> libnsd-4.99.31.so.1 => /lib/x86_64-linux-gnu/libnsd-4.99.31.so.1 (0x00007ddd75047000) >>> libtcl8.6.so <http://libtcl8.6.so/> => /lib/x86_64-linux-gnu/libtcl8.6.so <http://libtcl8.6.so/> (0x00007ddd74e9a000) >>> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ddd74c00000) >>> libssl.so.3 => /lib/x86_64-linux-gnu/libssl.so.3 (0x00007ddd74b56000) >>> libcrypto.so.3 => /lib/x86_64-linux-gnu/libcrypto.so.3 (0x00007ddd74600000) >>> libgssapi_krb5.so.2 => /lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x00007ddd74e44000) >>> libldap.so.2 => /lib/x86_64-linux-gnu/libldap.so.2 (0x00007ddd745a3000) >>> libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007ddd74e26000) >>> libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007ddd74b1c000) >>> libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ddd744ba000) >>> /lib64/ld-linux-x86-64.so.2 (0x00007ddd751d5000) >>> libkrb5.so.3 => /lib/x86_64-linux-gnu/libkrb5.so.3 (0x00007ddd743f1000) >>> libk5crypto.so.3 => /lib/x86_64-linux-gnu/libk5crypto.so.3 (0x00007ddd743c5000) >>> libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 (0x00007ddd74e1e000) >>> libkrb5support.so.0 => /lib/x86_64-linux-gnu/libkrb5support.so.0 (0x00007ddd743b8000) >>> liblber.so.2 => /lib/x86_64-linux-gnu/liblber.so.2 (0x00007ddd743a8000) >>> libsasl2.so.2 => /lib/x86_64-linux-gnu/libsasl2.so.2 (0x00007ddd7438e000) >>> libgnutls.so.30 => /lib/x86_64-linux-gnu/libgnutls.so.30 (0x00007ddd74194000) >>> libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1 (0x00007ddd74e15000) >>> libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007ddd74181000) >>> libp11-kit.so.0 => /lib/x86_64-linux-gnu/libp11-kit.so.0 (0x00007ddd73fdd000) >>> libidn2.so.0 => /lib/x86_64-linux-gnu/libidn2.so.0 (0x00007ddd73fbb000) >>> libunistring.so.5 => /lib/x86_64-linux-gnu/libunistring.so.5 (0x00007ddd73e0e000) >>> libtasn1.so.6 => /lib/x86_64-linux-gnu/libtasn1.so.6 (0x00007ddd73df8000) >>> libnettle.so.8 => /lib/x86_64-linux-gnu/libnettle.so.8 (0x00007ddd73da3000) >>> libhogweed.so.6 => /lib/x86_64-linux-gnu/libhogweed.so.6 (0x00007ddd73d5b000) >>> libgmp.so.10 => /lib/x86_64-linux-gnu/libgmp.so.10 (0x00007ddd73cd7000) >>> libffi.so.8 => /lib/x86_64-linux-gnu/libffi.so.8 (0x00007ddd73ccb000) >>> >>> >>> Running nm (list symbols from object files) on the /usr/lib/x86_64-linux-gnu/naviserver/bin/nsdbpg.so doesn't provide any feedback about having the the _Ns_ModuleInit symbol. >>> >>> See here: >>> .. >>> .. >>> .. >>> .. >>> >>> 0000000000004d50 t AddCmds >>> 0000000000004260 t BindRow >>> 00000000000077f0 t blob_dml_file >>> 0000000000007200 t blob_get >>> 00000000000075e0 t blob_put >>> 00000000000072e0 t blob_send_to_stream >>> 00000000000041e0 t CloseDb >>> U close@GLIBC_2.2.5 >>> 000000000000b068 b completed.0 >>> U __ctype_b_loc@GLIBC_2.3 >>> w __cxa_finalize@GLIBC_2.2.5 >>> 000000000000b070 b dateStyle >>> 0000000000006870 t DbFail >>> 0000000000003f50 t DbType >>> 0000000000007c70 t decode3 >>> 0000000000003ce0 t deregister_tm_clones >>> 0000000000003d50 t __do_global_dtors_aux >>> 000000000000a8d8 d __do_global_dtors_aux_fini_array_entry >>> 000000000000b000 d __dso_handle >>> 000000000000aa30 d _DYNAMIC >>> 0000000000007b60 t encode3 >>> 0000000000007b30 t enc_one >>> U __errno_location@GLIBC_2.2.5 >>> 0000000000004370 t Exec >>> 0000000000007d5c t _fini >>> 0000000000004980 t Flush >>> 0000000000003d90 t frame_dummy >>> 000000000000a8d0 d __frame_dummy_init_array_entry >>> 00000000000093a0 r __FRAME_END__ >>> 0000000000006fb0 t get_blob_tuples >>> U getenv@GLIBC_2.2.5 >>> 0000000000007c50 t get_one >>> 0000000000004740 t GetRow >>> 0000000000004940 t GetRowCount >>> 000000000000ac60 d _GLOBAL_OFFSET_TABLE_ >>> w __gmon_start__ >>> 0000000000008b50 r __GNU_EH_FRAME_HDR >>> 000000000000b078 b id >>> 0000000000003000 t _init >>> 000000000000b080 b intTypePtr >>> U __isoc23_strtol@GLIBC_2.38 >>> w _ITM_deregisterTMCloneTable >>> w _ITM_registerTMCloneTable >>> 0000000000007a80 t linkedListElement_new >>> 0000000000007ae0 t LinkedList_free_list >>> 0000000000007ab0 t LinkedList_len >>> 0000000000005370 t ListElementExternal >>> U ns_calloc >>> U Ns_ConfigGetValue >>> U Ns_ConnContentSent >>> U Ns_ConnWriteData >>> U Ns_Db0or1Row >>> U Ns_Db1Row >>> U Ns_DbDML >>> 0000000000003da0 T Ns_DbDriverInit >>> U Ns_DbDriverName >>> U Ns_DbExec >>> U Ns_DbGetMinDuration >>> 00000000000052c4 N nsdbpg.c.6eb8844b >>> U Ns_DbRegisterDriver >>> U Ns_DbSelect >>> U Ns_DbSetException >>> U Ns_DiffTime >>> U Ns_DStringExport >>> U Ns_DStringPrintf >>> U NS_EMPTY_STRING >>> U ns_free >>> U Ns_GetTime >>> U Ns_HttpParseHost2 >>> U Ns_Log >>> U Ns_LogSeverityEnabled >>> U Ns_LogSqlDebug >>> U ns_malloc >>> 0000000000008000 R Ns_ModuleVersion >>> U Ns_ObjvArgs >>> U Ns_ObjvObj >>> U Ns_ObjvSet >>> U Ns_ObjvString >>> U Ns_ParseObjv >>> 0000000000004d00 T Ns_PgServerInit >>> U Ns_SetClearValues >>> U Ns_SetFree >>> U Ns_SetGet >>> U Ns_SetPutSz >>> U Ns_SetPutValueSz >>> U Ns_SubcmdObjv >>> U Ns_TclDbGetHandle >>> U Ns_TclEnterSet >>> U Ns_TclGetConn >>> U Ns_TclPrintfResult >>> U Ns_TclRegisterTrace >>> 0000000000003f60 t OpenDb >>> U open@GLIBC_2.2.5 >>> 0000000000006a30 t parse_bind_variables >>> 0000000000005260 t ParsedSQLDupInternalRep >>> 00000000000051f0 t ParsedSQLFreeInternalRep >>> 000000000000b040 d ParsedSQLObjType >>> 00000000000052d0 t ParsedSQLSetFromAny >>> 00000000000058a0 t PgBindDmlObjCmd >>> 0000000000005fd0 t PgBindExecObjCmd >>> 00000000000061e0 t PgBindObjCmd >>> 0000000000005a50 t PgBindOneRowObjCmd >>> 0000000000005e10 t PgBindSelectObjCmd >>> 0000000000005c20 t PgBindZeroOrOneRowObjCmd >>> 000000000000b020 D pgDbName >>> 0000000000004dc0 t PgObjCmd >>> 0000000000006440 t PgPrepareObjCmd >>> U PQbackendPID >>> U PQclear >>> U PQcmdTuples >>> U PQdb >>> U PQerrorMessage >>> U PQexec >>> U PQfinish >>> U PQfname >>> U PQfreemem >>> U PQftype >>> U PQgetlength >>> U PQgetvalue >>> U PQhost >>> U PQlibVersion >>> U PQnfields >>> U PQntuples >>> U PQoptions >>> U PQport >>> U PQresultErrorMessage >>> U PQresultStatus >>> U PQsetdbLogin >>> U PQstatus >>> U PQunescapeBytea >>> 000000000000a960 d procs >>> U read@GLIBC_2.2.5 >>> 0000000000003d10 t register_tm_clones >>> 00000000000049f0 t ResetHandle >>> 0000000000004a90 t SetTransactionState >>> U __snprintf_chk@GLIBC_2.3.4 >>> U __sprintf_chk@GLIBC_2.3.4 >>> 00000000000053c0 t SqlObjToString >>> U __stack_chk_fail@GLIBC_2.4 >>> U strcasecmp@GLIBC_2.2.5 >>> U __strcat_chk@GLIBC_2.3.4 >>> U strchr@GLIBC_2.2.5 >>> U strcmp@GLIBC_2.2.5 >>> U __strcpy_chk@GLIBC_2.3.4 >>> U strerror@GLIBC_2.2.5 >>> U strlen@GLIBC_2.2.5 >>> U strncasecmp@GLIBC_2.2.5 >>> 000000000000a8e0 d subcmds.0 >>> 00000000000062e1 N tclcmds.c.1cb70ca1 >>> U Tcl_ConvertToType >>> U Tcl_CreateObjCommand >>> U Tcl_DictObjPut >>> U Tcl_DStringAppend >>> U Tcl_DStringFree >>> U Tcl_DStringInit >>> U Tcl_DStringResult >>> U Tcl_DStringSetLength >>> U Tcl_ExternalToUtfDString >>> U Tcl_GetByteArrayFromObj >>> U Tcl_GetIndexFromObjStruct >>> U Tcl_GetObjType >>> U Tcl_GetString >>> U Tcl_GetStringFromObj >>> U Tcl_GetVar2Ex >>> U Tcl_ListObjAppendElement >>> U Tcl_NewByteArrayObj >>> U Tcl_NewDictObj >>> U Tcl_NewIntObj >>> U Tcl_NewListObj >>> U Tcl_NewStringObj >>> U Tcl_Panic >>> U Tcl_SetObjResult >>> U Tcl_UtfToExternalDString >>> U Tcl_WrongNumArgs >>> 000000000000b068 d __TMC_END__ >>> U write@GLIBC_2.2.5 >>> 0000000000007560 t write_to_stream >>> >>> >>> Am I missing something ? or there is an issue with the Code? >>> <image.png> >>> >>> >>> Thanks >>> Regards, >>> >>> Sassy Natan >>> 972-(0)54-2203702 >> >> >> >> -- >> Regards, >> >> Sassy Natan >> 972-(0)54-2203702 > > > > -- > Regards, > > Sassy Natan > 972-(0)54-2203702 > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel |
|
From: Sassy N. <sa...@gm...> - 2024-11-25 10:20:12
|
Sorry once again,
I was thinking I solved it but I still have the same problem.
I'm running head version of the repo: commit
5232c61ff982ab232827746298257d7859010e28 (HEAD -> main, origin/main,
origin/HEAD), Author: Gustaf Neumann <ne...@wu...>, Date: Sun
Nov 3 11:33:23 2024 +0100
When starting the server:
[25/Nov/2024:10:13:03][29267.7be2d5a19840][-main:localhost-] Notice:
modload: loading module nsgdchart from file
/usr/lib/x86_64-linux-gnu/naviserver/bin/nsgdchart.so
[25/Nov/2024:10:13:03][29267.7be2d5a19840][-main:localhost-] Notice:
modload: loading module nsdb from file
/usr/lib/x86_64-linux-gnu/naviserver/bin/nsdb.so
*[25/Nov/2024:10:13:03][29267.7be2d5a19840][-main:localhost-] Debug(sql):
nsdb: Add DB pool:
main[25/Nov/2024:10:13:03][29267.7be2d5a19840][-main:localhost-] Error:
dbdrv: no such driver
'postgres'[25/Nov/2024:10:13:03][29267.7be2d5a19840][-main:localhost-]
Debug(sql): nsdb: Add DB pool:
subquery[25/Nov/2024:10:13:03][29267.7be2d5a19840][-main:localhost-]
Debug(sql): nsdb: Add DB pool:
log[25/Nov/2024:10:13:03][29267.7be2d5a19840][-main:localhost-] Error:
dbinit: no such default pool
'main'*[25/Nov/2024:10:13:03][29267.7be2d5a19840][-main:localhost-]
Notice: modload: loading module nsdbpg from file
/usr/lib/x86_64-linux-gnu/naviserver/bin/nsdbpg.so
*[25/Nov/2024:10:13:03][29267.7be2d5a19840][-main:localhost-] Error:
modload: /usr/lib/x86_64-linux-gnu/naviserver/bin/nsdbpg.so: cannot find
symbol "Ns_ModuleInit": /usr/lib/x86_64-linux-gnu/naviserver/bin/nsdbpg.so:
undefined symbol:
_Ns_ModuleInit[25/Nov/2024:10:13:03][29267.7be2d5a19840][-main:localhost-]
Fatal: modload: failed to load module
'/usr/lib/x86_64-linux-gnu/naviserver/bin/nsdbpg.so'*
In the README file in nsdbpg git repo the config point to set the driver
like this:
ns_param driver postgres
but in the previous version it was nsdbpg - is this valid?
Here is my config:
ns_section "ns/server/${server}/modules" {
ns_param nsdb ${homedir}/bin/nsdb.so
}
ns_section "ns/server/${server}/modules" {
ns_param nsdbpg ${homedir}/bin/nsdbpg.so
}
ns_section "ns/db/pools" {
ns_param main "Main"
ns_param subquery "Subquery"
ns_param log "Log"
}
ns_section "ns/db/pool/main" {
ns_param driver *postgres*
ns_param datasource
${pg_db_host}:${pg_db_port}:${pg_db_name}
ns_param user ${pg_db_user}
ns_param password ${pg_db_password}
ns_param connections 15
ns_param LogMinDuration 0.01
;# when SQL logging is on, log only statements above
this duration
ns_param logsqlerrors true
;# Verbose SQL query error logging
ns_param verbose true
;# Verbose error logging
ns_param maxidle 10
;# Max time to keep idle db conn open
ns_param maxopen 10
;# Max time to keep active db conn open
ns_param extendedtableinfo on
}
ns_section "ns/db/pool/subquery" {
ns_param driver *postgres*
ns_param datasource
${pg_db_host}:${pg_db_port}:${pg_db_name}
ns_param user ${pg_db_user}
ns_param password ${pg_db_password}
ns_param connections 15
ns_param LogMinDuration 0.01
;# when SQL logging is on, log only statements above
this duration
ns_param logsqlerrors true
;# Verbose SQL query error logging
ns_param verbose true
;# Verbose error logging
ns_param maxidle 10
;# Max time to keep idle db conn open
ns_param maxopen 10
;# Max time to keep active db conn open
ns_param extendedtableinfo on
}
ns_section "ns/db/pool/log" {
ns_param driver *postgres*
ns_param datasource
${pg_db_host}:${pg_db_port}:${pg_db_name}
ns_param user ${pg_db_user}
ns_param password ${pg_db_password}
ns_param connections 15
ns_param LogMinDuration 0.01
;# when SQL logging is on, log only statements above
this duration
ns_param logsqlerrors true
;# Verbose SQL query error logging
ns_param verbose true
;# Verbose error logging
ns_param maxidle 10
;# Max time to keep idle db conn open
ns_param maxopen 10
;# Max time to keep active db conn open
ns_param extendedtableinfo on
}
#
#
# Accessing DB pools
#
# In the case of virtual servers you can give different virtual
# servers access to different databases, or you can let them access
# them all. AOLserver 3.x does not use virtual servers so the only
# useful value is "*", but if you use one config file for multiple nsd
# processes, or you are using a version of AOLserver that supports
# virtual servers, then you should list the pools you want to access.
#
ns_section "ns/server/${server}/db" {
ns_param pools main,subquery,log
ns_param defaultpool "main"
}
Any feedback is welcome.
On Mon, Nov 25, 2024 at 11:33 AM Sassy Natan <sa...@gm...> wrote:
> Please ignore...
>
> I forgot to load the nsdb.so module...
>
> All good :-)
>
> Thank You.
>
>
> On Mon, Nov 25, 2024 at 11:22 AM Sassy Natan <sa...@gm...> wrote:
>
>> Hi Group,
>>
>> I was trying to install naviserver 4.99.31-1 on my ubuntu 24.04 server.
>> I can provide to the community a debian package I have built to support
>> this project (see attached picture).
>>
>> However, It seems that I have an issue with the naviserver-nsdbpg module.
>>
>> I'm using postgresql-17 (17.2-1.pgdg24.04) on this server, and I was
>> successfully build the nsdbpg module using "make
>> PGLIB=$/usr/lib/postgresql/17/lib/ PGINCLUDE=/usr/include/postgresql/".
>>
>> The nsdbpg.so file was created successfully with no error on the
>> compilation and linkage.
>>
>> When trying to load naviserver I'm getting the following error message:
>>
>> Error: modload: /usr/lib/x86_64-linux-gnu/naviserver/bin/nsdbpg.so:
>> cannot find symbol "Ns_ModuleInit":
>> /usr/lib/x86_64-linux-gnu/naviserver/bin/nsdbpg.so: undefined symbol:
>> _Ns_ModuleInit
>>
>> Running ldd on the file
>> /usr/lib/x86_64-linux-gnu/naviserver/bin/nsdbpg.so provide this output:
>>
>> linux-vdso.so.1 (0x00007fff676fc000)
>> libnsdb-4.99.31.so.1 =>
>> /lib/x86_64-linux-gnu/libnsdb-4.99.31.so.1 (0x00007ddd751af000)
>> libpq.so.5 => /lib/x86_64-linux-gnu/libpq.so.5
>> (0x00007ddd75158000)
>> libnsthread-4.99.31.so.1 =>
>> /lib/x86_64-linux-gnu/libnsthread-4.99.31.so.1 (0x00007ddd7514c000)
>> libnsd-4.99.31.so.1 => /lib/x86_64-linux-gnu/libnsd-4.99.31.so.1
>> (0x00007ddd75047000)
>> libtcl8.6.so => /lib/x86_64-linux-gnu/libtcl8.6.so
>> (0x00007ddd74e9a000)
>> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ddd74c00000)
>> libssl.so.3 => /lib/x86_64-linux-gnu/libssl.so.3
>> (0x00007ddd74b56000)
>> libcrypto.so.3 => /lib/x86_64-linux-gnu/libcrypto.so.3
>> (0x00007ddd74600000)
>> libgssapi_krb5.so.2 => /lib/x86_64-linux-gnu/libgssapi_krb5.so.2
>> (0x00007ddd74e44000)
>> libldap.so.2 => /lib/x86_64-linux-gnu/libldap.so.2
>> (0x00007ddd745a3000)
>> libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007ddd74e26000)
>> libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1
>> (0x00007ddd74b1c000)
>> libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ddd744ba000)
>> /lib64/ld-linux-x86-64.so.2 (0x00007ddd751d5000)
>> libkrb5.so.3 => /lib/x86_64-linux-gnu/libkrb5.so.3
>> (0x00007ddd743f1000)
>> libk5crypto.so.3 => /lib/x86_64-linux-gnu/libk5crypto.so.3
>> (0x00007ddd743c5000)
>> libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2
>> (0x00007ddd74e1e000)
>> libkrb5support.so.0 => /lib/x86_64-linux-gnu/libkrb5support.so.0
>> (0x00007ddd743b8000)
>> liblber.so.2 => /lib/x86_64-linux-gnu/liblber.so.2
>> (0x00007ddd743a8000)
>> libsasl2.so.2 => /lib/x86_64-linux-gnu/libsasl2.so.2
>> (0x00007ddd7438e000)
>> libgnutls.so.30 => /lib/x86_64-linux-gnu/libgnutls.so.30
>> (0x00007ddd74194000)
>> libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1
>> (0x00007ddd74e15000)
>> libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2
>> (0x00007ddd74181000)
>> libp11-kit.so.0 => /lib/x86_64-linux-gnu/libp11-kit.so.0
>> (0x00007ddd73fdd000)
>> libidn2.so.0 => /lib/x86_64-linux-gnu/libidn2.so.0
>> (0x00007ddd73fbb000)
>> libunistring.so.5 => /lib/x86_64-linux-gnu/libunistring.so.5
>> (0x00007ddd73e0e000)
>> libtasn1.so.6 => /lib/x86_64-linux-gnu/libtasn1.so.6
>> (0x00007ddd73df8000)
>> libnettle.so.8 => /lib/x86_64-linux-gnu/libnettle.so.8
>> (0x00007ddd73da3000)
>> libhogweed.so.6 => /lib/x86_64-linux-gnu/libhogweed.so.6
>> (0x00007ddd73d5b000)
>> libgmp.so.10 => /lib/x86_64-linux-gnu/libgmp.so.10
>> (0x00007ddd73cd7000)
>> libffi.so.8 => /lib/x86_64-linux-gnu/libffi.so.8
>> (0x00007ddd73ccb000)
>>
>>
>> Running nm (list symbols from object files) on the
>> /usr/lib/x86_64-linux-gnu/naviserver/bin/nsdbpg.so doesn't provide any
>> feedback about having the the _Ns_ModuleInit symbol.
>>
>> See here:
>> ..
>> ..
>> ..
>> ..
>>
>> 0000000000004d50 t AddCmds
>> 0000000000004260 t BindRow
>> 00000000000077f0 t blob_dml_file
>> 0000000000007200 t blob_get
>> 00000000000075e0 t blob_put
>> 00000000000072e0 t blob_send_to_stream
>> 00000000000041e0 t CloseDb
>> U close@GLIBC_2.2.5
>> 000000000000b068 b completed.0
>> U __ctype_b_loc@GLIBC_2.3
>> w __cxa_finalize@GLIBC_2.2.5
>> 000000000000b070 b dateStyle
>> 0000000000006870 t DbFail
>> 0000000000003f50 t DbType
>> 0000000000007c70 t decode3
>> 0000000000003ce0 t deregister_tm_clones
>> 0000000000003d50 t __do_global_dtors_aux
>> 000000000000a8d8 d __do_global_dtors_aux_fini_array_entry
>> 000000000000b000 d __dso_handle
>> 000000000000aa30 d _DYNAMIC
>> 0000000000007b60 t encode3
>> 0000000000007b30 t enc_one
>> U __errno_location@GLIBC_2.2.5
>> 0000000000004370 t Exec
>> 0000000000007d5c t _fini
>> 0000000000004980 t Flush
>> 0000000000003d90 t frame_dummy
>> 000000000000a8d0 d __frame_dummy_init_array_entry
>> 00000000000093a0 r __FRAME_END__
>> 0000000000006fb0 t get_blob_tuples
>> U getenv@GLIBC_2.2.5
>> 0000000000007c50 t get_one
>> 0000000000004740 t GetRow
>> 0000000000004940 t GetRowCount
>> 000000000000ac60 d _GLOBAL_OFFSET_TABLE_
>> w __gmon_start__
>> 0000000000008b50 r __GNU_EH_FRAME_HDR
>> 000000000000b078 b id
>> 0000000000003000 t _init
>> 000000000000b080 b intTypePtr
>> U __isoc23_strtol@GLIBC_2.38
>> w _ITM_deregisterTMCloneTable
>> w _ITM_registerTMCloneTable
>> 0000000000007a80 t linkedListElement_new
>> 0000000000007ae0 t LinkedList_free_list
>> 0000000000007ab0 t LinkedList_len
>> 0000000000005370 t ListElementExternal
>> U ns_calloc
>> U Ns_ConfigGetValue
>> U Ns_ConnContentSent
>> U Ns_ConnWriteData
>> U Ns_Db0or1Row
>> U Ns_Db1Row
>> U Ns_DbDML
>> 0000000000003da0 T Ns_DbDriverInit
>> U Ns_DbDriverName
>> U Ns_DbExec
>> U Ns_DbGetMinDuration
>> 00000000000052c4 N nsdbpg.c.6eb8844b
>> U Ns_DbRegisterDriver
>> U Ns_DbSelect
>> U Ns_DbSetException
>> U Ns_DiffTime
>> U Ns_DStringExport
>> U Ns_DStringPrintf
>> U NS_EMPTY_STRING
>> U ns_free
>> U Ns_GetTime
>> U Ns_HttpParseHost2
>> U Ns_Log
>> U Ns_LogSeverityEnabled
>> U Ns_LogSqlDebug
>> U ns_malloc
>> 0000000000008000 R Ns_ModuleVersion
>> U Ns_ObjvArgs
>> U Ns_ObjvObj
>> U Ns_ObjvSet
>> U Ns_ObjvString
>> U Ns_ParseObjv
>> 0000000000004d00 T Ns_PgServerInit
>> U Ns_SetClearValues
>> U Ns_SetFree
>> U Ns_SetGet
>> U Ns_SetPutSz
>> U Ns_SetPutValueSz
>> U Ns_SubcmdObjv
>> U Ns_TclDbGetHandle
>> U Ns_TclEnterSet
>> U Ns_TclGetConn
>> U Ns_TclPrintfResult
>> U Ns_TclRegisterTrace
>> 0000000000003f60 t OpenDb
>> U open@GLIBC_2.2.5
>> 0000000000006a30 t parse_bind_variables
>> 0000000000005260 t ParsedSQLDupInternalRep
>> 00000000000051f0 t ParsedSQLFreeInternalRep
>> 000000000000b040 d ParsedSQLObjType
>> 00000000000052d0 t ParsedSQLSetFromAny
>> 00000000000058a0 t PgBindDmlObjCmd
>> 0000000000005fd0 t PgBindExecObjCmd
>> 00000000000061e0 t PgBindObjCmd
>> 0000000000005a50 t PgBindOneRowObjCmd
>> 0000000000005e10 t PgBindSelectObjCmd
>> 0000000000005c20 t PgBindZeroOrOneRowObjCmd
>> 000000000000b020 D pgDbName
>> 0000000000004dc0 t PgObjCmd
>> 0000000000006440 t PgPrepareObjCmd
>> U PQbackendPID
>> U PQclear
>> U PQcmdTuples
>> U PQdb
>> U PQerrorMessage
>> U PQexec
>> U PQfinish
>> U PQfname
>> U PQfreemem
>> U PQftype
>> U PQgetlength
>> U PQgetvalue
>> U PQhost
>> U PQlibVersion
>> U PQnfields
>> U PQntuples
>> U PQoptions
>> U PQport
>> U PQresultErrorMessage
>> U PQresultStatus
>> U PQsetdbLogin
>> U PQstatus
>> U PQunescapeBytea
>> 000000000000a960 d procs
>> U read@GLIBC_2.2.5
>> 0000000000003d10 t register_tm_clones
>> 00000000000049f0 t ResetHandle
>> 0000000000004a90 t SetTransactionState
>> U __snprintf_chk@GLIBC_2.3.4
>> U __sprintf_chk@GLIBC_2.3.4
>> 00000000000053c0 t SqlObjToString
>> U __stack_chk_fail@GLIBC_2.4
>> U strcasecmp@GLIBC_2.2.5
>> U __strcat_chk@GLIBC_2.3.4
>> U strchr@GLIBC_2.2.5
>> U strcmp@GLIBC_2.2.5
>> U __strcpy_chk@GLIBC_2.3.4
>> U strerror@GLIBC_2.2.5
>> U strlen@GLIBC_2.2.5
>> U strncasecmp@GLIBC_2.2.5
>> 000000000000a8e0 d subcmds.0
>> 00000000000062e1 N tclcmds.c.1cb70ca1
>> U Tcl_ConvertToType
>> U Tcl_CreateObjCommand
>> U Tcl_DictObjPut
>> U Tcl_DStringAppend
>> U Tcl_DStringFree
>> U Tcl_DStringInit
>> U Tcl_DStringResult
>> U Tcl_DStringSetLength
>> U Tcl_ExternalToUtfDString
>> U Tcl_GetByteArrayFromObj
>> U Tcl_GetIndexFromObjStruct
>> U Tcl_GetObjType
>> U Tcl_GetString
>> U Tcl_GetStringFromObj
>> U Tcl_GetVar2Ex
>> U Tcl_ListObjAppendElement
>> U Tcl_NewByteArrayObj
>> U Tcl_NewDictObj
>> U Tcl_NewIntObj
>> U Tcl_NewListObj
>> U Tcl_NewStringObj
>> U Tcl_Panic
>> U Tcl_SetObjResult
>> U Tcl_UtfToExternalDString
>> U Tcl_WrongNumArgs
>> 000000000000b068 d __TMC_END__
>> U write@GLIBC_2.2.5
>> 0000000000007560 t write_to_stream
>>
>>
>> Am I missing something ? or there is an issue with the Code?
>> [image: image.png]
>>
>>
>> Thanks
>> Regards,
>>
>> Sassy Natan
>> 972-(0)54-2203702
>>
>
>
> --
> Regards,
>
> Sassy Natan
> 972-(0)54-2203702
>
--
Regards,
Sassy Natan
972-(0)54-2203702
|
|
From: Sassy N. <sa...@gm...> - 2024-11-25 09:33:40
|
Please ignore... I forgot to load the nsdb.so module... All good :-) Thank You. On Mon, Nov 25, 2024 at 11:22 AM Sassy Natan <sa...@gm...> wrote: > Hi Group, > > I was trying to install naviserver 4.99.31-1 on my ubuntu 24.04 server. > I can provide to the community a debian package I have built to support > this project (see attached picture). > > However, It seems that I have an issue with the naviserver-nsdbpg module. > > I'm using postgresql-17 (17.2-1.pgdg24.04) on this server, and I was > successfully build the nsdbpg module using "make > PGLIB=$/usr/lib/postgresql/17/lib/ PGINCLUDE=/usr/include/postgresql/". > > The nsdbpg.so file was created successfully with no error on the > compilation and linkage. > > When trying to load naviserver I'm getting the following error message: > > Error: modload: /usr/lib/x86_64-linux-gnu/naviserver/bin/nsdbpg.so: > cannot find symbol "Ns_ModuleInit": > /usr/lib/x86_64-linux-gnu/naviserver/bin/nsdbpg.so: undefined symbol: > _Ns_ModuleInit > > Running ldd on the file /usr/lib/x86_64-linux-gnu/naviserver/bin/nsdbpg.so > provide this output: > > linux-vdso.so.1 (0x00007fff676fc000) > libnsdb-4.99.31.so.1 => /lib/x86_64-linux-gnu/libnsdb-4.99.31.so.1 > (0x00007ddd751af000) > libpq.so.5 => /lib/x86_64-linux-gnu/libpq.so.5 (0x00007ddd75158000) > libnsthread-4.99.31.so.1 => > /lib/x86_64-linux-gnu/libnsthread-4.99.31.so.1 (0x00007ddd7514c000) > libnsd-4.99.31.so.1 => /lib/x86_64-linux-gnu/libnsd-4.99.31.so.1 > (0x00007ddd75047000) > libtcl8.6.so => /lib/x86_64-linux-gnu/libtcl8.6.so > (0x00007ddd74e9a000) > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ddd74c00000) > libssl.so.3 => /lib/x86_64-linux-gnu/libssl.so.3 > (0x00007ddd74b56000) > libcrypto.so.3 => /lib/x86_64-linux-gnu/libcrypto.so.3 > (0x00007ddd74600000) > libgssapi_krb5.so.2 => /lib/x86_64-linux-gnu/libgssapi_krb5.so.2 > (0x00007ddd74e44000) > libldap.so.2 => /lib/x86_64-linux-gnu/libldap.so.2 > (0x00007ddd745a3000) > libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007ddd74e26000) > libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 > (0x00007ddd74b1c000) > libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ddd744ba000) > /lib64/ld-linux-x86-64.so.2 (0x00007ddd751d5000) > libkrb5.so.3 => /lib/x86_64-linux-gnu/libkrb5.so.3 > (0x00007ddd743f1000) > libk5crypto.so.3 => /lib/x86_64-linux-gnu/libk5crypto.so.3 > (0x00007ddd743c5000) > libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 > (0x00007ddd74e1e000) > libkrb5support.so.0 => /lib/x86_64-linux-gnu/libkrb5support.so.0 > (0x00007ddd743b8000) > liblber.so.2 => /lib/x86_64-linux-gnu/liblber.so.2 > (0x00007ddd743a8000) > libsasl2.so.2 => /lib/x86_64-linux-gnu/libsasl2.so.2 > (0x00007ddd7438e000) > libgnutls.so.30 => /lib/x86_64-linux-gnu/libgnutls.so.30 > (0x00007ddd74194000) > libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1 > (0x00007ddd74e15000) > libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 > (0x00007ddd74181000) > libp11-kit.so.0 => /lib/x86_64-linux-gnu/libp11-kit.so.0 > (0x00007ddd73fdd000) > libidn2.so.0 => /lib/x86_64-linux-gnu/libidn2.so.0 > (0x00007ddd73fbb000) > libunistring.so.5 => /lib/x86_64-linux-gnu/libunistring.so.5 > (0x00007ddd73e0e000) > libtasn1.so.6 => /lib/x86_64-linux-gnu/libtasn1.so.6 > (0x00007ddd73df8000) > libnettle.so.8 => /lib/x86_64-linux-gnu/libnettle.so.8 > (0x00007ddd73da3000) > libhogweed.so.6 => /lib/x86_64-linux-gnu/libhogweed.so.6 > (0x00007ddd73d5b000) > libgmp.so.10 => /lib/x86_64-linux-gnu/libgmp.so.10 > (0x00007ddd73cd7000) > libffi.so.8 => /lib/x86_64-linux-gnu/libffi.so.8 > (0x00007ddd73ccb000) > > > Running nm (list symbols from object files) on the > /usr/lib/x86_64-linux-gnu/naviserver/bin/nsdbpg.so doesn't provide any > feedback about having the the _Ns_ModuleInit symbol. > > See here: > .. > .. > .. > .. > > 0000000000004d50 t AddCmds > 0000000000004260 t BindRow > 00000000000077f0 t blob_dml_file > 0000000000007200 t blob_get > 00000000000075e0 t blob_put > 00000000000072e0 t blob_send_to_stream > 00000000000041e0 t CloseDb > U close@GLIBC_2.2.5 > 000000000000b068 b completed.0 > U __ctype_b_loc@GLIBC_2.3 > w __cxa_finalize@GLIBC_2.2.5 > 000000000000b070 b dateStyle > 0000000000006870 t DbFail > 0000000000003f50 t DbType > 0000000000007c70 t decode3 > 0000000000003ce0 t deregister_tm_clones > 0000000000003d50 t __do_global_dtors_aux > 000000000000a8d8 d __do_global_dtors_aux_fini_array_entry > 000000000000b000 d __dso_handle > 000000000000aa30 d _DYNAMIC > 0000000000007b60 t encode3 > 0000000000007b30 t enc_one > U __errno_location@GLIBC_2.2.5 > 0000000000004370 t Exec > 0000000000007d5c t _fini > 0000000000004980 t Flush > 0000000000003d90 t frame_dummy > 000000000000a8d0 d __frame_dummy_init_array_entry > 00000000000093a0 r __FRAME_END__ > 0000000000006fb0 t get_blob_tuples > U getenv@GLIBC_2.2.5 > 0000000000007c50 t get_one > 0000000000004740 t GetRow > 0000000000004940 t GetRowCount > 000000000000ac60 d _GLOBAL_OFFSET_TABLE_ > w __gmon_start__ > 0000000000008b50 r __GNU_EH_FRAME_HDR > 000000000000b078 b id > 0000000000003000 t _init > 000000000000b080 b intTypePtr > U __isoc23_strtol@GLIBC_2.38 > w _ITM_deregisterTMCloneTable > w _ITM_registerTMCloneTable > 0000000000007a80 t linkedListElement_new > 0000000000007ae0 t LinkedList_free_list > 0000000000007ab0 t LinkedList_len > 0000000000005370 t ListElementExternal > U ns_calloc > U Ns_ConfigGetValue > U Ns_ConnContentSent > U Ns_ConnWriteData > U Ns_Db0or1Row > U Ns_Db1Row > U Ns_DbDML > 0000000000003da0 T Ns_DbDriverInit > U Ns_DbDriverName > U Ns_DbExec > U Ns_DbGetMinDuration > 00000000000052c4 N nsdbpg.c.6eb8844b > U Ns_DbRegisterDriver > U Ns_DbSelect > U Ns_DbSetException > U Ns_DiffTime > U Ns_DStringExport > U Ns_DStringPrintf > U NS_EMPTY_STRING > U ns_free > U Ns_GetTime > U Ns_HttpParseHost2 > U Ns_Log > U Ns_LogSeverityEnabled > U Ns_LogSqlDebug > U ns_malloc > 0000000000008000 R Ns_ModuleVersion > U Ns_ObjvArgs > U Ns_ObjvObj > U Ns_ObjvSet > U Ns_ObjvString > U Ns_ParseObjv > 0000000000004d00 T Ns_PgServerInit > U Ns_SetClearValues > U Ns_SetFree > U Ns_SetGet > U Ns_SetPutSz > U Ns_SetPutValueSz > U Ns_SubcmdObjv > U Ns_TclDbGetHandle > U Ns_TclEnterSet > U Ns_TclGetConn > U Ns_TclPrintfResult > U Ns_TclRegisterTrace > 0000000000003f60 t OpenDb > U open@GLIBC_2.2.5 > 0000000000006a30 t parse_bind_variables > 0000000000005260 t ParsedSQLDupInternalRep > 00000000000051f0 t ParsedSQLFreeInternalRep > 000000000000b040 d ParsedSQLObjType > 00000000000052d0 t ParsedSQLSetFromAny > 00000000000058a0 t PgBindDmlObjCmd > 0000000000005fd0 t PgBindExecObjCmd > 00000000000061e0 t PgBindObjCmd > 0000000000005a50 t PgBindOneRowObjCmd > 0000000000005e10 t PgBindSelectObjCmd > 0000000000005c20 t PgBindZeroOrOneRowObjCmd > 000000000000b020 D pgDbName > 0000000000004dc0 t PgObjCmd > 0000000000006440 t PgPrepareObjCmd > U PQbackendPID > U PQclear > U PQcmdTuples > U PQdb > U PQerrorMessage > U PQexec > U PQfinish > U PQfname > U PQfreemem > U PQftype > U PQgetlength > U PQgetvalue > U PQhost > U PQlibVersion > U PQnfields > U PQntuples > U PQoptions > U PQport > U PQresultErrorMessage > U PQresultStatus > U PQsetdbLogin > U PQstatus > U PQunescapeBytea > 000000000000a960 d procs > U read@GLIBC_2.2.5 > 0000000000003d10 t register_tm_clones > 00000000000049f0 t ResetHandle > 0000000000004a90 t SetTransactionState > U __snprintf_chk@GLIBC_2.3.4 > U __sprintf_chk@GLIBC_2.3.4 > 00000000000053c0 t SqlObjToString > U __stack_chk_fail@GLIBC_2.4 > U strcasecmp@GLIBC_2.2.5 > U __strcat_chk@GLIBC_2.3.4 > U strchr@GLIBC_2.2.5 > U strcmp@GLIBC_2.2.5 > U __strcpy_chk@GLIBC_2.3.4 > U strerror@GLIBC_2.2.5 > U strlen@GLIBC_2.2.5 > U strncasecmp@GLIBC_2.2.5 > 000000000000a8e0 d subcmds.0 > 00000000000062e1 N tclcmds.c.1cb70ca1 > U Tcl_ConvertToType > U Tcl_CreateObjCommand > U Tcl_DictObjPut > U Tcl_DStringAppend > U Tcl_DStringFree > U Tcl_DStringInit > U Tcl_DStringResult > U Tcl_DStringSetLength > U Tcl_ExternalToUtfDString > U Tcl_GetByteArrayFromObj > U Tcl_GetIndexFromObjStruct > U Tcl_GetObjType > U Tcl_GetString > U Tcl_GetStringFromObj > U Tcl_GetVar2Ex > U Tcl_ListObjAppendElement > U Tcl_NewByteArrayObj > U Tcl_NewDictObj > U Tcl_NewIntObj > U Tcl_NewListObj > U Tcl_NewStringObj > U Tcl_Panic > U Tcl_SetObjResult > U Tcl_UtfToExternalDString > U Tcl_WrongNumArgs > 000000000000b068 d __TMC_END__ > U write@GLIBC_2.2.5 > 0000000000007560 t write_to_stream > > > Am I missing something ? or there is an issue with the Code? > [image: image.png] > > > Thanks > Regards, > > Sassy Natan > 972-(0)54-2203702 > -- Regards, Sassy Natan 972-(0)54-2203702 |
|
From: Sassy N. <sa...@gm...> - 2024-11-25 09:22:26
|
Hi Group,
I was trying to install naviserver 4.99.31-1 on my ubuntu 24.04 server.
I can provide to the community a debian package I have built to support
this project (see attached picture).
However, It seems that I have an issue with the naviserver-nsdbpg module.
I'm using postgresql-17 (17.2-1.pgdg24.04) on this server, and I was
successfully build the nsdbpg module using "make
PGLIB=$/usr/lib/postgresql/17/lib/ PGINCLUDE=/usr/include/postgresql/".
The nsdbpg.so file was created successfully with no error on the
compilation and linkage.
When trying to load naviserver I'm getting the following error message:
Error: modload: /usr/lib/x86_64-linux-gnu/naviserver/bin/nsdbpg.so: cannot
find symbol "Ns_ModuleInit":
/usr/lib/x86_64-linux-gnu/naviserver/bin/nsdbpg.so: undefined symbol:
_Ns_ModuleInit
Running ldd on the file /usr/lib/x86_64-linux-gnu/naviserver/bin/nsdbpg.so
provide this output:
linux-vdso.so.1 (0x00007fff676fc000)
libnsdb-4.99.31.so.1 => /lib/x86_64-linux-gnu/libnsdb-4.99.31.so.1
(0x00007ddd751af000)
libpq.so.5 => /lib/x86_64-linux-gnu/libpq.so.5 (0x00007ddd75158000)
libnsthread-4.99.31.so.1 =>
/lib/x86_64-linux-gnu/libnsthread-4.99.31.so.1 (0x00007ddd7514c000)
libnsd-4.99.31.so.1 => /lib/x86_64-linux-gnu/libnsd-4.99.31.so.1
(0x00007ddd75047000)
libtcl8.6.so => /lib/x86_64-linux-gnu/libtcl8.6.so
(0x00007ddd74e9a000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ddd74c00000)
libssl.so.3 => /lib/x86_64-linux-gnu/libssl.so.3
(0x00007ddd74b56000)
libcrypto.so.3 => /lib/x86_64-linux-gnu/libcrypto.so.3
(0x00007ddd74600000)
libgssapi_krb5.so.2 => /lib/x86_64-linux-gnu/libgssapi_krb5.so.2
(0x00007ddd74e44000)
libldap.so.2 => /lib/x86_64-linux-gnu/libldap.so.2
(0x00007ddd745a3000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007ddd74e26000)
libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1
(0x00007ddd74b1c000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ddd744ba000)
/lib64/ld-linux-x86-64.so.2 (0x00007ddd751d5000)
libkrb5.so.3 => /lib/x86_64-linux-gnu/libkrb5.so.3
(0x00007ddd743f1000)
libk5crypto.so.3 => /lib/x86_64-linux-gnu/libk5crypto.so.3
(0x00007ddd743c5000)
libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2
(0x00007ddd74e1e000)
libkrb5support.so.0 => /lib/x86_64-linux-gnu/libkrb5support.so.0
(0x00007ddd743b8000)
liblber.so.2 => /lib/x86_64-linux-gnu/liblber.so.2
(0x00007ddd743a8000)
libsasl2.so.2 => /lib/x86_64-linux-gnu/libsasl2.so.2
(0x00007ddd7438e000)
libgnutls.so.30 => /lib/x86_64-linux-gnu/libgnutls.so.30
(0x00007ddd74194000)
libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1
(0x00007ddd74e15000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2
(0x00007ddd74181000)
libp11-kit.so.0 => /lib/x86_64-linux-gnu/libp11-kit.so.0
(0x00007ddd73fdd000)
libidn2.so.0 => /lib/x86_64-linux-gnu/libidn2.so.0
(0x00007ddd73fbb000)
libunistring.so.5 => /lib/x86_64-linux-gnu/libunistring.so.5
(0x00007ddd73e0e000)
libtasn1.so.6 => /lib/x86_64-linux-gnu/libtasn1.so.6
(0x00007ddd73df8000)
libnettle.so.8 => /lib/x86_64-linux-gnu/libnettle.so.8
(0x00007ddd73da3000)
libhogweed.so.6 => /lib/x86_64-linux-gnu/libhogweed.so.6
(0x00007ddd73d5b000)
libgmp.so.10 => /lib/x86_64-linux-gnu/libgmp.so.10
(0x00007ddd73cd7000)
libffi.so.8 => /lib/x86_64-linux-gnu/libffi.so.8
(0x00007ddd73ccb000)
Running nm (list symbols from object files) on the
/usr/lib/x86_64-linux-gnu/naviserver/bin/nsdbpg.so doesn't provide any
feedback about having the the _Ns_ModuleInit symbol.
See here:
..
..
..
..
0000000000004d50 t AddCmds
0000000000004260 t BindRow
00000000000077f0 t blob_dml_file
0000000000007200 t blob_get
00000000000075e0 t blob_put
00000000000072e0 t blob_send_to_stream
00000000000041e0 t CloseDb
U close@GLIBC_2.2.5
000000000000b068 b completed.0
U __ctype_b_loc@GLIBC_2.3
w __cxa_finalize@GLIBC_2.2.5
000000000000b070 b dateStyle
0000000000006870 t DbFail
0000000000003f50 t DbType
0000000000007c70 t decode3
0000000000003ce0 t deregister_tm_clones
0000000000003d50 t __do_global_dtors_aux
000000000000a8d8 d __do_global_dtors_aux_fini_array_entry
000000000000b000 d __dso_handle
000000000000aa30 d _DYNAMIC
0000000000007b60 t encode3
0000000000007b30 t enc_one
U __errno_location@GLIBC_2.2.5
0000000000004370 t Exec
0000000000007d5c t _fini
0000000000004980 t Flush
0000000000003d90 t frame_dummy
000000000000a8d0 d __frame_dummy_init_array_entry
00000000000093a0 r __FRAME_END__
0000000000006fb0 t get_blob_tuples
U getenv@GLIBC_2.2.5
0000000000007c50 t get_one
0000000000004740 t GetRow
0000000000004940 t GetRowCount
000000000000ac60 d _GLOBAL_OFFSET_TABLE_
w __gmon_start__
0000000000008b50 r __GNU_EH_FRAME_HDR
000000000000b078 b id
0000000000003000 t _init
000000000000b080 b intTypePtr
U __isoc23_strtol@GLIBC_2.38
w _ITM_deregisterTMCloneTable
w _ITM_registerTMCloneTable
0000000000007a80 t linkedListElement_new
0000000000007ae0 t LinkedList_free_list
0000000000007ab0 t LinkedList_len
0000000000005370 t ListElementExternal
U ns_calloc
U Ns_ConfigGetValue
U Ns_ConnContentSent
U Ns_ConnWriteData
U Ns_Db0or1Row
U Ns_Db1Row
U Ns_DbDML
0000000000003da0 T Ns_DbDriverInit
U Ns_DbDriverName
U Ns_DbExec
U Ns_DbGetMinDuration
00000000000052c4 N nsdbpg.c.6eb8844b
U Ns_DbRegisterDriver
U Ns_DbSelect
U Ns_DbSetException
U Ns_DiffTime
U Ns_DStringExport
U Ns_DStringPrintf
U NS_EMPTY_STRING
U ns_free
U Ns_GetTime
U Ns_HttpParseHost2
U Ns_Log
U Ns_LogSeverityEnabled
U Ns_LogSqlDebug
U ns_malloc
0000000000008000 R Ns_ModuleVersion
U Ns_ObjvArgs
U Ns_ObjvObj
U Ns_ObjvSet
U Ns_ObjvString
U Ns_ParseObjv
0000000000004d00 T Ns_PgServerInit
U Ns_SetClearValues
U Ns_SetFree
U Ns_SetGet
U Ns_SetPutSz
U Ns_SetPutValueSz
U Ns_SubcmdObjv
U Ns_TclDbGetHandle
U Ns_TclEnterSet
U Ns_TclGetConn
U Ns_TclPrintfResult
U Ns_TclRegisterTrace
0000000000003f60 t OpenDb
U open@GLIBC_2.2.5
0000000000006a30 t parse_bind_variables
0000000000005260 t ParsedSQLDupInternalRep
00000000000051f0 t ParsedSQLFreeInternalRep
000000000000b040 d ParsedSQLObjType
00000000000052d0 t ParsedSQLSetFromAny
00000000000058a0 t PgBindDmlObjCmd
0000000000005fd0 t PgBindExecObjCmd
00000000000061e0 t PgBindObjCmd
0000000000005a50 t PgBindOneRowObjCmd
0000000000005e10 t PgBindSelectObjCmd
0000000000005c20 t PgBindZeroOrOneRowObjCmd
000000000000b020 D pgDbName
0000000000004dc0 t PgObjCmd
0000000000006440 t PgPrepareObjCmd
U PQbackendPID
U PQclear
U PQcmdTuples
U PQdb
U PQerrorMessage
U PQexec
U PQfinish
U PQfname
U PQfreemem
U PQftype
U PQgetlength
U PQgetvalue
U PQhost
U PQlibVersion
U PQnfields
U PQntuples
U PQoptions
U PQport
U PQresultErrorMessage
U PQresultStatus
U PQsetdbLogin
U PQstatus
U PQunescapeBytea
000000000000a960 d procs
U read@GLIBC_2.2.5
0000000000003d10 t register_tm_clones
00000000000049f0 t ResetHandle
0000000000004a90 t SetTransactionState
U __snprintf_chk@GLIBC_2.3.4
U __sprintf_chk@GLIBC_2.3.4
00000000000053c0 t SqlObjToString
U __stack_chk_fail@GLIBC_2.4
U strcasecmp@GLIBC_2.2.5
U __strcat_chk@GLIBC_2.3.4
U strchr@GLIBC_2.2.5
U strcmp@GLIBC_2.2.5
U __strcpy_chk@GLIBC_2.3.4
U strerror@GLIBC_2.2.5
U strlen@GLIBC_2.2.5
U strncasecmp@GLIBC_2.2.5
000000000000a8e0 d subcmds.0
00000000000062e1 N tclcmds.c.1cb70ca1
U Tcl_ConvertToType
U Tcl_CreateObjCommand
U Tcl_DictObjPut
U Tcl_DStringAppend
U Tcl_DStringFree
U Tcl_DStringInit
U Tcl_DStringResult
U Tcl_DStringSetLength
U Tcl_ExternalToUtfDString
U Tcl_GetByteArrayFromObj
U Tcl_GetIndexFromObjStruct
U Tcl_GetObjType
U Tcl_GetString
U Tcl_GetStringFromObj
U Tcl_GetVar2Ex
U Tcl_ListObjAppendElement
U Tcl_NewByteArrayObj
U Tcl_NewDictObj
U Tcl_NewIntObj
U Tcl_NewListObj
U Tcl_NewStringObj
U Tcl_Panic
U Tcl_SetObjResult
U Tcl_UtfToExternalDString
U Tcl_WrongNumArgs
000000000000b068 d __TMC_END__
U write@GLIBC_2.2.5
0000000000007560 t write_to_stream
Am I missing something ? or there is an issue with the Code?
[image: image.png]
Thanks
Regards,
Sassy Natan
972-(0)54-2203702
|
|
From: Brian F. <bri...@ai...> - 2024-11-22 15:12:28
|
Thank you Gustaf for all your incredible work.
Regarding the commands you wish to deprecate, I see that we are still using ns_formvalueput in some very old, but still used, code.
All the best
Brian
________________________________
From: Gustaf Neumann (sslmail) <ne...@wu...>
Sent: Friday 22 November 2024 10:19 am
To: nav...@li... <nav...@li...>
Subject: Re: [naviserver-devel] ns_set reform
Dear all,
>From the previously state goals:
> 1) all commands tested in the regression test should be documented
> 2) all documented commands should be tested (at least syntax-tested)
> 3) all implemented commands should be tested
> 4) the parameters of the implemented commands should be documented and vice versa.
> 5) deprecated commands should be listed in the deprecated section of the command listing in the documentation, but not advertised in the documentation
At least 1 and 2 are finished by today. This week, i have added over 700 tests to the regression test, which was hard work and took all my resources. We have now 2608 tests in the NaviServer 5 regression test vs. 1893 in the newest 4.99 branch:
% egrep -r --include=*.test '^test ' /usr/local/src/naviserver/ |wc -l
2608
% egrep -r --include=*.test '^test ' /usr/local/src/naviserver-4.99/ |wc -l
1893
The current state is not perfect, but a progress.
Tested commands not documented
------------> 706 tested commands, 72 deprecated, 648 documented, 0 NOT documented
Documented commands not tested
------------> 648 documented commands, 648 tested, 0 NOT tested
Deprecated commands which are documented
------------> 0 deprecated commands are documented
The next goal is to check the alignment of the argument lists of the implementation with the documentation.
On my wishlist is also a non-deprecated mode switchable via configuration file, where NaviServer offers only non-deprecated commands.
In the meanwhile, something to think about for you: We have still a bunch of commands, which have a questionable future. These commands are in a "TBD" state for 19 years.
I think, we should deprecate these commands (see below for the list) in the NaviServer 5 release.
Please speak up, if your applications need these:
ns_browsermatch
ns_choosecharset
ns_cookiecharset
ns_formfieldcharset
ns_formvalueput
ns_paren
ns_tagelement
ns_tagelementset
All the best
-g
|
|
From: Sassy N. <sa...@gm...> - 2024-11-22 13:02:51
|
Thank you. This project is so impressive and was really introduced things head off its time. I’m working with Navi since 2002 when node js, python and all other new programming languages was never adapted the method of being the web server embedded in the language itself. AOL or Navi was from day one like this. When is the plan to release version 5.0? Regards, Sassy Natan 972-(0)54-2203702 On Fri, 22 Nov 2024 at 12:25 Maksym Zinchenko <siq...@gm...> wrote: > Hello, thank you for hard work. And I think nobody using this commands any > more. > > On Fri, 22 Nov 2024, 09:20 Gustaf Neumann (sslmail), <ne...@wu...> > wrote: > >> Dear all, >> >> From the previously state goals: >> >> > 1) all commands tested in the regression test should be documented >> > 2) all documented commands should be tested (at least syntax-tested) >> > 3) all implemented commands should be tested >> > 4) the parameters of the implemented commands should be documented >> and vice versa. >> > 5) deprecated commands should be listed in the deprecated section of >> the command listing in the documentation, but not advertised in the >> documentation >> >> At least 1 and 2 are finished by today. This week, i have added over 700 >> tests to the regression test, which was hard work and took all my >> resources. We have now 2608 tests in the NaviServer 5 regression test vs. >> 1893 in the newest 4.99 branch: >> >> % egrep -r --include=*.test '^test ' /usr/local/src/naviserver/ |wc -l >> 2608 >> >> % egrep -r --include=*.test '^test ' /usr/local/src/naviserver-4.99/ |wc >> -l >> 1893 >> >> >> The current state is not perfect, but a progress. >> >> Tested commands not documented >> ------------> 706 tested commands, 72 deprecated, 648 documented, 0 NOT >> documented >> >> Documented commands not tested >> ------------> 648 documented commands, 648 tested, 0 NOT tested >> >> Deprecated commands which are documented >> ------------> 0 deprecated commands are documented >> >> >> The next goal is to check the alignment of the argument lists of the >> implementation with the documentation. >> >> On my wishlist is also a non-deprecated mode switchable via configuration >> file, where NaviServer offers only non-deprecated commands. >> >> In the meanwhile, something to think about for you: We have still a bunch >> of commands, which have a questionable future. These commands are in a >> "TBD" state for 19 years. >> >> I think, we should deprecate these commands (see below for the list) in >> the NaviServer 5 release. >> Please speak up, if your applications need these: >> >> ns_browsermatch >> ns_choosecharset >> ns_cookiecharset >> ns_formfieldcharset >> ns_formvalueput >> ns_paren >> ns_tagelement >> ns_tagelementset >> >> All the best >> -g >> _______________________________________________ >> naviserver-devel mailing list >> nav...@li... >> https://lists.sourceforge.net/lists/listinfo/naviserver-devel >> > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > |
|
From: Maksym Z. <siq...@gm...> - 2024-11-22 10:25:09
|
Hello, thank you for hard work. And I think nobody using this commands any more. On Fri, 22 Nov 2024, 09:20 Gustaf Neumann (sslmail), <ne...@wu...> wrote: > Dear all, > > From the previously state goals: > > > 1) all commands tested in the regression test should be documented > > 2) all documented commands should be tested (at least syntax-tested) > > 3) all implemented commands should be tested > > 4) the parameters of the implemented commands should be documented and > vice versa. > > 5) deprecated commands should be listed in the deprecated section of > the command listing in the documentation, but not advertised in the > documentation > > At least 1 and 2 are finished by today. This week, i have added over 700 > tests to the regression test, which was hard work and took all my > resources. We have now 2608 tests in the NaviServer 5 regression test vs. > 1893 in the newest 4.99 branch: > > % egrep -r --include=*.test '^test ' /usr/local/src/naviserver/ |wc -l > 2608 > > % egrep -r --include=*.test '^test ' /usr/local/src/naviserver-4.99/ |wc > -l > 1893 > > > The current state is not perfect, but a progress. > > Tested commands not documented > ------------> 706 tested commands, 72 deprecated, 648 documented, 0 NOT > documented > > Documented commands not tested > ------------> 648 documented commands, 648 tested, 0 NOT tested > > Deprecated commands which are documented > ------------> 0 deprecated commands are documented > > > The next goal is to check the alignment of the argument lists of the > implementation with the documentation. > > On my wishlist is also a non-deprecated mode switchable via configuration > file, where NaviServer offers only non-deprecated commands. > > In the meanwhile, something to think about for you: We have still a bunch > of commands, which have a questionable future. These commands are in a > "TBD" state for 19 years. > > I think, we should deprecate these commands (see below for the list) in > the NaviServer 5 release. > Please speak up, if your applications need these: > > ns_browsermatch > ns_choosecharset > ns_cookiecharset > ns_formfieldcharset > ns_formvalueput > ns_paren > ns_tagelement > ns_tagelementset > > All the best > -g > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > |
|
From: Gustaf N. (sslmail) <ne...@wu...> - 2024-11-22 10:19:48
|
Dear all,
From the previously state goals:
> 1) all commands tested in the regression test should be documented
> 2) all documented commands should be tested (at least syntax-tested)
> 3) all implemented commands should be tested
> 4) the parameters of the implemented commands should be documented and vice versa.
> 5) deprecated commands should be listed in the deprecated section of the command listing in the documentation, but not advertised in the documentation
At least 1 and 2 are finished by today. This week, i have added over 700 tests to the regression test, which was hard work and took all my resources. We have now 2608 tests in the NaviServer 5 regression test vs. 1893 in the newest 4.99 branch:
% egrep -r --include=*.test '^test ' /usr/local/src/naviserver/ |wc -l
2608
% egrep -r --include=*.test '^test ' /usr/local/src/naviserver-4.99/ |wc -l
1893
The current state is not perfect, but a progress.
Tested commands not documented
------------> 706 tested commands, 72 deprecated, 648 documented, 0 NOT documented
Documented commands not tested
------------> 648 documented commands, 648 tested, 0 NOT tested
Deprecated commands which are documented
------------> 0 deprecated commands are documented
The next goal is to check the alignment of the argument lists of the implementation with the documentation.
On my wishlist is also a non-deprecated mode switchable via configuration file, where NaviServer offers only non-deprecated commands.
In the meanwhile, something to think about for you: We have still a bunch of commands, which have a questionable future. These commands are in a "TBD" state for 19 years.
I think, we should deprecate these commands (see below for the list) in the NaviServer 5 release.
Please speak up, if your applications need these:
ns_browsermatch
ns_choosecharset
ns_cookiecharset
ns_formfieldcharset
ns_formvalueput
ns_paren
ns_tagelement
ns_tagelementset
All the best
-g |
|
From: Gustaf N. (sslmail) <ne...@wu...> - 2024-11-19 11:19:26
|
> However, based on a quick grep, there are still several hundred syntax tests missing. Some more precise data: We have in NaviServer altogether 638 (!) documented commands including subcommands, Especially there are still many subcommands, which are not syntax tested. Yesterday and today, i added about 100 further tests to the regression test. Current State: there are 422 documented commands tested, and 216 still not (syntax) tested. There is probably some more legacy stuff in the documentation that should be removed. all the best -g |
|
From: Gustaf N. (sslmail) <ne...@wu...> - 2024-11-18 10:44:34
|
Dear all, i’ve implemented the changes with case-insensitive ns_sets, and they are working nicely. These changes are highly backwards compatible, no changes were e.g. necessary for OpenACS. The new version is still verbose, when e.g. a “get” or “update” operation happens on a case-insensitive set (e.g. HTTP headers) to ease fixing such cases also for older NaviServer versions, but that will go away for the release, Below are the old and new man pages for “ns_set”, the new man page is mostly a rewrite. NaviServer 4.99: https://naviserver.sourceforge.io/4.99/naviserver/files/ns_set.html NaviServer 5: https://naviserver.sourceforge.io/5.0/naviserver/files/ns_set.html There are more places, where case-insensitive ns_sets should be used (ADP parser for attributes since HTML attributes are case-insensitive, or query-results from SQL), but I have not investigated enough for these. Inspired by the previous state of the documentation of ns_set, I addressed the long-standing issue, that in usage messages (when commands a called incorrectly), did not differentiate between literal command elements and placeholders. In the new version, placeholders are enclosed in slashes (/), making it evident which parts are variable inputs. OLD: ns_ip properties ipaddr NEW: ns_ip properties /ipaddr/ Similarly, the arguments of parameters in the usage messages were often not informative about possible values, which are now included were we have internally the information OLD: ns_getcookie ?-all all? ?-include_set_cookies include_set_cookies? ?--? name ?default? NEW: ns_getcookie ?-all true|false? ?-include_set_cookies true|false? ?--? /name/ ?default? OLD: ns_deletecookie ... ?-samesite samesite? … NEW: ns_deletecookie ... ?-samesite strict|lax|none? … For more details, see commit [1] . While i was at this area, i found many things in the documentation which should be fixed before the release. The goal for the release should be: 1) all commands tested in the regression test should be documented 2) all documented commands should be tested (at least syntax-tested) 3) all implemented commands should be tested 4) the parameters of the implemented commands should be documented and vice versa. 5) deprecated commands should be listed in the deprecated section of the command listing in the documentation, but not advertised in the documentation The state in previous releases (including AOLserver releases) is really not good. For example, we have commands documented which were removed at least 22 years ago from NaviServer(AOLserver), such as ns_db close ns_db open I have already added over 50 new tests to the regression test suite to cover usage messages. However, based on a quick grep, there are still several hundred syntax tests missing. If we don't address1-5 now, before the release of the new major version, it's highly likely that we never will. All the best. -g [1] https://github.com/naviserver-project/naviserver/commit/ffbd32774db1fe4a5b24a11b0032f144bec45cf7 > On 08.11.2024, at 17:35, Brian Fenton <bri...@ai...> wrote: > > This change sounds very welcome. I think we've all experienced the frustration of case-insensitive searching. > > One suggestion I have for the man page would be a beginner friendly example of iterating through the contents of an ns_set e.g. > > set headers [ns_conn headers] > set output "" > foreach {key value} [ns_set array $headers] { > append output "$key = $value \n" > } > set output > > I know we have ns_set print, but the first time I encountered sets an example like the above would have been helpful. |
|
From: Brian F. <bri...@ai...> - 2024-11-08 18:06:42
|
This change sounds very welcome. I think we've all experienced the frustration of case-insensitive searching.
One suggestion I have for the man page would be a beginner friendly example of iterating through the contents of an ns_set e.g.
set headers [ns_conn headers]
set output ""
foreach {key value} [ns_set array $headers] {
append output "$key = $value \n"
}
set output
I know we have ns_set print, but the first time I encountered sets an example like the above would have been helpful.
All the best
Brian
________________________________
From: Gustaf Neumann (sslmail) <ne...@wu...>
Sent: Thursday 7 November 2024 10:13 am
To: nav...@li... <nav...@li...>
Subject: [naviserver-devel] ns_set reform
Dear all,
The upcoming release of NaviServer 5 includes several enhancements to "ns_set", such as more efficient storage management and the addition of the "-all" option for "ns_set get" and "ns_set iget". I also plan to implement further improvements.
One common problem area is the handling of "ns_set" collections with case-insensitive keys (e.g., HTTP request and reply headers, or configuration values). Currently, developers must use the i* variants of commands whenever accessing or updating elements with case-insensitive keys.
This current approach has two main issues:
a) Semantic Issues: When a developer forgets to use the i* variant for such sets errors will occur that are difficult to debug. These errors may happen at both the C level and the Tcl level, affecting the main NaviServer code as well as the NaviServer modules. In the past few days, I have fixed more than ten such cases, which is why I am now addressing this issue.
b) Performance Issues: Using the i* variants (e.g., "ns_set iget”) leads to keys being searched sequentially using strcasecmp(). For a set with N elements, an average of N/2 strcasecmp() operations are performed per lookup or update operation. In other words, during each get/update/delete operation, approximately half of the dictionary is converted to lowercase. Additionally, the input key is repeatedly converted to lowercase. Benchmark comparisons indicate that strcasecmp() is 20 to 30 times slower than strcmp(). The heavy reliance on strcasecmp() in the implementation of Ns_Set certainly impacts performance.
To address these problems, I have added a property to the Ns_Set structure that allows it to be declared case-insensitive. With this property enabled, keys are stored in lowercase, enabling the use of
strcmp() instead of strcasemp() for comparisons. This change not only improves performance but also reduces the likelihood of semantic errors, as developers no longer need to remember to use the i* variants.
So far, I have made the configuration value sets and HTTP header sets case-insensitive:
- HTTP Headers: According to the RFC, the names of header fields are case-insensitive. Now, these headers are stored in lowercase, ensuring consistent behavior.
- Configuration Sets: Most operations were already case-insensitive, but a few were not, which I regard as bugs.
The Ns_Sets for both cases are created from the C level. The only behavioral change is that when obtaining all keys from such a set, they are now returned in lowercase. For case-insensitive sets, the operations "ns_set get" and "ns_set iget will" return the same results.
In future versions, we might consider other options for ns_sets, such as enforcing uniqueness or sorting. However, I do not regard these as important as the "-nocase" option for now.
Some preliminary data: For a single HTTP request in OpenACS, I count 1,672 strcasecmp() operations. By utilizing the "-nocase" options on HTTP headers and ns_config data, this number is reduced for the same request to just 195 operations per request. On some of our busier systems that process up to 1,000 requests per second, the nocase option on sets saves nearly 1.5 million strcasecmp() operations per second.
I am also considering adding a "-nocase" flag to the base operations (i.e. allowing "ns_set get -nocase ..." in addition to "ns_set iget ..."). The "-nocase" flag is common in the Tcl world and appears more familiar than using strange names like: "icput", "idelkey", "ifind”, "iget", "imerge", "iunique", and "iupdate",
Finally, the man page for "ns_set" is not very user-friendly, as the base case and the "-nocase" variant should be presented together and not require excessive scrolling. The i* variants will continue to work and might be marked as deprecated in the future.
As always, your input is welcome. If you have suggestions about maybe more annoying legacy operations, please let me know, the release change is a chance to address such things.
All the best
-g
_______________________________________________
naviserver-devel mailing list
nav...@li...
https://lists.sourceforge.net/lists/listinfo/naviserver-devel
|
|
From: Gustaf N. (sslmail) <ne...@wu...> - 2024-11-07 10:14:28
|
Dear all, The upcoming release of NaviServer 5 includes several enhancements to "ns_set", such as more efficient storage management and the addition of the "-all" option for "ns_set get" and "ns_set iget". I also plan to implement further improvements. One common problem area is the handling of "ns_set" collections with case-insensitive keys (e.g., HTTP request and reply headers, or configuration values). Currently, developers must use the i* variants of commands whenever accessing or updating elements with case-insensitive keys. This current approach has two main issues: a) Semantic Issues: When a developer forgets to use the i* variant for such sets errors will occur that are difficult to debug. These errors may happen at both the C level and the Tcl level, affecting the main NaviServer code as well as the NaviServer modules. In the past few days, I have fixed more than ten such cases, which is why I am now addressing this issue. b) Performance Issues: Using the i* variants (e.g., "ns_set iget”) leads to keys being searched sequentially using strcasecmp(). For a set with N elements, an average of N/2 strcasecmp() operations are performed per lookup or update operation. In other words, during each get/update/delete operation, approximately half of the dictionary is converted to lowercase. Additionally, the input key is repeatedly converted to lowercase. Benchmark comparisons indicate that strcasecmp() is 20 to 30 times slower than strcmp(). The heavy reliance on strcasecmp() in the implementation of Ns_Set certainly impacts performance. To address these problems, I have added a property to the Ns_Set structure that allows it to be declared case-insensitive. With this property enabled, keys are stored in lowercase, enabling the use of strcmp() instead of strcasemp() for comparisons. This change not only improves performance but also reduces the likelihood of semantic errors, as developers no longer need to remember to use the i* variants. So far, I have made the configuration value sets and HTTP header sets case-insensitive: - HTTP Headers: According to the RFC, the names of header fields are case-insensitive. Now, these headers are stored in lowercase, ensuring consistent behavior. - Configuration Sets: Most operations were already case-insensitive, but a few were not, which I regard as bugs. The Ns_Sets for both cases are created from the C level. The only behavioral change is that when obtaining all keys from such a set, they are now returned in lowercase. For case-insensitive sets, the operations "ns_set get" and "ns_set iget will" return the same results. In future versions, we might consider other options for ns_sets, such as enforcing uniqueness or sorting. However, I do not regard these as important as the "-nocase" option for now. Some preliminary data: For a single HTTP request in OpenACS, I count 1,672 strcasecmp() operations. By utilizing the "-nocase" options on HTTP headers and ns_config data, this number is reduced for the same request to just 195 operations per request. On some of our busier systems that process up to 1,000 requests per second, the nocase option on sets saves nearly 1.5 million strcasecmp() operations per second. I am also considering adding a "-nocase" flag to the base operations (i.e. allowing "ns_set get -nocase ..." in addition to "ns_set iget ..."). The "-nocase" flag is common in the Tcl world and appears more familiar than using strange names like: "icput", "idelkey", "ifind”, "iget", "imerge", "iunique", and "iupdate", Finally, the man page for "ns_set" is not very user-friendly, as the base case and the "-nocase" variant should be presented together and not require excessive scrolling. The i* variants will continue to work and might be marked as deprecated in the future. As always, your input is welcome. If you have suggestions about maybe more annoying legacy operations, please let me know, the release change is a chance to address such things. All the best -g |
|
From: Zoran V. <zv...@ar...> - 2024-10-29 17:40:42
|
On 29.10.24 18:27, Gustaf Neumann (sslmail) wrote: > see below for the current ambitious plans for the Tcl roadmap. > The core-team puts a strong emphasis on Tcl9 and names already end-of-support times for Tcl 8.* > This is VERY ambitious in the sense that most of those (TCT) people do not existentialy rely on the code quality, as we do. We have a company and large installation base (mainly large media companies) and cannot afford destabilisation. So, for us, the 8.6 is here to stay for a long(er) time. If needed we will "cook our own soup" i.e. completely detach from the current/future developments. I see that comming. Cheers, Zoran |
|
From: Gustaf N. (sslmail) <ne...@wu...> - 2024-10-29 17:28:01
|
Dear NaviServer community, see below for the current ambitious plans for the Tcl roadmap. The core-team puts a strong emphasis on Tcl9 and names already end-of-support times for Tcl 8.* all the best -g > Begin forwarded message: > > From: Harald Oehlmann <har...@el...> > Subject: [TCLCORE] Monday noon TCL/Tk meeting report > Date: 28. October 2024 at 14:33:20 GMT+1 > To: Tcl Core List <tcl...@li...> > > Dear TCL/Tk/OpenACS/Naviserver team, > > we had a great meeting today with: Don, Jan, Rolf, Paul, Brian, Massimo, Ashok, Andreas Kupries, Andreas Leitgreb, Mark, Steve, Harald. > > The results are: > > R1) TCL/Tk 9.0.0 release is great ! Thanks for all contributors ! > > R2) TCL/Tk 9.0.1 is the next step > - release process starts in December 2024 > - developed in main branches > - address double-distribution of 8.6 and 9.0 by Linux maintainers > - TIP 701 (tilde API) included > - TIP 700 (MD documentation) eventually started > > R3) TCL 8.6 support > - proposed support time: until end 2025 > - all major packages and distributions should be ported to 9.0 > - but some will only switch, if 8.6 declared as unsupported > - specially Tk 9 offers so much practical value, that Tk8.6 is seen as obsolete (scaled interface, updated themes) > - no new features for 8.6, sorry, only bug back-porting > > R4) TCL 8.7 release > - discussion point > - most just want to focus on 9.0 > - 8.6 is easy for migration for 8.6 packages: > - TCL_CHAR size with 16 bit interface is available > - TCL_CHAR size with 32 bit interface (like 9.0) is also available > - No surrogates (like 8.6.11+) > - 8.7 is better than 8.6 as compatible 9.0 extensions are included (full Unicode) > - major player like AndroWish are supposed to directly go to 9.0 > - if released, 8.6 should be taken out of maintenance to avoid double-burden > - first possible release in 1 year. All bugfixes of 9.0 are back-ported, so 8.7. is getting better > - Debian co-maintainer pointed out, that distributions do not have resources for multiple versions. So, only one version is best, max 2, not 3. > > R5) TCL 9.1 release > - will be started when 9.0 is stable (not now) > - TIP 626 (long number of command arguments) is binary incompatible and will wait for 9.1 > - now we have long strings and lists, we should work on its performance. > - decodings currently also have performance issues and are sometimes issued multiple times > - drop support for ITCL > > R6) Decoupling of TCL and Tk release > - There is a strong support to decouple TCL and Tk (minor) releases > - Don is ready to release Tk separately at any time > - Major Tk people were missing in the call > - Eventually own infra-structure: TIP, Team > It would be great to build-up a Tk team and a working way. > Any people for a task force? > > R7) Documentation > - The new documentation project is seen as important to get wider audience > - Help is proposed to advance - Torsten must not do all the work > > R8) Extensions > - Porting all extensions to 9 is a main step to put energy in > - Get tests for larger strings/lists > - make valgrind cleaner for extensions > - Massimo is the Debian maintainer for TDBC. He proposed (before) to be the tdbc packages maintainer. I would say: yes, just do it, great, applause! > > It is proposed to repeat those meetings each two weeks on Mondays at 12:00 UTC. The next meeting will take place 11th of November 2025. > > Thank you all, you guys rock ! > Harald > > _______________________________________________ > Tcl-Core mailing list > Tcl...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-core |
|
From: Gustaf N. (sslmail) <ne...@wu...> - 2024-10-11 05:46:25
|
The regression test on github runs now also the tests on tcl8.5 (in addition to 8.6.15, 8.7a5, 9.0).
This makes sure, that recent changes keep 8.5 compatibility.
Below are the rest running after every push operation.
core-8-5-branch is a post 8.5.19 version containing several fixes.
all the best
-g
- os: ubuntu-latest
compiler: gcc-10
tcltag: core-8-6-15
nsf_version: 2.3.0
tdom_version: 0.9.1
- os: ubuntu-latest
compiler: gcc-12
tcltag: core-8-7-a5
ns_modules: nsdbpg nsdbi nsdbipg nsudp nscoap nssmtpd
nsf_version: 2.4.0
tdom_version: 0.9.4
- os: ubuntu-latest
compiler: gcc-12
tcltag: core-8-5-branch
nsf_version: HEAD
tcllib_version: "2.0"
ns_modules: nsdbpg nsdbi nsdbipg nsudp nscoap nssmtpd nsloopctl
tdom_version: 0.9.4
- os: ubuntu-latest
compiler: gcc-12
tcltag: 9.0.0
nsf_version: HEAD
tcllib_version: "2.0"
ns_modules: nsdbpg nsdbi nsdbipg nsudp nscoap nssmtpd nsloopctl
tdom_version: 0.9.4
|
|
From: Zoran V. <zv...@ar...> - 2024-10-08 15:54:51
|
On 08.10.24 17:49, Andrew Piskorski wrote: > Have you heard of anybody > who still really WANTS to stay on Tcl 8.5 for some reason? I do :-) But I am not in any way married to the server's public version so I guess I do not count. At some (later) point we will move one tick up the ladder and use Tcl 8.6 and will stay there for some years to come. Cheers Zoran |
|
From: Andrew P. <at...@pi...> - 2024-10-08 15:49:25
|
On Tue, Oct 08, 2024 at 04:58:11PM +0200, Gustaf Neumann (sslmail) wrote: > What speaks against using the Tcl scripted approach is that so far, we support NaviServer with tcl8.5. ???file tempfile??? was introduced in Tcl 8.6. Ah, I hadn't realized 'file tempfile' was that new. Maybe just wait until NaviServer requires Tcl 8.6 or later? Have you heard of anybody who still really WANTS to stay on Tcl 8.5 for some reason? > Furthermore, TclUnixOpenTemporaryFile() is just for Unix, and not part of the public API (starting with ???Tcl_???). Well you'd never directly call TclUnixOpenTemporaryFile() of course. That's just how TclFileTemporaryCmd() and TclpOpenTemporaryFile() are implemented underneath. The Windows implemenation uses GetTempPathW() instead of mkstemp(), but presumably works the same at the Tcl level, and in C when calling TclpOpenTemporaryFile(). > But providing this support is not a big thing, since we have in NaviServer since a while support for mkstemp() also for windows (named ns_mkstemp)), since we use this call internally on several places. I???ll cook something up which is most version and platform independent, backward compatible, providing depreciation messages, which can be turned off for ???hopeless cases??? when admins get annoyed about to many depreciation messages. That sounds great! Thanks for taking care of this so proactively. -- Andrew Piskorski <at...@pi...> |
|
From: Gustaf N. (sslmail) <ne...@wu...> - 2024-10-08 14:58:36
|
On 07.10.2024, at 17:59, Andrew Piskorski <at...@pi...> wrote: > > On Mon, Oct 07, 2024 at 12:54:32PM +0200, Gustaf Neumann (sslmail) wrote: > >> However, there are many cases, where existing programs use "ns_mkstemp", which cannot be replaced easily. When looking at OpenACS, I see 33 cases like >> >> - the temporary name is passed to an external program (e.g. "tar", "zip", image creation), or >> - the temporary name is passed to a Tcl function expecting a filename (e.g. "file copy"). > > Interesting. It sounds like are no 100% good solutions for this, and > in fact there CAN'T be. This is right in the sense of “there can’t be a solution free of possible race conditions unless the code is refactored” (e.g. let the NaviServer application write to the temp file rather than the external program) > > I'd lean towards turning ns_mktemp into a wrapper around Tcl's "file > tempfile". That calls TclUnixOpenTemporaryFile() and thus mkstemp() > or mkstemps(), but it looks like Tcl has already done the necessary > work What speaks against using the Tcl scripted approach is that so far, we support NaviServer with tcl8.5. “file tempfile” was introduced in Tcl 8.6. Furthermore, TclUnixOpenTemporaryFile() is just for Unix, and not part of the public API (starting with “Tcl_”). But providing this support is not a big thing, since we have in NaviServer since a while support for mkstemp() also for windows (named ns_mkstemp)), since we use this call internally on several places. I’ll cook something up which is most version and platform independent, backward compatible, providing depreciation messages, which can be turned off for “hopeless cases” when admins get annoyed about to many depreciation messages. all the best -g |
|
From: Wolfgang W. <wol...@di...> - 2024-10-08 13:50:15
|
I like the solution suggested by Andrew as well. This should allow an easy transition of existing code without sacrificing security. Am 07.10.24 um 17:59 schrieb Andrew Piskorski: > On Mon, Oct 07, 2024 at 12:54:32PM +0200, Gustaf Neumann (sslmail) wrote: > >> However, there are many cases, where existing programs use "ns_mkstemp", which cannot be replaced easily. When looking at OpenACS, I see 33 cases like >> >> - the temporary name is passed to an external program (e.g. "tar", "zip", image creation), or >> - the temporary name is passed to a Tcl function expecting a filename (e.g. "file copy"). > Interesting. It sounds like are no 100% good solutions for this, and > in fact there CAN'T be. > >> - Call the safe function (e.g. mkstemp()) and delete the file, while >> producing a depreciation message? This could also be done on the Tcl-level. > I guess so. Probably with a switch to control whether the file is > created and remains (new-style behavior), or gets quickly deleted > (more fully backward compatible). > > I'd lean towards turning ns_mktemp into a wrapper around Tcl's "file > tempfile". That calls TclUnixOpenTemporaryFile() and thus mkstemp() > or mkstemps(), but it looks like Tcl has already done the necessary > work to easily make the wrapper backwards compatible with the > old-style ns_mktemp. And having the compatibility wrapper in Tcl > instead of C makes it a lot easier for NaviServer users to adjust it > to their own needs if necessary. > |
|
From: Brian F. <bri...@ai...> - 2024-10-08 11:35:27
|
I agree with Andrew's suggested approach here. Brian ________________________________ From: Andrew Piskorski <at...@pi...> Sent: Monday 7 October 2024 4:59 pm To: nav...@li... <nav...@li...> Subject: Re: [naviserver-devel] ns_mktemp On Mon, Oct 07, 2024 at 12:54:32PM +0200, Gustaf Neumann (sslmail) wrote: > However, there are many cases, where existing programs use "ns_mkstemp", which cannot be replaced easily. When looking at OpenACS, I see 33 cases like > > - the temporary name is passed to an external program (e.g. "tar", "zip", image creation), or > - the temporary name is passed to a Tcl function expecting a filename (e.g. "file copy"). Interesting. It sounds like are no 100% good solutions for this, and in fact there CAN'T be. > - Call the safe function (e.g. mkstemp()) and delete the file, while > producing a depreciation message? This could also be done on the Tcl-level. I guess so. Probably with a switch to control whether the file is created and remains (new-style behavior), or gets quickly deleted (more fully backward compatible). I'd lean towards turning ns_mktemp into a wrapper around Tcl's "file tempfile". That calls TclUnixOpenTemporaryFile() and thus mkstemp() or mkstemps(), but it looks like Tcl has already done the necessary work to easily make the wrapper backwards compatible with the old-style ns_mktemp. And having the compatibility wrapper in Tcl instead of C makes it a lot easier for NaviServer users to adjust it to their own needs if necessary. -- Andrew Piskorski <at...@pi...> _______________________________________________ naviserver-devel mailing list nav...@li... https://lists.sourceforge.net/lists/listinfo/naviserver-devel |
|
From: Georg L. <jor...@ma...> - 2024-10-07 17:33:53
|
On 10/7/24 12:54, Gustaf Neumann (sslmail) wrote: > Dear all. > [..] However, there are many cases, where existing programs use > "ns_mkstemp", which cannot be replaced easily. When looking at > OpenACS, I see 33 cases like - the temporary name is passed to an > external program (e.g. "tar", "zip", image creation), or - the > temporaryname is passed to a Tcl function expecting a filename (e.g. > "file copy"). So, dropping the support for "ns_mkstemp" fully is not a > good option. Also, providing a "home-cooked" version of "ns_mktemp" is > not good either (both in Tcl or in C), since technically speaking, > this will not be better than the original function having the same > problems. Ignoring the compilation warning is not good either, since > sooner or later, the deprecated function will be removed. What should > we do? - place "ns_mktemp" into an external module? NaviServer will > compile nicely, but applications like OpenACS will have to load the > module, making administration and migration to NaviServer 5 less > smooth. - Call the safe function (e.g. mkstemp()) and delete the file, > while producing a depreciation message? This could also be done on the > Tcl-level. I like this option best. It maintains backward compatibility for the application, encourages update to more secure approaches, discourages future use - especially when accompanied by respective hints in the documentation - and removes the warnings for up-to-date applications. At some time in the future, the wrapped ns_mktemp could then be deprecated and moved out into an external module, which still allows legacy operations to continue using it, while raising the bar. Best Regards, Georg > Other options? Opinions? All the best > -g [1] > https://pubs.opengroup.org/onlinepubs/009695399/functions/mktemp.html > [1] https://man.openbsd.org/OpenBSD-7.5/mkstemp.3 > > > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel |
|
From: Zoran V. <zv...@ar...> - 2024-10-07 16:45:51
|
On 07.10.24 12:54, Gustaf Neumann (sslmail) wrote: > So, dropping the support for "ns_mkstemp" fully is not a good option. You mean ns_mktemp? |
|
From: Zoran V. <zv...@ar...> - 2024-10-07 16:42:10
|
On 07.10.24 17:59, Andrew Piskorski wrote: > I'd lean towards turning ns_mktemp into a wrapper around Tcl's "file > tempfile". That calls TclUnixOpenTemporaryFile() and thus mkstemp() > or mkstemps(), but it looks like Tcl has already done the necessary > work to easily make the wrapper backwards compatible with the > old-style ns_mktemp. Well, if this is so as stated above, then it is a no-brainer! |
|
From: Andrew P. <at...@pi...> - 2024-10-07 16:16:09
|
On Mon, Oct 07, 2024 at 12:54:32PM +0200, Gustaf Neumann (sslmail) wrote: > However, there are many cases, where existing programs use "ns_mkstemp", which cannot be replaced easily. When looking at OpenACS, I see 33 cases like > > - the temporary name is passed to an external program (e.g. "tar", "zip", image creation), or > - the temporary name is passed to a Tcl function expecting a filename (e.g. "file copy"). Interesting. It sounds like are no 100% good solutions for this, and in fact there CAN'T be. > - Call the safe function (e.g. mkstemp()) and delete the file, while > producing a depreciation message? This could also be done on the Tcl-level. I guess so. Probably with a switch to control whether the file is created and remains (new-style behavior), or gets quickly deleted (more fully backward compatible). I'd lean towards turning ns_mktemp into a wrapper around Tcl's "file tempfile". That calls TclUnixOpenTemporaryFile() and thus mkstemp() or mkstemps(), but it looks like Tcl has already done the necessary work to easily make the wrapper backwards compatible with the old-style ns_mktemp. And having the compatibility wrapper in Tcl instead of C makes it a lot easier for NaviServer users to adjust it to their own needs if necessary. -- Andrew Piskorski <at...@pi...> |
14 messages has been excluded from this view by a project administrator.
