Re: Putting packages up for adoption
On Fri, 2020-03-20 at 10:29 +0100, Jan Nijtmans wrote: > Op vr 20 mrt. 2020 om 05:03 schreef Yaakov Selkowitz: > > To that end, in the best interest of the community, please consider my > > packages up for adoption. I don't expect that any one person will take > > all of them; some are obsolete and due for removal anyway, some should > > be picked up as soon as possible, and others might just end up > > bitrotting if nobody is interested in them. However, in whatever there > > is interest (or need), hopefully what is there now will serve as a > > strong foundation to on which to continue to build. > > I'm willing to adopt the tcl-related packages: > > mingw64-i686-tcl Yaakov Selkowitz > mingw64-i686-tk Yaakov Selkowitz > mingw64-x86_64-tcl Yaakov Selkowitz > mingw64-x86_64-tkYaakov Selkowitz > tcl Yaakov Selkowitz > tcl-itcl Yaakov Selkowitz > tcl-itk Yaakov Selkowitz > tcl-iwidgets Yaakov Selkowitz > tcl-tix Yaakov Selkowitz > tcl-tk Yaakov Selkowitz > tcl-togl Yaakov Selkowitz A word of caution wrt Tcl/Tk for Cygwin: upstream incorrectly treats Cygwin as a Win32 platform, necessitating extensive patches to make it comply with *NIX/X11 standards. These patches CANNOT be dropped without breaking compatibility, since Win32 and X11 APIs do not interact. Fortunately, Tcl/Tk moves rather slowly, so the existing patches should serve you well for some time. -- Yaakov
Re: Putting packages up for adoption
Yaakov Selkowitz writes: > Case sensitivity. The modules depend on symbols both from other > dependent modules as well as the C libraries which they bind. While > for many of the libraries these names are slightly different, e.g. > -lPango and -lpango-1.0, in the case of Cairo, the only difference is > case (-lCairo -lcairo). I'd seen that and then dismissed it… > FWIW I always ran Cygwin with case sensitivity > on (except when Windows upgrades forcibly disabled that behind my > back), as these issues are not infrequent particularly when building. I'm running into it for the first time… :-) > ExtUtils::Depends used to use full paths for the module imports, e.g. > /usr/lib/perl5//libPango.dll.a instead of -L/usr/lib/perl5/ > -lPango, but I guess that changed at some point. If building with case > sensitivity enabled is not an option, then I suggest patching EU::D to > use full paths for module imports again. It uses the pkgconf system it would appear, so I've monkey-patched cairo.pc accordingly. Not sure what will be the final solution. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: Putting packages up for adoption
On Sun, 2020-03-22 at 17:36 +0100, ASSI wrote: > ASSI writes: > > I see the same thing. I have no idea why the linker doesn't pick up the > > reference, but it produces exactly the same error when removing > > "-lcairo" from the link list, which looks suspicious. > > Indeed if I replace that library reference with "-l:libcairo.dll.a" then > things work. The other cairo-dependent modules seem to have the same > problem. Could anybody with some more knowledge of binutils than me > explain why that happens and how to fix it? Case sensitivity. The modules depend on symbols both from other dependent modules as well as the C libraries which they bind. While for many of the libraries these names are slightly different, e.g. -lPango and -lpango-1.0, in the case of Cairo, the only difference is case (-lCairo -lcairo). FWIW I always ran Cygwin with case sensitivity on (except when Windows upgrades forcibly disabled that behind my back), as these issues are not infrequent particularly when building. ExtUtils::Depends used to use full paths for the module imports, e.g. /usr/lib/perl5//libPango.dll.a instead of -L/usr/lib/perl5/ -lPango, but I guess that changed at some point. If building with case sensitivity enabled is not an option, then I suggest patching EU::D to use full paths for module imports again. HTH, -- Yaakov
Re: Putting packages up for adoption
Marco Atzeri via Cygwin-apps writes: > I am planning to update all the packages left behind > by the Perl update > (Except if Achim is interested in them) > > perl-Glib already built > perl-Cairo > perl-Gtk2 > perl-Pango I currently have that stack in evaluation (since Pango needs those). It looks like I have most or all of the needed development libraries in my installation already. If that also holds true for the rest of the Gtk2 modules I'll just take them all… I'll look at Gtk3 and Gnome again later, give me a few days. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
setup 2.904 release candidate - please test
A new setup release candidate is available at: https://cygwin.com/setup/setup-2.904.x86_64.exe (64 bit version) https://cygwin.com/setup/setup-2.904.x86.exe(32 bit version) Please test, and report any problems here. This is not the place for setup feature requests. Changes compared to 2.903: - The '--disable-old-keys' option is still accepted, but is now the default. - Add an '--enable-old-keys' option, for if you really need to install from an old mirror snapshot, for some reason. - The Start Menu folder used for 32-bit installs on WoW64 is now named 'Cygwin (32-bit)', to avoid collision with the name used for 64-bit installs. - Fix a memory allocation error which could (very rarely) cause crashes during package installation.
Re: Putting packages up for adoption
ASSI writes: > I see the same thing. I have no idea why the linker doesn't pick up the > reference, but it produces exactly the same error when removing > "-lcairo" from the link list, which looks suspicious. Indeed if I replace that library reference with "-l:libcairo.dll.a" then things work. The other cairo-dependent modules seem to have the same problem. Could anybody with some more knowledge of binutils than me explain why that happens and how to fix it? Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada
Re: Putting packages up for adoption
Marco Atzeri via Cygwin-apps writes: > I already built > > perl-GLIB > perl-Cairo Yes, these are easy to build, I've even had the devel packages already installed. > but perl-Pango is failing > > [ LD blib/arch/auto/Pango/Pango.dll ] > /usr/lib/gcc/x86_64-pc-cygwin/9.3.0/../../../../x86_64-pc-cygwin/bin/ld: > xs/PangoCairo.o: in function > `gtk2perl_pango_cairo_shape_renderer_func': > /usr/src/debug/perl-Pango-1.227-3/xs/PangoCairo.xs:44: undefined > reference to `cairo_reference' > /usr/src/debug/perl-Pango-1.227-3/xs/PangoCairo.xs:44:(.text+0x21e): > relocation truncated to fit: R_X86_64_PC32 against undefined symbol > `cairo_reference' > > for what I see cairo_reference is in /usr/lib/libcairo.dll.a > So I am blocked and you can take over I see the same thing. I have no idea why the linker doesn't pick up the reference, but it produces exactly the same error when removing "-lcairo" from the link list, which looks suspicious. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
