On Wed, Oct 22, 2014 at 4:04 PM, Óscar Fuentes <[email protected]> wrote:
> Ray Donnelly <[email protected]>
> writes:
>
>> Top posting because I'm replying to all the stuff written in this thread:
>>
>> Óscar worried that doing:
>>    CC="gcc -static-libgcc" configure ...
>>
>> .. would override users' versions of CC, well you can do tests with
>> bash to get around that:
>>
>> if [ -z "$CC" ]; then
>>   export CC="gcc -static-libgcc"
>> else
>>   export CC="$CC -static-libgcc"
>> fi
>
> Ok, thanks.
>
> [snip]
>
>> Óscar, can you provide PKGBUILDs for everything you involved in your
>> crash please?
>
> Here is the PKGBUILD of the Tktable Tcl binary extension:
>
> # Begin PKGBUILD
> # Maintainer: Oscar Fuentes <[email protected]>
> # Based on Arch's PKGBUILD
>
> _realname=tktable
> pkgname="${MINGW_PACKAGE_PREFIX}-${_realname}"
> _pkgnameactual=Tktable
> pkgver=2.10
> pkgrel=1
> pkgdesc="A full-featured 2D table widget for Tk."
> arch=('any')
> url="http://tktable.sourceforge.net/";
> license=('custom')
> depends=("${MINGW_PACKAGE_PREFIX}-tk")
> source=("http://sourceforge.net/projects/tktable/files/${_realname}/$pkgver/${_pkgnameactual}${pkgver}.tar.gz";)
> md5sums=('ecdd96b39ad49b820bf084eb1c786f66')
>
> build() {
>   mkdir -p "${srcdir}/build-${CARCH}"
>   cd "${srcdir}/build-${CARCH}"
>   # Fix the package name
>   # mv "$_pkgnameactual$pkgver" "$pkgname$pkgver"
>   # cd "$pkgname$pkgver"
>   [ "${MINGW_CHOST}" = 'x86_64-w64-mingw32' ] && enable64bit='--enable-64bit'
>   "${srcdir}"/${_pkgnameactual}${pkgver}/configure \
>     --prefix=${MINGW_PREFIX} \
>     $enable64bit
>   make
> }
>
> package() {
>   cd "${srcdir}/build-${CARCH}"
>   make DESTDIR="$pkgdir/" install
> }
> # end PKGBUILD
>
>
> Build that for i686, install and then run
>
> wish test.tcl
>
>
> where test.tcl is
>
> # Begin test.tcl
> package require Tktable
> table .t
> pack .t
> # end test.tcl
>

Thanks, you also had changes to tcl/tk to allow the debug/!strip
options to behave, care to make a pull request for that?

>
> Now simply close the window that the previous command created by
> clicking on its close button. There are two dialogs about a malfunction
> on the application. This is on Windows XP 32 bits, I suppose it is the
> same on other versions.
>
>
>> To me, the crux of the problem is that no one should *ever* set
>> -static-libgcc unless they are building an entirely static executable
>> that never calls LoadLibrary() and no one should ever mix two
>> different libgcc versions. Please demonstrate the problem outside of
>> those conditions guys. Adding -static-libgcc is *not* a solution, nor
>> is it a workaround.
>
> Then we are screwed, because this problem has no other known solution.
>
>
> ------------------------------------------------------------------------------
> Comprehensive Server Monitoring with Site24x7.
> Monitor 10 servers for $9/Month.
> Get alerted through email, SMS, voice calls or mobile push notifications.
> Take corrective actions from your mobile device.
> http://p.sf.net/sfu/Zoho
> _______________________________________________
> Msys2-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/msys2-users

------------------------------------------------------------------------------
_______________________________________________
Msys2-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/msys2-users

Reply via email to