@yogi32

If you get undefined references to __gthread_#? with newer gcc it just means that you need to add -athread=single (or -athread=native if your code uses C++ threads) when linking.

Also when posting source code on the forum if you use [ code] /* insert code here */ [ /code] tags (without the space after the '[') it won't remove the angular brackets and the indentation will be preserved.

SSHTerm 1.9 is now available:

https://github.com/salass00/sshterm/releases

Main new features is that it now uses libssh2 1.10.0 and is built using AmiSSL 5.1 SDK so that it works with the latest AmiSSL version.

While testing I initially thought that I had somehow managed to break the RSA public key support (ED25519 was still working correctly) while moving to libssh2 1.10.0 from 1.9.0 and I wasted a lot of time trying to find what changes could be responsible, until I tried with the 1.8 version of SSHTerm and found it didn't work there either. Turns out that Ubuntu 22.04 LTS (I had recently updated to it from 20.04 LTS) no longer supports RSA public keys by default and you have to modify your /etc/ssh/sshd_config file to get them working.

@Raziel

Add -lssp to get rid of those undefined references.

To test I just compiled and linked the FLAC C decode file example code using the gcc 8.4.0 from SDK 54.16 and it worked without any errors (libs used for linking were "-lFLAC -logg -lssp").

@flash

Quote:

That really shouldn't happen and I'm so far unable to reproduce it here (either with a cross compiler or native gcc).

The reason the #include_next fails is because the gcc internal stddef.h is ahead of the "newlib" one in the compiler's include search path, but for this exact reason and the fact that the gcc stddef.h does not contain a #include_next directive the "newlib" stddef.h header should never be used...

The only reason that there is a stddef.h header included at all with newlib is for vbcc compiler support, so if you do not use the vbcc compiler (or don't use the +newlib target) you can simply delete this file, and if this doesn't fix things then there is something wrong with your gcc installation.

@SinanSam460

Just link the executable with -lunix and it will fix those pathing issues.

@SinanSam460

Don't bother with version 1.20.1. It isn't working which is why there are no releases so far of this version and the main makefile is still set to build version 1.18.2.

As for the cleanup problems there is very little that can be done if programs refuse to clean up after themselves. Theoretically it might be possible to do something with an atexit or destructor function that cleans up the audio driver backend if the program hasn't done so yet, but this could also cause problems for correctly written programs so it isn't worth it IMO.

To cause a reschedule with SetTaskPri() it is enough to just do:

@daveyw

Then you are probably just lucky and don't have kernel munge option enabled. It was broken ever since the paste handling was moved to being done in a sub-process (somewhere between versions 54.2 and 54.8).

As a developer I have munge option enabled all the time because it makes visible bugs like this.

@nbache

Weren't the Bitstream fonts renamed to DejaVu? At least that is something I recall reading.

@rjd324

I take it you are referring to the menus created by the ContextMenus commodity?

If so it has been broken for a long time AFAIK. I made some big fixes to the paste function in ContextMenus in December 2020 that have not been released yet...

@LiveForIt

Quote:

Not true, the partition mounting code from the mass storage driver was split off into its own kickstart module, "mounter.library", in 2014 and has been available publicly since 4.1 Final Edition.

The X5000 and A1222 on-board SATA drivers are in fact already making use of this library.

@trixie

Quote:

There is the strnlen() function which is like strlen() but allows to limit how far the function will go to look for a '\0' character.

@afxgroup

For whatever reason it's definitely using the wrong libstdc++.a (newlib version) for walkero. The clib2 version should be in a clib2 sub-directory from where the newlib one is.

@rjd324

I fixed this bug in string.gadget almost six months ago (14.1.2022 according to the releasenotes). That a fixed version hasn't been released yet is a little frustrating TBH.

@sTix

Actually there is a difference between newlib and clib2 getcwd() in that newlib getcwd() will return the AmigaOS style path if __translate_amiga_to_unix_path_name() fails whereas clib2 will just return an error. Still doesn't explain why it works when the buffer size is 1024.

@sTix

Newlib uses the same path translation so I doubt it. It just means that if you have the unix path semantics enabled (-lunix) there is little to no benefit from using a buffer larger than PATH_MAX bytes.

@kas1e

AFAICT there should be no upper limit on the buffer size for getcwd() in clib2 (I looked at the code both for Olaf Barthel's and afxgroup's clib2).

What is errno set to after getcwd() has returned?

@trgswe

A more verbose method that should produce the same result:


BTW the warning note in the GetDiskFontCtrl() autodoc is mainly for the tag pairs like DFCTRL_XDPI/DFCTRL_YDPI or DFCTRL_XDOTP/DFCTRL_YDOTP where you might get a new value for the X and an old value Y if you read them while they are being modified.

@LiveForIt

Quote:

If that was the case it would be an ISI and not an alert.

In this case what seems to have happened is that the newlib.library dlmalloc allocator has detected an error and posted the alert 0x81000009 (AT_DeadEnd|AN_FreeTwice).

It could be that a bad memory pointer was passed to free() or maybe the memory was already freed before as suggested by the alert code. It is also possible that the magic field in the memory chunk header has been overwritten by a buffer overflow or random memory trashing.

@walkero

You don't need unlibdev or other external dependencies to convert between local charset and unicode.

Just use IDiskfont->GetDiskFontCtrl(DFCTRL_CHARSET) to get the IANA number and you can then use IDiskfont->ObtainCharsetInfo() to request a mapping table.



The mapping table is an array of 256 ULONGs that are the unicode (UCS4) equivalents to each character in the local (8-bit) charset.

You can then use this to convert to unicode just like so:


I use this method in SSHTerm as libtsm (the terminal emulation layer I am using) works exclusively with unicode as well (see src/term-gc.c).