DJGPP cross compiler crashes.
Hello everyone,
I would like to signal that the DJGPP cross compiler, included into
the available packages, crashes as soon as you try to compile
something with it.
To reproduce the problem, just create a simple source file with just
this line for simplicity:
int main() { return 0; }
and after calling:
i586-pc-msdosdjgpp-gcc c.c -o c.exe
you will get:
collect2: fatal error: ld terminated with signal 11 [Segmentation
fault], core dumped
compilation terminated.
I bypassed the problem by recompiling DJGPP cross compiler myself with
this utility:
https://github.com/andrewwutw/build-djgpp
however, I'm signaling the problem in case somebody would like to fix
the trouble with a working package.
Sincerely.
--
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
libsoxr for mingw32/64
Hello, I was wondering if it would be possible to add libsoxr to the list of the available packages for MINGW (32bit and 64bit). This package is already available into cygwin, but not for MINGW. Thank you very much for your time. Sincerely. -- 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: DJGPP cross compiler crashes.
Hello, well, I tried both versions of CYGWIN, 32 bit and 64 bit, even on different PCs. I also tried to install different versions, 5.4.0 and 5.3.0 of djgpp-gcc. I used Windows 7 64bit Home Premium and Windows 7 64 bit Professional. Always the same result. I have no idea how you can run it without errors, please note that i586-pc-msdosdjgpp-gcc works fine until it does not link. Sincerely. Il giorno gio 18 apr 2019 alle ore 23:19 Hans-Bernhard Bröker ha scritto: > > Am 18.04.2019 um 16:11 schrieb Carlo B.: > > > I would like to signal that the DJGPP cross compiler, included into > > the available packages, crashes as soon as you try to compile > > something with it. > > Doesn't, here. It just works. > > > -- > 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 > -- 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: Mingw pkg-config not working
Hello, I wanted to say that I modified the script in this way and it seems that it has resolved all issues: #!/bin/sh if [ "$#" -eq 1 ] && [ "$1" == "--version" ]; then exec pkgconf --version else exec pkgconf --personality=i686-w64-mingw32 $@ fi Fixing x64_64 is easy, I have just replaced i686-w64-mingw32 with x86_64-w64-mingw32 in the personality. I hope you will find this fix useful and, if you think it is good, the maintainer of the package could rewrite those scripts in the same way. Sincerely. Il giorno sab 22 feb 2020 alle ore 18:47 Jon Turney ha scritto: > > On 20/02/2020 11:06, Carlo B. wrote: > [...] > > x86_64-w64-mingw32-pkg-config are emulated with a shell script, for > > example the one for i686 is: > > > > #!/bin/sh > > exec pkgconf --personality=i686-w64-mingw32 $@ > > > > But while this solution mostly works when you exec it from the command > > line, it makes impossible to detect the presence of the tool from > > meson and cmake build systems. > > If you try to do this on the bash prompt, you get: > > > > $ i686-w64-mingw32-pkg-config --version > > pkgconf: --version specified with other options or module names, > > assuming --modversion. > > Please specify at least one package name on the command line. > > > > and this is exactly what happens with those build systems (and perhaps > > others, I don't know): it tries to call pkg-config with "--version" > > and it executes the above script that calls pkgconf. But sadly, the > > presence of the "--personality" option makes the process to fail, > > because the "--version" is currently allowed only when no other > > options are added. > > And, for this reason, meson and cmake fail the detection of the tool. > > > > I have also filed an issue here for pkgconf: > > https://todo.sr.ht/~kaniini/pkgconf/10 > > because the solution is actually to ignore the presence of the > > "--personality" option when the "--version" is written, but > > unfortunately I have not received any feedback. > > > > So, I'm also writing here, with the hope that you could find a solution. > [...] > > Thanks for reporting this issue. > > I guess the alternative to fixing pkgconf would be to modify those > wrapper scripts to detect when the parameters are just '--version' (or > equivalent) and not use --personality in that case? > > These wrapper scripts are specific to cygwin (generated by the cygport, > see [1]) > > It's possible other distros have more sophisticated wrapper scripts, > which avoid this problem? > > If you do write or discover some improved wrapper scripts, a patch to > [1] to update them would be appreciated. > > [1] > https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/pkgconf.git;a=blob;f=pkgconf.cygport#l84 -- 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
Mingw pkg-config not working
Hello, I discovered that the mingw cross compilers for i686 and x86-64 have a problem with support of pkg-config. From what I have seen, the mingw included into CYGWIN is not using the usual pkg-config, but it uses pkgconf instead, which is a good thing at first sight, since it does not depend to GLib. Unfortunately, this introduces a problem: the traditional i686-w64-mingw32-pkg-config and x86_64-w64-mingw32-pkg-config are emulated with a shell script, for example the one for i686 is: #!/bin/sh exec pkgconf --personality=i686-w64-mingw32 $@ But while this solution mostly works when you exec it from the command line, it makes impossible to detect the presence of the tool from meson and cmake build systems. If you try to do this on the bash prompt, you get: $ i686-w64-mingw32-pkg-config --version pkgconf: --version specified with other options or module names, assuming --modversion. Please specify at least one package name on the command line. and this is exactly what happens with those build systems (and perhaps others, I don't know): it tries to call pkg-config with "--version" and it executes the above script that calls pkgconf. But sadly, the presence of the "--personality" option makes the process to fail, because the "--version" is currently allowed only when no other options are added. And, for this reason, meson and cmake fail the detection of the tool. I have also filed an issue here for pkgconf: https://todo.sr.ht/~kaniini/pkgconf/10 because the solution is actually to ignore the presence of the "--personality" option when the "--version" is written, but unfortunately I have not received any feedback. So, I'm also writing here, with the hope that you could find a solution. This behavior is easy to verify, just write that command at the prompt of the shell, or try to build something that uses the detection of the tool: in my case, I found it when I tried to build the audacious media player from sources. Thank you very much for your time and your support. Sincerely. -- 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
wxWidgets 3.1.5 has not built-in regex support.
Hello, I'm trying to build an application (Codelite) with the recently released wxWidgets 3.1.5 package, but I'm getting an error because wxRE_ADVANCED is undefined. I suspect that this release has been compiled without the built-in regex engine. Is it possible to fix this this issue? Thank you very much. Sincerely. -- 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
EXPAT 2.4.4 released with fixed CMake support for CYGWIN
Hello, with reference with this message: https://cygwin.com/pipermail/cygwin/2022-January/250572.html I would like to report that EXPAT 2.4.4 has been released with fixed CMake support for CYGWIN: https://github.com/libexpat/libexpat/blob/R_2_4_4/expat/Changes Will it be possible to release an updated package? Thank you very much for your time. Sincerely, Carlo Bramini. -- 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
CMake support into libssh-0.8.7-1 is broken.
Hello,
I discovered that CMake support into current libssh-0.8.7-1 is broken.
After you installed the development package, you just need to add this
line into a dummy CMakeLists.txt:
find_package(libssh)
and into the console you will read:
CMake Error at /usr/lib/cmake/libssh/libssh-config.cmake:21 (message):
File or directory /usr/lib/cygssh.dll referenced by variable
LIBSSH_LIBRARIES does not exist !
The error is correct because, if you open
/usr/lib/cmake/libssh/libssh-config.cmake, you will see this code:
if (EXISTS "${CMAKE_CURRENT_LIST_DIR}/CMakeCache.txt")
# In tree build
set_and_check(LIBSSH_INCLUDE_DIR "${CMAKE_CURRENT_LIST_DIR}/include")
set_and_check(LIBSSH_LIBRARIES "${CMAKE_CURRENT_LIST_DIR}/lib/cygssh.dll")
else()
set_and_check(LIBSSH_INCLUDE_DIR "${PACKAGE_PREFIX_DIR}/include")
set_and_check(LIBSSH_LIBRARIES "${PACKAGE_PREFIX_DIR}/lib/cygssh.dll")
endif()
which is wrong since the right value for LIBSSH_LIBRARIES should be
"${PACKAGE_PREFIX_DIR}/bin/cygssh-4.dll" or
"${CMAKE_CURRENT_LIST_DIR}/bin/cygssh-4.dll".
After that, I downloaded the latest stable libssh-0.9.6, I tried to
build it but it crashes with an internal GCC error at compile time:
during RTL pass: final
/home/Carlo/libssh-0.9.6/src/sftp.c: In function ‘sftp_packet_read’:
/home/Carlo/libssh-0.9.6/src/sftp.c:549:1: internal compiler error: in
i386_pe_seh_unwind_emit, at config/i386/winnt.c:1275
549 | }
| ^
So, I downloaded the latest sources from the repository: GCC still
emits an internal compiler error, but only when building the examples.
So I configured with -DWITH_EXAMPLES=OFF and I got the base library
compiled.
Here, I verified that the macros for CMake are generated correctly
with the right names and paths.
Is it possible to fix or update this package?
Thank you very much for your time.
Sincerely.
--
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: CMake support into libssh-0.8.7-1 is broken.
Hello, Il giorno gio 20 gen 2022 alle ore 20:07 Marco Atzeri ha scritto: > > On 15.01.2022 14:19, Marco Atzeri wrote: > > On 14.01.2022 23:30, Carlo B. wrote: > >> Hello, > >> I discovered that CMake support into current libssh-0.8.7-1 is broken. > >> After you installed the development package, you just need to add this > >> line into a dummy CMakeLists.txt: > >> > >> > >> find_package(libssh) > >> > >> > > >> > >> So, I downloaded the latest sources from the repository: GCC still > >> emits an internal compiler error, but only when building the examples. > >> So I configured with -DWITH_EXAMPLES=OFF and I got the base library > >> compiled. > >> Here, I verified that the macros for CMake are generated correctly > >> with the right names and paths. > >> > >> Is it possible to fix or update this package? > >> Thank you very much for your time. > >> > >> Sincerely. > >> > > > > noted > > > > Regards > > Marco > > > > what´s happening if you try to use libssh2 ? > Thank you for the reply. Unfortunately, I doubt that it can be possible because libssh is required for building Codelite for CYGWIN. About the crash of CYGWIN GCC when building the latest source of libssh, this is caused by the "-fstack-clash-protection" option. However, according to this issue at bugzilla for GCC: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90458 it should not be used when the target platform is Windows and derivates. > Currently libssh is without maintainer and it is anyway obsolete > so probably you should build with libssh2 > This is a bad news actually, I mean the missing maintaner. Sincerely. -- 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
CMake support into expat-2.4.1 is broken.
Hello, I tried to build the latest stable of OpenColorIO but I got an error because the support for CMake into expat is broken. I'm getting this message: CMake Error at /usr/lib/cmake/expat-2.4.1/expat.cmake:74 (message): The imported target "expat::expat" references the file "/usr/lib/libexpat.so.1.8.1" but this file does not exist. which is true, as you can see by inspecting the file /usr/lib/cmake/expat-2.4.1/expat-noconfig.cmake. As you can see by looking here: https://github.com/libexpat/libexpat/tree/master/expat/cmake/autotools this is a bug of Expath because "expat-noconfig__linux.cmake.in" is installed rather than expat-noconfig__windows.cmake.in. Here: https://github.com/libexpat/libexpat/pull/546 I made a PR to the master of Expat for fixing this issue. I was wondering if a newer packaged could be published with a newer stable version of Expat (when it will be released with this fix) or by updating the cygport file by including the same patch. Thank you very much. Sincerely. -- 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
Error when building autoconf2.1, broken package?
Hello, I did these actions: 1) Downloaded autoconf2.1-2.13-12-src.tar.bz2 2) Unpack that file. 3) I run this command: cygport autoconf2.1.cygport all and this is the output on screen: >>> Preparing autoconf2.1-2.13-12.x86_64 >>> Unpacking source autoconf-2.13.tar.gz *** Info: applying patch autoconf2.1-texinfo.patch (-p2): patching file autoconf.texi >>> Preparing working source directory *** Info: applying patch autoconf2.1-2.13-12.cygwin.patch (-p2): patching file CYGWIN-PATCHES/autoconf2.1.README >>> Compiling autoconf2.1-2.13-12.x86_64 *** ERROR: could not detect autoconf version; perhaps set AUTOCONF_VERSION? Have you an idea of the cause of the problem? I tried to download and rebuild also autoconf2.5 and autoconf2.7 and they worked fine, only 2.1 fails. Thank you very much for your time. Sincerely, Carlo Bramini. -- 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: Error when building autoconf2.1, broken package?
Hello,
it works, thank you very much.
I also added AUTOCONF_VERSION=2.13 directly into the cygport script,
before calling cygconf and it also worked fine without manually
setting that environment variable.
I think that it would be worth to update the cygport script into
autoconf2.1-2.13-12-src.tar.bz2 to make it working again also for
other people.
Sincerely,
Carlo Bramini.
Il giorno gio 21 lug 2022 alle ore 15:07 Takashi Yano
ha scritto:
>
> On Tue, 19 Jul 2022 12:42:47 +0200
> "Carlo B." wrote:
> > Hello,
> > I did these actions:
> > 1) Downloaded autoconf2.1-2.13-12-src.tar.bz2
> > 2) Unpack that file.
> > 3) I run this command:
> >
> > cygport autoconf2.1.cygport all
> >
> > and this is the output on screen:
> >
> > >>> Preparing autoconf2.1-2.13-12.x86_64
> > >>> Unpacking source autoconf-2.13.tar.gz
> > *** Info: applying patch autoconf2.1-texinfo.patch (-p2):
> > patching file autoconf.texi
> > >>> Preparing working source directory
> > *** Info: applying patch autoconf2.1-2.13-12.cygwin.patch (-p2):
> > patching file CYGWIN-PATCHES/autoconf2.1.README
> > >>> Compiling autoconf2.1-2.13-12.x86_64
> > *** ERROR: could not detect autoconf version; perhaps set AUTOCONF_VERSION?
> >
> > Have you an idea of the cause of the problem?
> > I tried to download and rebuild also autoconf2.5 and autoconf2.7 and
> > they worked fine, only 2.1 fails.
> > Thank you very much for your time.
>
> I could build autoconf2.1 successfully by the following steps.
>
>
> 1) Modify autoconf2.1.cygport as follows.
>
> diff --git a/autoconf2.1.cygport.orig b/autoconf2.1.cygport
> index c8b075f..6876c3c 100755
> --- a/autoconf2.1.cygport.orig
> +++ b/autoconf2.1.cygport
> @@ -28,7 +28,7 @@ src_compile() {
> cd ${B}
> cygconf --program-suffix=-2.13
> cygmake -j1
> - (makeinfo --no-split -I ${S} -o autoconf2.13.info autoconf.texi)
> + (makeinfo --no-split -o autoconf2.13.info ${S}/autoconf.texi)
> }
>
> DIFF_EXCLUDES="autoconf.info standards.info stamp-vti version.texi"
>
> 2) Run 'export AUTOCONF_VERSION=2.13'
> 3) Run 'cygport autoconf2.1.cygport all'
>
> --
> Takashi Yano
--
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: Error when building autoconf2.1, broken package?
Hello,
Il giorno mer 3 ago 2022 alle ore 21:52 Jon Turney
ha scritto:
>
> On 22/07/2022 15:44, Carlo B. wrote:
> > Hello,
> > it works, thank you very much.
> > I also added AUTOCONF_VERSION=2.13 directly into the cygport script,
> > before calling cygconf and it also worked fine without manually
> > setting that environment variable.
> > I think that it would be worth to update the cygport script into
> > autoconf2.1-2.13-12-src.tar.bz2 to make it working again also for
> > other people.
>
> Is there something wrong with our supplied autconf2.1 package?
>
Nowadays, it is not possible to make the autconf2.1 package from "src"
because the errors written in previous emails.
I don't know if the fault is caused by a regression into cygport or it
is needed to fix the "src" package of autconf2.1 for supporting a new
syntax or something like that. Unfortunately, the main problem is that
running the cygport script for autoconf 2.1 still hangs, so perhaps it
would be useful to fix it, in one way or another one.
Thank you very much for your time and your reply.
Sincerely,
Carlo Bramini.
> >
> > Sincerely,
> >
> > Carlo Bramini.
> >
> > Il giorno gio 21 lug 2022 alle ore 15:07 Takashi Yano
> > ha scritto:
> >>
> >> On Tue, 19 Jul 2022 12:42:47 +0200
> >> "Carlo B." wrote:
> >>> Hello,
> >>> I did these actions:
> >>> 1) Downloaded autoconf2.1-2.13-12-src.tar.bz2
> >>> 2) Unpack that file.
> >>> 3) I run this command:
> >>>
> >>> cygport autoconf2.1.cygport all
> >>>
> >>> and this is the output on screen:
> >>>
> >>>>>> Preparing autoconf2.1-2.13-12.x86_64
> >>>>>> Unpacking source autoconf-2.13.tar.gz
> >>> *** Info: applying patch autoconf2.1-texinfo.patch (-p2):
> >>> patching file autoconf.texi
> >>>>>> Preparing working source directory
> >>> *** Info: applying patch autoconf2.1-2.13-12.cygwin.patch (-p2):
> >>> patching file CYGWIN-PATCHES/autoconf2.1.README
> >>>>>> Compiling autoconf2.1-2.13-12.x86_64
> >>> *** ERROR: could not detect autoconf version; perhaps set
> >>> AUTOCONF_VERSION?
>
> This is a regression in cygport, which I'll see about fixing.
>
> (Briefly: cygport tries to detect the version of autoconf which was used
> to generate the ./configure script, so it knows what option arguments to
> supply to it. Recently this was extended to detect autoconf 2.7x, but
> that seems to have broken detecting autoconf 2.1x)
>
> >>>
> >>> Have you an idea of the cause of the problem?
> >>> I tried to download and rebuild also autoconf2.5 and autoconf2.7 and
> >>> they worked fine, only 2.1 fails.
> >>> Thank you very much for your time.
> >>
> >> I could build autoconf2.1 successfully by the following steps.
> >>
> >>
> >> 1) Modify autoconf2.1.cygport as follows.
> >>
> >> diff --git a/autoconf2.1.cygport.orig b/autoconf2.1.cygport
> >> index c8b075f..6876c3c 100755
> >> --- a/autoconf2.1.cygport.orig
> >> +++ b/autoconf2.1.cygport
> >> @@ -28,7 +28,7 @@ src_compile() {
> >> cd ${B}
> >> cygconf --program-suffix=-2.13
> >> cygmake -j1
> >> - (makeinfo --no-split -I ${S} -o autoconf2.13.info autoconf.texi)
> >> + (makeinfo --no-split -o autoconf2.13.info ${S}/autoconf.texi)
>
> I'm not sure why this change is needed.
>
> >> }
> >>
> >> DIFF_EXCLUDES="autoconf.info standards.info stamp-vti version.texi"
> >>
> >> 2) Run 'export AUTOCONF_VERSION=2.13'
> >> 3) Run 'cygport autoconf2.1.cygport all'
--
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
Packages of mingw64 i686/x86_64 openssl 1.1.1 are empty!
Hello, if you look these packages: mingw64-x86_64-openssl-1.1.1q-0.1 mingw64-x86_64-openssl-1.1.1p-0.1 mingw64-i686-openssl-1.1.1q-0.1 mingw64-i686-openssl-1.1.1p-0.1 they are EMPTY. For example, the content of mingw64-x86_64-openssl-1.1.1q-0.1 is: usr/ usr/share/ usr/share/doc/ usr/share/doc/mingw64-x86_64-openssl/ usr/share/doc/mingw64-x86_64-openssl/AUTHORS usr/share/doc/mingw64-x86_64-openssl/CHANGES usr/share/doc/mingw64-x86_64-openssl/FAQ usr/share/doc/mingw64-x86_64-openssl/LICENSE usr/share/doc/mingw64-x86_64-openssl/NEWS usr/share/doc/mingw64-x86_64-openssl/README https://www.cygwin.com/cgi-bin2/package-cat.cgi?file=x86_64%2Fmingw64-x86_64-openssl%2Fmingw64-x86_64-openssl-1.1.1q-0.1=openssl Actually, if you get the "src" packages of openssl for mingw64 and you try to build them with cygport, it happens that includes, DLLs and libraries are installed directly into the *REAL* destination directory, into: /usr/x86_64-w64-mingw32/sys-root/mingw or: /usr/i686-w64-mingw32/sys-root/mingw instead of the installation directory created by cygport. I hope that you could fix them. Sincerely, Carlo Bramini. -- 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
[PATCH] SERIAL: Fix a copy-paste error in DTR setup
Hello, In commit 2dab880c963ce0204c3513d664f610b587a3e6a6 I did a mistake when I copied the new fhandler_serial::switch_modem_lines() from my modified 3.3.6 branch to the current master and I left a copy paste error that I corrected later. This patch fixes that error. Sorry for the trouble. Sincerely, Carlo Bramini. 0001-SERIAL-Fix-a-copy-paste-error-in-DTR-setup.patch Description: Binary data -- 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
Sharing my packages for CYGWIN
Hello, at this address I did a repository of packages that I made for CYGWIN: https://github.com/carlo-bramini/packages-cygwin Sometimes, when I need something not existing (or newer) into the official list of packages for CYGWIN, I upload it here. All these packages exists also in all major linux distributions. I hope that you will find it useful. === bzip2-1.0.8-1 These packages are an update to version 1.0.8 for the MinGW64 compilers. === ffmpeg-5.1.2-1 FFmpeg is a multimedia framework, able to decode, encode, transcode, mux, demux, stream, filter and play pretty much anything that humans and machines have created. Packages available for CYGWIN and MinGW64. === glfw-3.3.8 GLFW is an Open Source, multi-platform library for OpenGL, OpenGL ES and Vulkan development on the desktop. Packages available for CYGWIN and MinGW64. === liblo-0.31-1 Open Sound Control protocol for POSIX systems. Packages available for CYGWIN and MinGW64. === nettle-3.8.1-1 Low-level cryptographic library. Packages available for CYGWIN and MinGW64. === sbsms-2.3.0-1 A library for high quality time stretching and pitch scaling of audio. Packages available for CYGWIN and MinGW64. === soxr-0.1.3-1 These packages are an update of existing packages to version 0.1.3. Packages available for CYGWIN and MinGW64. === utfcpp-3.2.1-1 utf8cpp is a library for handling UTF-8 in C++. Packages available for CYGWIN and MinGW64. === wavpack-5.5.0-1 These packages are an update of existing packages to version 5.5.0. Packages available for CYGWIN and MinGW64. === win-iconv-0.0.8-1 These packages are an update to version 0.0.8 for the MinGW64 compilers. NOTE: current win-iconv provided by CYGWIN is bugged. The existing package version 0.0.6 is compiled with calls to InterlockedCompareExchange(), which are absolutely unused by the library. Probably, this happened because it was compiled with an ancient version of W32API, with those functions statically used into the header files. As result, this blocks the usage of win-iconv on older versions of Windows 9x/ME/NT4. I discovered this issue when compiling the SCUMMVM virtual machine, for running it on older versions of Windows. === xa65-2.3.13-1 xa is a cross-assembler for the 6502 and 65816 CPUs (and derivatives). Packages available for CYGWIN. === Sincerely, Carlo Bramini. -- 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
Error after updating gettext, missing libunistring5.
Hello, After Setup.exe updated gettext in my CYGWIN installation, I got this error when building a software: C:/cygwin64/bin/msgfmt.exe: error while loading shared libraries: cygunistring-5.dll: cannot open shared object file: No such file or directory After manually installing libunistring5, the problem disappeared. Probably, libunistring5 should be added as required dependency when installing/upgrading gettext. Sincerely, Carlo Bramini. -- 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
PATCH: TIOCMBIS/TIOCMBIC not working when using usbser.sys
I'm sending here the patch as you requested. I hope that you will find it useful. Sincerely, Carlo Bramini. 0001-PATCH-Cygwin-fix-TIOCMBIS-TIOCMBIC-not-working-when-.patch Description: Binary data -- 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
PATCH: TIOCMBIS/TIOCMBIC not working when using usbser.sys
Hello, into winsup/cygwin/fhandler/serial.cc, the function fhandler_serial::switch_modem_lines() is called when TIOCMBIS/TIOCMBIC are used into an ioctl() call. This function uses EscapeCommFunction() for setting and resetting RTS and DTR signals of a serial port. Unfortunately, this function does not work on USB CDC devices. This is not a true bug of a CYGWIN but an issue of the usbser.sys driver from Microsoft, from Windows 2000 to the latest Windows 11. Both 32bit and 64bit versions of the operating system are affected. Actually, I tested EscapeCommFunction() also when using a real UART, based on the traditional 16550 driver and it works fine. Using thirdy party CDC drivers, like the one provided by FTDI for their USB bridge chips, probably also works. However, it is also possible to drive the RTS/DTR signals by writing their state with SetCommState(), which proved to be working fine all types of connection. Here, I attached a patch that I made for fixing this issue. Anyways, in my opinion this is also a better solution for handling these signals since RTS/DTR can be set at the same time rather than having two separate calls with a visible delay between them. I was wondering if this fix could be imported into the core of CYGWIN and if it could be possible to include it also into the v3.3.x branch, since I have seen that 32bit support has been removed from Master branch recently. Thank you very much for your time. Sincerely, Carlo Bramini. winsup_cygwin_fhandler_serial.cc.patch Description: Binary data -- 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: Mingw pkg-config not working
Hello, I would like to report that I updated to the latest release, I tried to do some tests and it really seems that it has resolved the issue on my side. Thank you very much for your support. Sincerely, Carlo Bramini. Il giorno lun 6 apr 2020 alle ore 18:44 Yaakov Selkowitz ha scritto: > > On Sun, 2020-04-05 at 15:51 +0200, Carlo B. via Cygwin wrote: > > I wanted to report that I received a reply on the issue that I had opened > > here: > > > > https://todo.sr.ht/~kaniini/pkgconf/10#comment-7894 > > Thanks for following up. > > > The report has been closed and I got this reply: > > > > "You should use a symlink instead of a wrapper script when using the > > personality feature." > > > > I hope that somebody has understood what he means (posix is not > > exactly my primary platform) and it could be useful for fixing the > > issue. > > Yes, that gave me the information I needed. There is actually code > within pkgconf to automatically load $PREFIX.personality when called as > $PREFIX-pkg-config. This requires a packaging change on our end, which > I'm incorporating into the latest release. > > > Il giorno gio 26 mar 2020 alle ore 14:07 Carlo B. > > ha scritto: > > > Hello, > > > I implemented the solution to this problem as a patch to > > > pkgconf.cygport as requested. > > > I attached small patch to this email, which resolved the troubles with > > > CMake and Meson. > > > I hope that you will find it useful and some developers will gently > > > apply the correction to fix the issue. > > > > > > Thank you very much for your time and your support. > > > Sincerely, > > > > > > Carlo Bramini. > > > > > > Il giorno sab 22 feb 2020 alle ore 18:47 Jon Turney > > > ha scritto: > > > > On 20/02/2020 11:06, Carlo B. wrote: > > > > [...] > > > > > x86_64-w64-mingw32-pkg-config are emulated with a shell script, for > > > > > example the one for i686 is: > > > > > > > > > > #!/bin/sh > > > > > exec pkgconf --personality=i686-w64-mingw32 $@ > > > > > > > > > > But while this solution mostly works when you exec it from the command > > > > > line, it makes impossible to detect the presence of the tool from > > > > > meson and cmake build systems. > > > > > If you try to do this on the bash prompt, you get: > > > > > > > > > > $ i686-w64-mingw32-pkg-config --version > > > > > pkgconf: --version specified with other options or module names, > > > > > assuming --modversion. > > > > > Please specify at least one package name on the command line. > > > > > > > > > > and this is exactly what happens with those build systems (and perhaps > > > > > others, I don't know): it tries to call pkg-config with "--version" > > > > > and it executes the above script that calls pkgconf. But sadly, the > > > > > presence of the "--personality" option makes the process to fail, > > > > > because the "--version" is currently allowed only when no other > > > > > options are added. > > > > > And, for this reason, meson and cmake fail the detection of the tool. > > > > > > > > > > I have also filed an issue here for pkgconf: > > > > > https://todo.sr.ht/~kaniini/pkgconf/10 > > > > > because the solution is actually to ignore the presence of the > > > > > "--personality" option when the "--version" is written, but > > > > > unfortunately I have not received any feedback. > > > > > > > > > > So, I'm also writing here, with the hope that you could find a > > > > > solution. > > > > [...] > > > > > > > > Thanks for reporting this issue. > > > > > > > > I guess the alternative to fixing pkgconf would be to modify those > > > > wrapper scripts to detect when the parameters are just '--version' (or > > > > equivalent) and not use --personality in that case? > > > > > > > > These wrapper scripts are specific to cygwin (generated by the cygport, > > > > see [1]) > > > > > > > > It's possible other distros have more sophisticated wrapper scripts, > > > > which avoid this problem? > > > > > > > > If you do write or discover some improved wrapper scripts, a patch to > > > > [1] to update them would be appreciated. > > > > > > > > [1] > > > > https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/pkgconf.git;a=blob;f=pkgconf.cygport#l84 > > -- > Yaakov > > > -- > 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 -- 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 pkg-config not working (part 2)
Hello, After the release of the new pkg-conf, with the use of symlinks instead of a script for using the personality feature, I got some strange errors at compile time. Let's think to have a directory called "mylibrary" into your home directory, so you have a path for example "/home/carlo/mylibrary". In this directory create a file called "test.pc" with these lines: Name: test Description: test MinGW pkg-config on CYGWIN Version: 1.2.3 Libs: Cflags: -I/home/carlo/mylibrary Finally, add this directory to PKG_CONFIG_PATH environment variable. Now, if you type this command on the console: $ x86_64-w64-mingw32-pkg-config --cflags test -I/usr/x86_64-w64-mingw32/sys-root/home/carlo/mylibrary which is wrong, because it changed all references to "home/carlo" by appending "/usr/x86_64-w64-mingw32/sys-root". Instead, if I type: $ pkg-config --cflags test -I/home/carlo/mylibrary then the path it returned unchanged as expected. Sadly, this behavior forces you to rebuild everything and to move all stuff that you could normally have in your home directory into "/usr/x86_64-w64-mingw32/sys-root/home/carlo", othewise it won't work anymore. Am I doing something wrong or it is the expected result and there is another way to make things working again? Thank you very much. Sincerely. -- 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: Mingw pkg-config not working
Hello, I wanted to report that I received a reply on the issue that I had opened here: https://todo.sr.ht/~kaniini/pkgconf/10#comment-7894 The report has been closed and I got this reply: "You should use a symlink instead of a wrapper script when using the personality feature." I hope that somebody has understood what he means (posix is not exactly my primary platform) and it could be useful for fixing the issue. Thank you very much for your time. Sincerely, Carlo Bramini. Il giorno gio 26 mar 2020 alle ore 14:07 Carlo B. ha scritto: > > Hello, > I implemented the solution to this problem as a patch to > pkgconf.cygport as requested. > I attached small patch to this email, which resolved the troubles with > CMake and Meson. > I hope that you will find it useful and some developers will gently > apply the correction to fix the issue. > > Thank you very much for your time and your support. > Sincerely, > > Carlo Bramini. > > Il giorno sab 22 feb 2020 alle ore 18:47 Jon Turney > ha scritto: > > > > On 20/02/2020 11:06, Carlo B. wrote: > > [...] > > > x86_64-w64-mingw32-pkg-config are emulated with a shell script, for > > > example the one for i686 is: > > > > > > #!/bin/sh > > > exec pkgconf --personality=i686-w64-mingw32 $@ > > > > > > But while this solution mostly works when you exec it from the command > > > line, it makes impossible to detect the presence of the tool from > > > meson and cmake build systems. > > > If you try to do this on the bash prompt, you get: > > > > > > $ i686-w64-mingw32-pkg-config --version > > > pkgconf: --version specified with other options or module names, > > > assuming --modversion. > > > Please specify at least one package name on the command line. > > > > > > and this is exactly what happens with those build systems (and perhaps > > > others, I don't know): it tries to call pkg-config with "--version" > > > and it executes the above script that calls pkgconf. But sadly, the > > > presence of the "--personality" option makes the process to fail, > > > because the "--version" is currently allowed only when no other > > > options are added. > > > And, for this reason, meson and cmake fail the detection of the tool. > > > > > > I have also filed an issue here for pkgconf: > > > https://todo.sr.ht/~kaniini/pkgconf/10 > > > because the solution is actually to ignore the presence of the > > > "--personality" option when the "--version" is written, but > > > unfortunately I have not received any feedback. > > > > > > So, I'm also writing here, with the hope that you could find a solution. > > [...] > > > > Thanks for reporting this issue. > > > > I guess the alternative to fixing pkgconf would be to modify those > > wrapper scripts to detect when the parameters are just '--version' (or > > equivalent) and not use --personality in that case? > > > > These wrapper scripts are specific to cygwin (generated by the cygport, > > see [1]) > > > > It's possible other distros have more sophisticated wrapper scripts, > > which avoid this problem? > > > > If you do write or discover some improved wrapper scripts, a patch to > > [1] to update them would be appreciated. > > > > [1] > > https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/pkgconf.git;a=blob;f=pkgconf.cygport#l84 -- 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: Mingw pkg-config not working
Hello, I implemented the solution to this problem as a patch to pkgconf.cygport as requested. I attached small patch to this email, which resolved the troubles with CMake and Meson. I hope that you will find it useful and some developers will gently apply the correction to fix the issue. Thank you very much for your time and your support. Sincerely, Carlo Bramini. Il giorno sab 22 feb 2020 alle ore 18:47 Jon Turney ha scritto: > > On 20/02/2020 11:06, Carlo B. wrote: > [...] > > x86_64-w64-mingw32-pkg-config are emulated with a shell script, for > > example the one for i686 is: > > > > #!/bin/sh > > exec pkgconf --personality=i686-w64-mingw32 $@ > > > > But while this solution mostly works when you exec it from the command > > line, it makes impossible to detect the presence of the tool from > > meson and cmake build systems. > > If you try to do this on the bash prompt, you get: > > > > $ i686-w64-mingw32-pkg-config --version > > pkgconf: --version specified with other options or module names, > > assuming --modversion. > > Please specify at least one package name on the command line. > > > > and this is exactly what happens with those build systems (and perhaps > > others, I don't know): it tries to call pkg-config with "--version" > > and it executes the above script that calls pkgconf. But sadly, the > > presence of the "--personality" option makes the process to fail, > > because the "--version" is currently allowed only when no other > > options are added. > > And, for this reason, meson and cmake fail the detection of the tool. > > > > I have also filed an issue here for pkgconf: > > https://todo.sr.ht/~kaniini/pkgconf/10 > > because the solution is actually to ignore the presence of the > > "--personality" option when the "--version" is written, but > > unfortunately I have not received any feedback. > > > > So, I'm also writing here, with the hope that you could find a solution. > [...] > > Thanks for reporting this issue. > > I guess the alternative to fixing pkgconf would be to modify those > wrapper scripts to detect when the parameters are just '--version' (or > equivalent) and not use --personality in that case? > > These wrapper scripts are specific to cygwin (generated by the cygport, > see [1]) > > It's possible other distros have more sophisticated wrapper scripts, > which avoid this problem? > > If you do write or discover some improved wrapper scripts, a patch to > [1] to update them would be appreciated. > > [1] > https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/pkgconf.git;a=blob;f=pkgconf.cygport#l84 pkgconf.cygport.patch Description: Binary data -- 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: Build of glm-0.9.7.6-1-src.tar.xz does not work.
Hello, thank you very much, your updated script allowed me to complete the rebuilt process. KiCad requires GLM version 0.9.8 or newer for compiling. Unfortunately, I discovered that just replacing the old sources with the latest ones is not enough for updating the library. Since version 0.9.9.6, the install and uninstall targets have been removed from generated Makefile: https://github.com/g-truc/glm/commit/5f352ecce21bb1ab37fa56fac0f383c779b351a3#diff-af3b638bc2a3e6c650974192a53c7291 So, the current cygport script is able to work up to version 0.9.9.5, which is enough for the task anyways. Perhaps, the newer versions are using CMake directly for doing installation, but I have no idea how this is expected to work in cygport. Thank you very much for your time and your support. Sincerely, Il giorno dom 23 ago 2020 alle ore 18:04 Marco Atzeri via Cygwin ha scritto: > > On 23.08.2020 17:30, Jon Turney wrote: > > On 22/08/2020 06:00, Marco Atzeri via Cygwin wrote: > >> On 21.08.2020 10:35, Carlo B. via Cygwin wrote: > >>> Hello, > >>> I tried to rebuild glm-0.9.7.6-1-src.tar.xz but the "install" command > >>> does not work. > >>> I'm getting this error message: > >>> > >>>>>> Installing glm-0.9.7.6-1.noarch > >>> make: *** Nessuna regola per generare l'obiettivo «install». Arresto. > >>> *** ERROR: make install DESTDIR failed > >>> > >>> Translated in english, it should be something like this: > >>> "No rules to generate target <>. Stop." > >>> > > [...] > >> > >> the error is caused by the build system using now cmake+ninja for > >> the execution > >> > >> while mingw64-i686-glm and mingw64-x86_64-glm builds stay on the > >> previous cmake+make > >> > > I am a bit confused by this. What causes the default generator used by > > cmake to change? Having old .cygports break due to that seems bad. > > > > not sure. > I guess that if ninja is available the glm cmake settings > give it a precedence. > > It is also possible that the latest cmake is behaving differently > than previous one. > > Regards > Marco > > > -- > 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 -- 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
Build of glm-0.9.7.6-1-src.tar.xz does not work.
Hello, I tried to rebuild glm-0.9.7.6-1-src.tar.xz but the "install" command does not work. I'm getting this error message: >>> Installing glm-0.9.7.6-1.noarch make: *** Nessuna regola per generare l'obiettivo «install». Arresto. *** ERROR: make install DESTDIR failed Translated in english, it should be something like this: "No rules to generate target <>. Stop." I did NO changes to the files into glm-0.9.7.6-1-src.tar.xz. Strangely, cygport cannot build the CYGWIN package, but it builds mingw64-i686-glm and mingw64-x86_64-glm without errors. The CYGWIN and MinGW-W64 scripts have some differences actually. If somebody could check this, perhaps it would be good to also evaluate the chance to update all GLM packages to a newer version. The current source packages for all builds, CYGWIN and MinGW-W64, include a patch for fixing a bug into the sources; nowadays, this bug has been resolved into the official sources and into the latest 0.9.9.8 version: https://github.com/g-truc/glm/blob/master/test/gtc/gtc_round.cpp#L451 so the packages could be also simplified, because they do not need a patch anymore. I'm trying to update GLM because it is a required dependency for building KiCad, an Open Source Electronics Design software, so I hope that somebody could understand the first issue and also update the package with a newer version. Sincerely, -- 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
New version of GLM package?
Hello everyone, I'm wondering if it would be possible to release a newer version of this package and also fixing this bug if it is possible: https://cygwin.com/pipermail/cygwin/2020-August/245945.html Thank you very much for your time and your support. Sincerely. -- 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: New version of GLM package?
Hello, Il giorno dom 20 dic 2020 alle ore 14:32 Marco Atzeri via Cygwin ha scritto: > > On 20.12.2020 12:58, Carlo B. via Cygwin wrote: > > Hello, > > perhaps, if copying the files by hand is too heavy as another user > > said, it is possible to use version 0.9.9.5, as I had written here: > > > > https://cygwin.com/pipermail/cygwin/2020-August/245981.html > > > > it is not the latest version, but it is surely much newer than 0.9.7: > > you just need to change version number and remove the patch now > > useless from glm.cygport. > > > > Sincerely. > > > > bottom post here, please > > > 0.9.9.5 is up, let us know if there is any issue > > Regards > Marco Thank you very much, the package has been updated and it is working fine for me. Perhaps, while we are on the topic, it would be worth to update also the packages for MinGW. Sincerely. -- 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: New version of GLM package?
Hello, perhaps, if copying the files by hand is too heavy as another user said, it is possible to use version 0.9.9.5, as I had written here: https://cygwin.com/pipermail/cygwin/2020-August/245981.html it is not the latest version, but it is surely much newer than 0.9.7: you just need to change version number and remove the patch now useless from glm.cygport. Sincerely. Il giorno dom 20 dic 2020 alle ore 11:56 Marco Atzeri via Cygwin ha scritto: > > back on the mailing list > > On 20.12.2020 00:23, Hans-Bernhard Bröker wrote: > > Am 19.12.2020 um 19:21 schrieb Marco Atzeri via Cygwin: > > > >> for what I can see upstream has completely removed the install > >> section from the cmake files on 0.9.9.8 . > >> > >> unclear why they performed such issue. > > > > Possibly because there isn't all that much to install for a "library" > > that does not actually contain any compiled files, because it consists > > of nothing but inlined templates in header files. > > > > I.e. the binary package would just be a subset of the source in a > > different place. > > > > They seem to assume that the cmake script snippet they offer is > > sufficient to make the package count as "installed", because that (with > > an environment variable on top) allows the package to be found by CMake > > packages. The canonical method would probably be a CPack package. > > Hi Hans, > > I have impression debian is using such assumption and copy just the > files in the proper place. > It is annoying anyway. > > The fact that the github repository seems to not have the "issues" > is another annoying problem of this package. > > Regards > Marco > > > > > > -- > 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 -- 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
GLM for MinGW at same version of the ones for CYGWIN?
Hello, with reference to this thread: https://cygwin.com/pipermail/cygwin/2020-December/247106.html recently, GLM for CYGWIN has been updated to 0.9.9.5. I'm wondering if it would be possible to do the same thing and update the GLM packages for MinGW to the same version. An update will simplify some things because, unlike 0.9.7, no additional patches are required. Sincerely. -- 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: How to configuring a cross compiler for ARM Cortex M4F from GCC using Cygwin
Hello, Il giorno dom 28 feb 2021 alle ore 09:29 Welwin Joseph via Cygwin ha scritto: > > Hi, > I am new to the concept of configuring crosscompiler from GCC , can anyone > guide me on how to create/ Configure a cross compiler from GCC compiler for > ARM cortex M4F using Cygwin. I am using a windows 10 PC, my target is arm > cortexM4F TM4C129ENCPDT and I am using it as bareboard (no OS). > > > With regards, > Welwin > -- > 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 In my opinion, the best way for getting what you need is to use crosstool-ng: https://github.com/crosstool-ng/crosstool-ng You can clone the repo, build and install the program. Then, you can use ct-ng for configuring the build with the platform you want and finally start the creation. When the process finishes, you will find your cross compiler into the "x-tools" directory, inside your $HOME. When you get it, it is very easy to create a cross compiler: with this tool, I created an arm-none-eabi with NEWLIB, an aarch64 android cross compiler with NDK and an armhf linux cross compiler. I suggest you to do a try with this tiny thing. Please note that after you start the build, the tool automatically downloads the tar files with the sources that it needs, unless it already finds them in its directory, so be careful if you have a limited amount of internet traffic available. Sincerely. -- 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
Error with wxWidgets 3.0.5 for CYGWIN.
Hello, after updating some packages, I tried to rebuild my Kicad sources and I discovered that I could not do it anymore. During the process, it hangs with this error: error: 'wxRE_ADVANCED' was not declared in this scope. It seems that the new package of wxWidgets 3.0.5 had not been compiled with built-in regex support, including wxRE_ADVANCED option. I downgraded to wxWidgets 3.0.4 and I was able to build everything again. I hope that you could fix this issue. Sincerely. Carlo Bramini. -- 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
cygport: CYGCMAKE_SOURCE seems to have no effect.
Hello,
I'm trying to make a package for CYGWIN to provide liblo, but I'm
having some difficulties.
This library is available to the most used linux distributions (but
not limited to), here there is the link to the one into a Debian as
example:
https://packages.debian.org/buster/liblo-dev
I implemented a script for cygport but this is the output on the
console when I execute it:
$ cygport liblo.cygport all
>>> Preparing liblo-0.31-1.x86_64
>>> Unpacking source liblo-0.31.tar.gz
>>> Preparing working source directory
>>> Compiling liblo-0.31-1.x86_64
*** ERROR: cygcmake: cmake directory not found
The unique aspect of this library is that the CMakeLists.txt file is
not into the root of the source tree, but it is located into a
subfolder, see here:
https://github.com/radarsat1/liblo/tree/master/cmake
So, in my script, I configured ${CYGCMAKE_SOURCE} to point there, but
it still cannot make it working. Since it seems that I'm not able to
make it working in any way, I'm wondering if the behaviour of this
variable has been ever tested, so I'm writing here with the hope to
receive a suggestion.
Thank you very much for your support.
===> And this is the content of my liblo.cygport file:
inherit cmake
NAME="liblo"
VERSION=0.31
RELEASE=1
CATEGORY="Audio"
SUMMARY="Open Sound Control protocol for POSIX systems"
DESCRIPTION="Open Sound Control (OSC) is a protocol for communication
among computers, sound synthesizers, and other multimedia devices that
is optimized for modern networking technology."
HOMEPAGE="http://liblo.sourceforge.net/;
SRC_URI="http://downloads.sourceforge.net/liblo/liblo-${VERSION}.tar.gz;
PKG_NAMES="liblo1 liblo-devel"
PKG_IGNORE="
usr/share/doc/liblo/AUTHORS
usr/share/doc/liblo/COPYING
usr/share/doc/liblo/ChangeLog
usr/share/doc/liblo/NEWS
usr/share/doc/liblo/README
usr/share/doc/liblo/TODO
"
liblo1_CATEGORY="Libs"
liblo1_SUMMARY="${SUMMARY}"
liblo1_CONTENTS="
usr/bin/cyglo-7.dll
usr/bin/oscdump.exe
usr/bin/oscsend.exe
"
liblo_devel_CATEGORY="Libs"
liblo_devel_SUMMARY="${SUMMARY}"
liblo_devel_CONTENTS="
usr/include/lo/*
usr/lib/liblo.dll.a
usr/lib/pkgconfig/liblo.pc
usr/lib/cmake/liblo/libloConfig.cmake
"
CYGCMAKE_SOURCE="${S}/cmake"
--
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: cygport: CYGCMAKE_SOURCE seems to have no effect.
Hello,
in addition to my previous message, I did some experiments with the
code of cygport and I added these lines to
/usr/share/cygport/cygclass/cmake.cygclass:
echo "CYGCMAKE_SOURCE=${CYGCMAKE_SOURCE}"
echo "B=${B}"
echo "S=${S}"
echo "PWD=${PWD}"
and the result is:
CYGCMAKE_SOURCE=/cmake
B=/home/carlo/liblo.src/liblo-0.31-1.x86_64/build
S=/home/carlo/liblo.src/liblo-0.31-1.x86_64/src/liblo-0.31
PWD=/home/carlo/liblo.src/liblo-0.31-1.x86_64/build
*** ERROR: cygcmake: cmake directory not found
But ${CYGCMAKE_SOURCE} was set as:
CYGCMAKE_SOURCE="${S}/cmake"
So, it seems to me that there is at least a bug into the
documentation, because ${CYGCMAKE_SOURCE} does not seem to allow the
use of {S}.
I was able to make it working by writing:
CYGCMAKE_SOURCE="$(pwd)/${NAME}-${VERSION}-${RELEASE}.${ARCH}/src/${NAME}-${VERSION}/cmake"
but I don't know if this is the right way to do it and could be accepted or not.
Sincerely.
Il giorno gio 16 set 2021 alle ore 17:18 Carlo B.
ha scritto:
>
> Hello,
> I'm trying to make a package for CYGWIN to provide liblo, but I'm
> having some difficulties.
> This library is available to the most used linux distributions (but
> not limited to), here there is the link to the one into a Debian as
> example:
>
> https://packages.debian.org/buster/liblo-dev
>
> I implemented a script for cygport but this is the output on the
> console when I execute it:
>
> $ cygport liblo.cygport all
> >>> Preparing liblo-0.31-1.x86_64
> >>> Unpacking source liblo-0.31.tar.gz
> >>> Preparing working source directory
> >>> Compiling liblo-0.31-1.x86_64
> *** ERROR: cygcmake: cmake directory not found
>
> The unique aspect of this library is that the CMakeLists.txt file is
> not into the root of the source tree, but it is located into a
> subfolder, see here:
>
> https://github.com/radarsat1/liblo/tree/master/cmake
>
> So, in my script, I configured ${CYGCMAKE_SOURCE} to point there, but
> it still cannot make it working. Since it seems that I'm not able to
> make it working in any way, I'm wondering if the behaviour of this
> variable has been ever tested, so I'm writing here with the hope to
> receive a suggestion.
>
> Thank you very much for your support.
>
> ===> And this is the content of my liblo.cygport file:
>
> inherit cmake
>
> NAME="liblo"
> VERSION=0.31
> RELEASE=1
> CATEGORY="Audio"
> SUMMARY="Open Sound Control protocol for POSIX systems"
> DESCRIPTION="Open Sound Control (OSC) is a protocol for communication
> among computers, sound synthesizers, and other multimedia devices that
> is optimized for modern networking technology."
> HOMEPAGE="http://liblo.sourceforge.net/;
> SRC_URI="http://downloads.sourceforge.net/liblo/liblo-${VERSION}.tar.gz;
>
> PKG_NAMES="liblo1 liblo-devel"
> PKG_IGNORE="
> usr/share/doc/liblo/AUTHORS
> usr/share/doc/liblo/COPYING
> usr/share/doc/liblo/ChangeLog
> usr/share/doc/liblo/NEWS
> usr/share/doc/liblo/README
> usr/share/doc/liblo/TODO
> "
>
> liblo1_CATEGORY="Libs"
> liblo1_SUMMARY="${SUMMARY}"
> liblo1_CONTENTS="
> usr/bin/cyglo-7.dll
> usr/bin/oscdump.exe
> usr/bin/oscsend.exe
> "
> liblo_devel_CATEGORY="Libs"
> liblo_devel_SUMMARY="${SUMMARY}"
> liblo_devel_CONTENTS="
> usr/include/lo/*
> usr/lib/liblo.dll.a
> usr/lib/pkgconfig/liblo.pc
> usr/lib/cmake/liblo/libloConfig.cmake
> "
>
> CYGCMAKE_SOURCE="${S}/cmake"
--
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: cygport: CYGCMAKE_SOURCE seems to have no effect.
Hello,
thank you for your message,
> Worked just fine for a recent update of fortune-mod.
>
I gave a look to the source tree inside the package
fortune-mod-3.6.1-1-src.tar.xz and the CMakeLists.txt is into the
top-level directory, so it is not the same thing. And it seems to me
that ${CYGCMAKE_SOURCE} is not used by fortune-mod.cygport.
> See online or under your Cygwin directory:
>
> https://cygwin.github.io/cygport/cmake_cygclass.html#robo765
>
> cygstart /usr/share/doc/cygport/html/manual/cmake_cygclass.html
>
Yes, I had read that.
> Try directory specification rather than path - cygport often just DTRT:
>
> CYGCMAKE_SOURCE=cmake
>
Yes, I had also tried that, but without success.
Sincerely.
> --
> Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
>
> This email may be disturbing to some readers as it contains
> too much technical detail. Reader discretion is advised.
> [Data in binary units and prefixes, physical quantities in SI.]
>
>
> > ===> And this is the content of my liblo.cygport file:
> >
> > inherit cmake
> >
> > NAME="liblo"
> > VERSION=0.31
> > RELEASE=1
> > CATEGORY="Audio"
> > SUMMARY="Open Sound Control protocol for POSIX systems"
> > DESCRIPTION="Open Sound Control (OSC) is a protocol for communication
> > among computers, sound synthesizers, and other multimedia devices that
> > is optimized for modern networking technology."
> > HOMEPAGE="http://liblo.sourceforge.net/;
> > SRC_URI="http://downloads.sourceforge.net/liblo/liblo-${VERSION}.tar.gz;
> >
> > PKG_NAMES="liblo1 liblo-devel"
> > PKG_IGNORE="
> > usr/share/doc/liblo/AUTHORS
> > usr/share/doc/liblo/COPYING
> > usr/share/doc/liblo/ChangeLog
> > usr/share/doc/liblo/NEWS
> > usr/share/doc/liblo/README
> > usr/share/doc/liblo/TODO
> > "
> >
> > liblo1_CATEGORY="Libs"
> > liblo1_SUMMARY="${SUMMARY}"
> > liblo1_CONTENTS="
> > usr/bin/cyglo-7.dll
> > usr/bin/oscdump.exe
> > usr/bin/oscsend.exe
> > "
> > liblo_devel_CATEGORY="Libs"
> > liblo_devel_SUMMARY="${SUMMARY}"
> > liblo_devel_CONTENTS="
> > usr/include/lo/*
> > usr/lib/liblo.dll.a
> > usr/lib/pkgconfig/liblo.pc
> > usr/lib/cmake/liblo/libloConfig.cmake
> > "
> >
> > CYGCMAKE_SOURCE="${S}/cmake"
>
> --
> 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
--
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: cygport: CYGCMAKE_SOURCE seems to have no effect.
Hello,
> If you look at the Cygport Install Functions docs for docinto, ...into,
> defining target directories, you would see that an "absolute" path
> disables cygport from prefixing a subdirectory name with the package
> name, etc. so CMakeLists.txt is (linked) under ${S,B}/cmake, and cygport
> will automatically find that, so it should not be required or specified:
>
> https://cygwin.github.io/cygport/cmake_cygclass.html#robo767
>
cygport does not find it.
If CYGCMAKE_SOURCE is not defined into my liblo.cygport, it prints:
*** ERROR: cygcmake: cmake directory not found
If CYGCMAKE_SOURCE is defined as "${S}/cmake", it prints again:
*** ERROR: cygcmake: cmake directory not found
If CYGCMAKE_SOURCE is defined as an absolute path like I have written
in my previous message, it finally works.
> "This is only necessary when the top-level CMakeLists.txt is not in $S
> and cygcmake is not being run in the same subdirectory of $B which under
> $S contains the top-level CMakeLists.txt. (IOW if the top-level
> CMakeLists.txt is in $S/unix and cygcmake is run from $B/unix, setting
> CYGCMAKE_SOURCE would not be necessary.)"
"This is only necessary when the top-level CMakeLists.txt is not in $S"
true, it is under "$S/cmake"
"and cygcmake is not being run in the same subdirectory of $B which
under $S contains the top-level CMakeLists.txt."
also true in my opinion.
It could be possible that I have not understood something, but however
there is also an easy way:
- my cygport file was included in my first email and also attached
into this last one.
- the source archive can be downloaded from this direct link:
http://downloads.sourceforge.net/liblo/liblo-0.31.tar.gz
- put both them into a directory and execute:
cygport liblo.cygport all
and you will see with your eyes that it does not work.
Perhaps, there are other extra things to write in my cygport that I
don't know about.
thank you very much for your support.
Sincerely.
liblo.cygport
Description: Binary data
--
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
CYGPORT: using WAF build system.
Hello, I would like to make a package with LV2 plugins for CYGWIN. The problem is that those plugins are using the WAF build system and it is not clear to me how to proceed. Do you know if some of the existing packages for CYGWIN are using WAF, so that they could be uses as example for starting? Thank you very much. Sincerely. -- 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: CYGPORT: using WAF build system.
Hello, thank you very much for the replies. I have successfully compiled lv2, lilv, serd, sord, sratom (but not suil yet) for CYGWIN and I made the packages for building the master branch of Audacity. I also tried to do the same thing for i686 and x86_64, by using provided MinGW-w64 cross compiler, but I'm getting this message: *** ERROR: waf.cygclass does not yet support cross-compiling I hope that somebody may fix this in the future. Sincerely. Il giorno ven 15 ott 2021 alle ore 17:22 Brian Inglis ha scritto: > > On 2021-10-14 04:02, Carlo B. via Cygwin wrote: > > I would like to make a package with LV2 plugins for CYGWIN. > > The problem is that those plugins are using the WAF build system and > > it is not clear to me how to proceed. Do you know if some of the > > existing packages for CYGWIN are using WAF, so that they could be uses > > as example for starting? > > In connection with other queries, I just came across a few lv2 packages > already available in Cygwin: > > lv2 > lv2core > lv2-calf > lv2-devel > lv2-examples > lv2-swh > > slv2 > libslv2_9 > libslv2-devel > > with cygport build control script definitions and patches available > which use WAF: > > https://cygwin.com/git-cygwin-packages?p=git/cygwin-packages/lv2.git > https://cygwin.com/git-cygwin-packages?p=git/cygwin-packages/lv2-swh.git > https://cygwin.com/git-cygwin-packages?p=git/cygwin-packages/slv2.git > > so you could install cygport and any *lv2* package dependencies, clone > these repos or download and untar the current source packages which > contain these files plus upstream tars, and build the current packages > as a proof of concept and way of learning cygport, before trying to > build more current versions. > > The simple approach to running cygport is to change to the directory > containing the .cygport definitions and .patch file(s) or move them to a > working directory (normally named for the source package), then run e.g. > > $ cygport lv2.cygport get prep > > which downloads the upstream (not Cygwin) package sources for the > specified version to a central cache directory, creates a package build > directory, copies or untars sources if required, and (tries to) apply > any patches to the original sources, to give you working sources, which > you can then use to compile and make install-able Cygwin packages for > the current arch. > You can try one of the following examples, depending whether you want to > watch the builds run or review the results later: > > $ cygport lv2.cygport all |& tee lv2-cygport-`arch`-all.log > > $ cygport lv2.cygport all | tee lv2-cygport-`arch`-all.log 2>&1 > > $ cygport lv2.cygport all &> tee lv2-cygport-`arch`-all.log & > >$ cygport lv2.cygport all > tee lv2-cygport-`arch`-all.log 2>&1 & > > Browse the created build subdirectories to see what is produced and > review all detail logs generated during the process. > > After a successful build and package creation, it is always a good idea > to try to run any test suites with: > >$ cygport lv2.cygport check > tee lv2-cygport-`arch`-check.log 2>&1 & > > I use the cygport command check instead of test as test is used > ambiguously by cygport, as it may also refer to test vs stable or > production releases produced by cygport using commands e.g. all-test. > > -- > Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada > > This email may be disturbing to some readers as it contains > too much technical detail. Reader discretion is advised. > [Data in binary units and prefixes, physical quantities in SI.] -- 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: CYGPORT: using WAF build system.
Hello,
in addition to my previous message, I would like to say that I tried
to build the existing old sources of lv2-1.12.0-1.x86_64 package, but
an error is generated.
I attached what happens and I hope that you will find this report useful.
Sincerely.
=
$ cygport lv2.cygport all
>>> Preparing lv2-1.12.0-1.x86_64
>>> Unpacking source lv2-1.12.0.tar.bz2
*** Info: applying patch 1.12.0-cygwin-shlib.patch (-p2):
patching file plugins/eg-amp.lv2/wscript
patching file plugins/eg-fifths.lv2/wscript
patching file plugins/eg-metro.lv2/wscript
patching file plugins/eg-midigate.lv2/wscript
patching file plugins/eg-sampler.lv2/wscript
patching file plugins/eg-scope.lv2/wscript
>>> Preparing working source directory
>>> Compiling lv2-1.12.0-1.x86_64
Traceback (most recent call last):
File
"/home/Carlo/packages/lv2.src/lv2.src/a/lv2-1.12.0-1.src/lv2-1.12.0-1.x86_64/build/.waf3-1.8.5-3556be08f33a5066528395b11fed89fa/waflib/Node.py",
line 293, in ant_iter
raise StopIteration
StopIteration
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File
"/home/Carlo/packages/lv2.src/lv2.src/a/lv2-1.12.0-1.src/lv2-1.12.0-1.x86_64/build/.waf3-1.8.5-3556be08f33a5066528395b11fed89fa/waflib/Scripting.py",
line 103, in waf_entry_point
run_commands()
File
"/home/Carlo/packages/lv2.src/lv2.src/a/lv2-1.12.0-1.src/lv2-1.12.0-1.x86_64/build/.waf3-1.8.5-3556be08f33a5066528395b11fed89fa/waflib/Scripting.py",
line 160, in run_commands
parse_options()
File
"/home/Carlo/packages/lv2.src/lv2.src/a/lv2-1.12.0-1.src/lv2-1.12.0-1.x86_64/build/.waf3-1.8.5-3556be08f33a5066528395b11fed89fa/waflib/Scripting.py",
line 133, in parse_options
Context.create_context('options').execute()
File
"/home/Carlo/packages/lv2.src/lv2.src/a/lv2-1.12.0-1.src/lv2-1.12.0-1.x86_64/build/.waf3-1.8.5-3556be08f33a5066528395b11fed89fa/waflib/Options.py",
line 141, in execute
super(OptionsContext,self).execute()
File
"/home/Carlo/packages/lv2.src/lv2.src/a/lv2-1.12.0-1.src/lv2-1.12.0-1.x86_64/build/.waf3-1.8.5-3556be08f33a5066528395b11fed89fa/waflib/Context.py",
line 92, in execute
self.recurse([os.path.dirname(g_module.root_path)])
File
"/home/Carlo/packages/lv2.src/lv2.src/a/lv2-1.12.0-1.src/lv2-1.12.0-1.x86_64/build/.waf3-1.8.5-3556be08f33a5066528395b11fed89fa/waflib/Context.py",
line 133, in recurse
user_function(self)
File
"/home/Carlo/packages/lv2.src/lv2.src/a/lv2-1.12.0-1.src/lv2-1.12.0-1.x86_64/build/wscript",
line 25, in options
opt.load('compiler_c')
File
"/home/Carlo/packages/lv2.src/lv2.src/a/lv2-1.12.0-1.src/lv2-1.12.0-1.x86_64/build/.waf3-1.8.5-3556be08f33a5066528395b11fed89fa/waflib/Context.py",
line 89, in load
fun(self)
File
"/home/Carlo/packages/lv2.src/lv2.src/a/lv2-1.12.0-1.src/lv2-1.12.0-1.x86_64/build/.waf3-1.8.5-3556be08f33a5066528395b11fed89fa/waflib/Tools/compiler_c.py",
line 36, in options
opt.load_special_tools('c_*.py',ban=['c_dumbpreproc.py'])
File
"/home/Carlo/packages/lv2.src/lv2.src/a/lv2-1.12.0-1.src/lv2-1.12.0-1.x86_64/build/.waf3-1.8.5-3556be08f33a5066528395b11fed89fa/waflib/Context.py",
line 296, in load_special_tools
lst=self.root.find_node(waf_dir).find_node('waflib/extras').ant_glob(var)
File
"/home/Carlo/packages/lv2.src/lv2.src/a/lv2-1.12.0-1.src/lv2-1.12.0-1.x86_64/build/.waf3-1.8.5-3556be08f33a5066528395b11fed89fa/waflib/Node.py",
line 342, in ant_glob
ret=[x for x in
self.ant_iter(accept=accept,pats=[to_pat(incl),to_pat(excl)],maxdepth=kw.get('maxdepth',25),dir=dir,src=src,remove=kw.get('remove',True))]
File
"/home/Carlo/packages/lv2.src/lv2.src/a/lv2-1.12.0-1.src/lv2-1.12.0-1.x86_64/build/.waf3-1.8.5-3556be08f33a5066528395b11fed89fa/waflib/Node.py",
line 342, in
ret=[x for x in
self.ant_iter(accept=accept,pats=[to_pat(incl),to_pat(excl)],maxdepth=kw.get('maxdepth',25),dir=dir,src=src,remove=kw.get('remove',True))]
RuntimeError: generator raised StopIteration
*** ERROR: waf configure failed
Il giorno ven 15 ott 2021 alle ore 17:22 Brian Inglis
ha scritto:
>
> On 2021-10-14 04:02, Carlo B. via Cygwin wrote:
> > I would like to make a package with LV2 plugins for CYGWIN.
> > The problem is that those plugins are using the WAF build system and
> > it is not clear to me how to proceed. Do you know if some of the
> > existing packages for CYGWIN are using WAF, so that they could be uses
> > as example for starting?
>
> In connection with other queries, I just came across a few lv2 packages
> already available in Cygwin:
>
> lv2
> lv2core
> lv2-calf
> lv2-devel
> lv2-examples
> lv2-swh
>
> slv2
> libslv2_9
> libslv2-devel
>
> with cygport build control script definitions and patches available
> which use WAF:
>
> ht
Re: Bug in CYGWIN's UUID library: GUID_NULL not found.
I see... problem solved.
Thank you very much.
Sincerely,
Carlo Bramini.
Il giorno lun 20 feb 2023 alle ore 17:01 Takashi Yano
ha scritto:
>
> On Mon, 20 Feb 2023 16:48:50 +0100
> "Carlo B. wrote:
> > Hello,
> > I think that there is a bug into the uuid library, the one to be used
> > with the W32API for the POSIX core.
> > Please have a look to the following tiny test code:
> >
> > //
> > #include
> > #include
> > #include
> > #include
> >
> > int main()
> > {
> >
> > printf("GUID_NULL=\"%08X-%04X-%04X-%02X%02X-%02X%02X%02X%02X%02X%02X\"\n",
> > GUID_NULL.Data1,
> > GUID_NULL.Data2, GUID_NULL.Data3,
> > GUID_NULL.Data4[0], GUID_NULL.Data4[1],
> > GUID_NULL.Data4[2], GUID_NULL.Data4[3],
> > GUID_NULL.Data4[4], GUID_NULL.Data4[5],
> > GUID_NULL.Data4[6], GUID_NULL.Data4[7]
> > );
> >
> > return 0;
> > }
> > //
> >
> > Compiling it with x86_64-pc-cygwin or i686-pc-cygwin does not work:
> >
> > $ gcc e.c -o e.exe -luuid
> > /usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld:
> > /tmp/ccyJK3d9.o:e.c:(.rdata$.refptr.GUID_NULL[.refptr.GUID_NULL]+0x0):
> > undefined reference to `GUID_NULL'
> > collect2: error: ld returned 1 exit status
>
> You linked /usr/lib/libuuid.dll.a rather than /usr/lib/w32api/libuuid.a.
> You might want: gcc e.c -o e.exe -L/usr/lib/w32api -luuid
>
> --
> Takashi Yano
--
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
Bug in CYGWIN's UUID library: GUID_NULL not found.
Hello,
I think that there is a bug into the uuid library, the one to be used
with the W32API for the POSIX core.
Please have a look to the following tiny test code:
//
#include
#include
#include
#include
int main()
{
printf("GUID_NULL=\"%08X-%04X-%04X-%02X%02X-%02X%02X%02X%02X%02X%02X\"\n",
GUID_NULL.Data1,
GUID_NULL.Data2, GUID_NULL.Data3,
GUID_NULL.Data4[0], GUID_NULL.Data4[1],
GUID_NULL.Data4[2], GUID_NULL.Data4[3],
GUID_NULL.Data4[4], GUID_NULL.Data4[5],
GUID_NULL.Data4[6], GUID_NULL.Data4[7]
);
return 0;
}
//
Compiling it with x86_64-pc-cygwin or i686-pc-cygwin does not work:
$ gcc e.c -o e.exe -luuid
/usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld:
/tmp/ccyJK3d9.o:e.c:(.rdata$.refptr.GUID_NULL[.refptr.GUID_NULL]+0x0):
undefined reference to `GUID_NULL'
collect2: error: ld returned 1 exit status
But it works fine when using MinGW-w64 compilers:
$ x86_64-w64-mingw32-gcc e.c -o e.exe -luuid
$ ./e.exe
GUID_NULL="----"
I discovered this issue when making a new FluidSynth package for
CYGWIN for my repository of packages.
Can you confirm it?
Thank you very much for your time.
Sincerely,
Carlo Bramini.
--
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
Installing/upgrading only NOARCH packages.
Hello, after the 32-bit port of CYGWIN has been obsoleted, I was looking for a way for installing or upgrading the NOARCH packages, like the libraries for the mingw cross compilers for example. Unfortunately, I have not found an existing way for doing it. Is it possible to do it? Otherwise, I'm searching for the sources of the setup program for adding this feature in my local installation. I have seen that setup utility has a "--arch" option, but it accepts only "x86_64" or "x86", according to the "--help" printed on screen. So, I'm planning to add a "noarch" in addition to "x86_64" and "x86" to this option. Where can I get the latest development sources of the setup utility? Thank you very much for your replies. Sincerely, Carlo Bramini. -- 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
