Re: libguile package | dlopen: no such file: guile-readline.dll
>On Saturday, January 6, 2024 at 01:45:09 AM PST, marco atzeri via Cygwin > wrote: >On Sat, 6 Jan 2024, 10:28 Brian Inglis via Cygwin, wrote: >> On 2024-01-05 18:07, asebian via Cygwin wrote: >> > package: liguile3.0_1 >> > version: 3.0.9-2 >> > >> > >> > Problem >> > >> > Loading the ice-9/readline module coming with libguile raises an error: >> > >> > $ guile -q >> > scheme@(guile-user)> (use-modules (ice-9 readline)) >> > While compiling expression: >> > In procedure dlopen: file "guile-readline.dll", message "No such file >> > or directory" > > >> > Seems as if version number 0 got attached: >> > >> > $ ls -1 /usr/lib/guile/3.0/extensions/ >> > guile-readline.la >> > guile-readline-0.dll >> > >> > C:\cygwin64\lib\guile\3.0\exte >> > nsions> dir /B >> > guile-readline-0.dll >> > guile-readline.la >> > >> > >> > Makeshift fix >> > >> > Create symlink (as Admin): >> > >> > C:\cygwin64\lib\guile\3.0\extensions> mklink guile-readline.dll >> > guile-readline-0.dll >> > symbolic link created for guile-readline.dll <<===>> guile-readline-0.dll >> > >> > $ guile -q >> > scheme@(guile-user)> (use-modules (ice-9 readline)) >> > scheme@(guile-user)> (activate-readline) >> >> As these appear to be generated during package config or build, this >> should be >> handled during package config, build, install, or postinstall, perhaps >> using >> alternatives. >> >Alternatives today can not be used as does not handle dll's only exe and >script >Mklink could be a possible general approch in alternatives for handling >dll. >With some file system limitation > will look on the guile issue next week This is a known regression in Guile itself. Bug #64723. Guile used to use libltdl to do dynamic linking, and libltdl would search for dlls that had major version numbers attached, such as 'guile-readline0.dll' Guile replaced libltdl with internal code, which no longer handles dlls with major version numbers attached. A patch was proposed but has not made it into the main tree to restore major version number handling in Dlls. I keep my own version of the patch in my fork: here. github.com/spk121/guile/commit/ddcdfe0db957a8231deb8e8ee70a7aec6307acd9 Another workaround would be to add the "-avoid-version" flag to LDFLAGS for guile-readline -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Another confusing error from someone else's Cygwin setup
> On Monday, June 26, 2023 at 04:36:30 PM PDT, David Karr via Cygwin
> wrote:
> m seeing a problem with someone else's Cygwin setup, sort of similar to a
> problem I asked about a couple of weeks ago, in that it's a problem with
> the same user, but seemingly a completely different problem.
...
> He was getting a weird error on line 3, just saying this:
> -
> ...: line 3: syntax error near unexpected token `$'{\r''
> ...: line 3: `main() {
> ---
If you run bash with the "-o igncr" option, it will ignore extraneous
carriage return characters.
But the characters are there in the first place because your
script has been converted into using Windows line endings:
carriage return + linefeed.
You didn't say how the script was transferred, but lots
of programs could add returns when you transfer something
to windows: git or ftp just to name a few.
You both could try running "bash --version". The first line should
say something like
"GNU bash, version 5.2.15(3)-release (x86_64-pc-cygwin)"
Note the "pc-cygwin" at the end.
HTH,
Mike Gran
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Trying to figure out what is wrong in a colleague's Cygwin setup
> Ok, well, we managed to resolve this, but I don't understand why what we > did would fix this. > In system environment variables in Windows, they added "c:\cygwin64\bin" to > the end of the PATH. That fixes the problem. That just doesn't make any > sense to me. In a Cygwin shell, "/usr/bin" is in the PATH, which is the > same as "c:\cygwin64\bin". Hello David- The fact that their uname said MINGW implies they weren't running "real" Cygwin, but, actually MSYS, which is the slightly modified Cygwin that is bundled with MINGW to allow it to run bash and other coreutils. MSYS has its own location for '/usr/bin', which is probably c:/msys64/usr/bin or similar. It won't look in c:/cygwin64 by default. Just a guess, but, hope this helps. -Mike Gran -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
On abstract sockets
Hello Cygwin-
I just wanted to double-check my understanding that binding
an abstract socket (a NULL-prefixed filename) is not currently
supported on Cygwin. I think there used to be some sort
of emulation of abstract sockets, but, that's not true anymore,
right?
With the sample program below, bind for AF_UNIX traces into
fhandler_socket_local::bind, since AF_UNIX == AF_LOCAL.
fhandler_socket_local::bind copies the NULL-prefixed abstract
name using
strncpy (sun_path, un_addr->sun_path, len);
which truncates sun_path to be an empty string. Searching
for the existence of the empty path causes errno ENOENT.
Also, it seems unclear if winsock2 sockets supports abstract sockets
anyway.
Thanks,
Mike Gran
// tmp.c
#include
#include
#include
#include
int main()
{
int s;
struct sockaddr_un name;
int ret;
s = socket(AF_UNIX, SOCK_STREAM, 0);
if (s == -1) {
perror("socket");
exit(1);
}
const char path[5] = { 0, 'f', 'o', 'o', 0};
memset(, 0, sizeof(name));
name.sun_family = AF_UNIX;
memcpy(name.sun_path, path, sizeof(path));
ret = bind(s, (const struct sockaddr *) , 2 + sizeof(path));
if (ret == -1) {
perror("bind");
exit(1);
}
return 0;
}
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: guile-3.0.9-2
On Thu, Jun 01, 2023 at 07:51:55AM +0200, Marco Atzeri via Cygwin wrote: > Hi Mike, > download the source package. > You can use setup to install it or going directly to one of the mirror like > > https://mirrors.kernel.org/sourceware/cygwin/x86_64/release/guile3.0/ > > All the patches and the cygport script to build it are there Got it. > I have not yet (moved) uploaded the guile cygwin patches in the expected > canonical repository for cygwin. > It is on the long TODO list Thanks you for your hard work. Regards, Mike Gran -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: guile-3.0.9-2
On Saturday, May 13, 2023 at 11:40:01 PM PDT, Marco Atzeri via Cygwin-announce via Cygwin wrote: > Version 3.0.9-2 of > guile3.0 > libguile3.0-devel > libguile3.0_1 > have been uploaded for cygwin. Hello Marco and Cygwin: Where can I find the source patches that Cygwin uses for guile3.0? On Github, for some project, I'm trying to make my own CI/CD nightly build of upstream Guile's main branch on a handful of OSs, and I'm having a bit of trouble getting Cygwin to build. If anyone's curious, here's my Github Action YML so far. https://github.com/spk121/guile/blob/main-patches/.github/workflows/windows-cygwin.yml Regards, Mike Gran -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: guile 3.0.8: readline does not work - patch with also other fixes
On Tue, Oct 04, 2022 at 08:06:00PM +0200, Hannes M�ller wrote: > Hi Guile-Maintainer, > Hi Marco Atzeri, > > with e.g. guile 3.0.8-1 I noticed serveral problems. > > Most important one is not working readline support. You may check in > guile via e.g.: > (begin (use-modules (ice-9 readline))(activate-readline)) > > With e.g. guile3.0-3.0.8-1.src the shared library guile-readline-0.dll > is created on Cygwin but guile-readline.dll is expected. This results > from guile since 3.0.6 does not load foreign libraries via libltdl. Hannes- Hi. I can speak speak for upstream Guile on that, I guess. When the core Guile maintainers dumped libltdl, I was the one that wrote the Guile code that converted GNU/Linux shared object names to Cygwin DLL names, and I forgot to properly account for version numbers in Cygwin DLL names. The code that does "libfoo.so" to "cygfoo.dll"... On Linux, "libfoo.so" is usually a link to a more specific "libfoo.so.x" so Guile doesn't have to search for the most recent revision. I could change that code so that the code that searches for "libfoo.so" actually searches for anything named "cygfoo.dll" and "cygfoo-??.dll", but I'd need someone on Cygwin to explain to me how that search should be. Is the '??' in cygfoo-?? always numeric? How many digits can it be? I'm assuming the highest number has priority. Should "cygfoo.dll" outrank "cygfoo-1.dll", or is it the opposite? Is there some Cygwin library function that will do this search for me that I should know about? As for the other patches to upstream Guile, if no one else is working on it, I'll see what I can do. But in the meantime, if Cygwin wants to incorporate your patch to '-avoid-version' in guile-readline, that's the best solution for 3.0.8. Thanks, Mike Gran -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
mingw.org may be dead, but is referenced in cygwin docs
Hello Cygwin- I was reading the webpage "Building and Using DLLs". That page suggests looking at mingw.org for more information. mingw.org is no more. I don't know when or if it will return. Thanks, Michael -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Use cygwin to run autotools for MSVC?
Hi- Is it possible use Cygwin to run an autotools 'configure' script but have the compiler be MSVC? Thanks, Michael -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Why is __unix__ defined, and not __WINDOWS__ ?
On Sun, May 12, 2019 at 08:22:36PM +0200, Agner Fog wrote: > I have noticed that the gcc and clang compilers have defined the > preprocessing macro __unix__, but not __WINDOWS__, _WIN32, or _WIN64 when > compiling a windows executable. > > Why is this? As I understand it, when using the cygwin compiler to compile for the cygwin target, these defines are intentionally not defined, because Cygwin is supposed to look and feel like a Posix platform, not a windows one. The various MinGW compilers do define these constants because the target is native windows. I think these days the canonical defines are (somebody correct me if I'm wrong) __CYGWIN__ for Cygwin _WIN32 as 1 on MinGW when the compilation target is Windows 32-bit ARM, 64-bit ARM, x86, or x64. Otherwise, undefined. _WIN64 as 1 on MinGW when the compilation target is Windows 64-bit ARM or x64. Otherwise, undefined I am not a maintainer. - Mike Gran -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Docker, containers, and Cygwin
Hello good people, This isn't a question so much as a random musing... From what I understand, Cygwin works by translating POSIX-like calls into Windows API. Or, to be more specific, the version of newlib that Cygwin provides links to Windows-provided dlls that make Windows API calls. And Docker on Windows works by creating a layer that allows some subset of the Windows API to be called by the image in the container, passing those API calls to the OS kernel. I tried (non-exhaustively) to figure out what Windows kernel APIs can actually make it through the Docker infrastructure from an image to the Windows kernel. This led me to ponder if the Windows APIs that Cygwin uses in its emulation layer are a subset of the APIs that make it through the Windows Docker containers. My guess is that all the API that Cygwin uses *would* pass through container, since is it basic stuff. (Of course, the file and socket I/O may be intercepted by the container depending on its permissions.) Unfortunately, there doesn't seem to be handy reference about how Windows Docker containers work. Anyway, that's today's musing. -Mike Gran -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: return value of getitimer after an alarm
On Sun, Feb 24, 2019 at 10:18:58AM +0100, Corinna Vinschen wrote:
> On Feb 23 22:58, Mike Gran via cygwin wrote:
> > Hi-
> >
> > There is an unusual behaviour with setitimer/getitimer and I'm not
> > sure if it is a bug or not.
> >
> > Basically, if I call setitimer to set an SIGALRM, and then call
> > getitimer *after* the alarm goes off, I rather expect the time I
> > receive from getitimer should be {tv_sec = 0, tv_usec = 0}, but, in
> > fact, it_value is the negative of the unix timestamp.
> >
> > Attached is a test case.
>
> Thanks for the testcase. The reason for the problem is this:
> I optimized a condition in Cygwin's POSIX timers "gettime" method.
> I optimized it so effecively that it was practically invisible :}
>
> I pushed a patch and uploaded new developer snapshots to
> https://cygwin.com/snapshots/
>
> Please test.
Works for me. Thanks for your help.
-Mike Gran
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
return value of getitimer after an alarm
Hi-
There is an unusual behaviour with setitimer/getitimer and I'm not
sure if it is a bug or not.
Basically, if I call setitimer to set an SIGALRM, and then call
getitimer *after* the alarm goes off, I rather expect the time I
receive from getitimer should be {tv_sec = 0, tv_usec = 0}, but, in
fact, it_value is the negative of the unix timestamp.
Attached is a test case.
Thanks,
Mike Gran
#include
#include
#include
#include
#include
#include
#include
#include
int loop = 1;
static void
handler(int sig, siginfo_t *si, void *unused)
{
printf("Got SIGALRM at address: 0x%lx\n",
(long) si->si_addr);
loop = 0;
}
int main(int argc, char **argv)
{
struct sigaction sa;
sa.sa_flags = SA_SIGINFO;
sigemptyset(_mask);
sa.sa_sigaction = handler;
sigaction(SIGALRM, , NULL);
struct itimerval new_value, old_value;
new_value.it_interval.tv_sec = 0;
new_value.it_interval.tv_usec = 0;
new_value.it_value.tv_sec = 0;
new_value.it_value.tv_usec = 1000;
setitimer(ITIMER_REAL, _value, _value);
while (loop)
;
printf("Loop is complete\n");
int ret = getitimer(ITIMER_REAL, _value);
printf("%d %ld %ld %ld %ld\n",
ret,
old_value.it_interval.tv_sec,
old_value.it_interval.tv_usec,
old_value.it_value.tv_sec,
old_value.it_value.tv_usec
);
return 0;
}
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
