Re: 32bit GS on 64bit Win rebuild base from src

[Richard Frith-Macdonald]

> On 6 Aug 2016, at 10:57, Giah de Barag  wrote:
> 
> Setup:
>w2k8 r2 x64
>GNUstep installed using 32-bit installer
> 
> 
> Goal:
>Rebuild just base from source
> 
> 
> Procedure:
>check out core/base from svn
>cd core/base; ./configure
> 
> 
> Result:
>conftest.exe crashes in FFI library test.
> 
> 
> Question:
>Must the host be changed to 32-bit, or can this work somehow?


The installer is a 32bit distribution ... uyou can't use it to build 64bit code.

If you want a 64bit build, you need to dowload a 64bit development environment 
(msys2 and  a load of 64bit libraries) and then configur/build/install gnustep 
from source.

There are step by step instructions for getting the depedencies into an msys2 
64bit environment in svn at tools/scripts/trunk/install-dependencies-msys2-64bit

You can see that script via http at 
http://svn.gna.org/viewcvs/gnustep/tools/scripts/trunk/install-dependencies-msys2-64bit


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: 32bit GS on 64bit Win rebuild base from src

[Giah de Barag]

No I just want to build 32-bit code. I downloaded GNUstep, installed it, and 
now I want to just have it re-build part of itself (base) as is.

On Aug 6, 2016, at 06:13, Richard Frith-Macdonald 
 wrote:


> On 6 Aug 2016, at 10:57, Giah de Barag  wrote:
> 
> Setup:
>   w2k8 r2 x64
>   GNUstep installed using 32-bit installer
> 
> 
> Goal:
>   Rebuild just base from source
> 
> 
> Procedure:
>   check out core/base from svn
>   cd core/base; ./configure
> 
> 
> Result:
>   conftest.exe crashes in FFI library test.
> 
> 
> Question:
>   Must the host be changed to 32-bit, or can this work somehow?


The installer is a 32bit distribution ... uyou can't use it to build 64bit code.

If you want a 64bit build, you need to dowload a 64bit development environment 
(msys2 and  a load of 64bit libraries) and then configur/build/install gnustep 
from source.

There are step by step instructions for getting the depedencies into an msys2 
64bit environment in svn at tools/scripts/trunk/install-dependencies-msys2-64bit

You can see that script via http at 
http://svn.gna.org/viewcvs/gnustep/tools/scripts/trunk/install-dependencies-msys2-64bit



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: 32bit GS on 64bit Win rebuild base from src

[Giah de Barag]

If I use the 32-bit distribution to try to rebuild base, it fails here in the 
config.ffi.c test:

Breakpoint 2, main () at config/config.ffi.c:39
39ffi_closure *pcl = ffi_closure_alloc(sizeof(ffi_closure), &code);
(gdb) p sizeof(ffi_closure)
$1 = 64


On Aug 6, 2016, at 06:15, Giah de Barag  wrote:

No I just want to build 32-bit code. I downloaded GNUstep, installed it, and 
now I want to just have it re-build part of itself (base) as is.

On Aug 6, 2016, at 06:13, Richard Frith-Macdonald 
 wrote:


> On 6 Aug 2016, at 10:57, Giah de Barag  wrote:
> 
> Setup:
>  w2k8 r2 x64
>  GNUstep installed using 32-bit installer
> 
> 
> Goal:
>  Rebuild just base from source
> 
> 
> Procedure:
>  check out core/base from svn
>  cd core/base; ./configure
> 
> 
> Result:
>  conftest.exe crashes in FFI library test.
> 
> 
> Question:
>  Must the host be changed to 32-bit, or can this work somehow?


The installer is a 32bit distribution ... uyou can't use it to build 64bit code.

If you want a 64bit build, you need to dowload a 64bit development environment 
(msys2 and  a load of 64bit libraries) and then configur/build/install gnustep 
from source.

There are step by step instructions for getting the depedencies into an msys2 
64bit environment in svn at tools/scripts/trunk/install-dependencies-msys2-64bit

You can see that script via http at 
http://svn.gna.org/viewcvs/gnustep/tools/scripts/trunk/install-dependencies-msys2-64bit



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: 32bit GS on 64bit Win rebuild base from src

[Riccardo Mottola]

Hi,


On 06/08/2016 11:57, Giah de Barag wrote:

Procedure:
 check out core/base from svn
 cd core/base; ./configure


I think that more flags are needed: to make something clean, you need to 
configure and build base and "overwrite" cleanly the existing.


Adam, what flags do you use to configure base for our distribution?


Riccardo

PS: we just released the new GNUstep core installers, so they are 
up-to-daet with latest release.



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: 32bit GS on 64bit Win rebuild base from src

[Giah de Barag]

Goal:

1. Install installer on Win64 (w2k8 r2 x64)
2. Build base


Question:

It crashes in configure. Can I achieve the above goal with a change in steps 
(below)? Step-by-step instructions sincerely appreciated. Thank you.


Steps:

1. install w2k8 r2 x64 on a vm
2. install gnustep from installers
   gnustep-msys-system-0.30.0-setup.exe
   gnustep-core-0.35.0-setup.exe
   gnustep-devel-1.4.0-setup.exe
3. get source http://svn.gna.org/svn/gnustep/modules/core
4. cd core/base; ./configure


Result:

The FFI test fails. Here are the details.


Building the FFI test:

gcc -o conftest.exe -g -O2 -march=i586  -I/GNUstep/Local/Library/Headers 
-I/GNUstep/Local/Library/Headers -I/GNUstep/System/Library/Headers 
-I/GNUstep/System/Library/Headers  -shared-libgcc 
-L/GNUstep/Local/Library/Libraries -L/GNUstep/Local/Library/Libraries 
-L/GNUstep/System/Library/Libraries -L/GNUstep/System/Library/Libraries 
conftest.c -lffi -lbfd -liberty -lintl  -lpthread -lz


Running the FFI test:

Breakpoint 2, main () at config/config.ffi.c:39
39ffi_closure *pcl = ffi_closure_alloc(sizeof(ffi_closure), &code);
(gdb) n

Program received signal SIGILL, Illegal instruction.
0x6b742764 in ffi_closure_alloc () from 
c:\gnustep\gnustep\system\tools\libffi-6.dll
(gdb) 



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: 32bit GS on 64bit Win rebuild base from src

[Riccardo Mottola]

Hi,


On 06/08/2016 19:25, Giah de Barag wrote:

1. install w2k8 r2 x64 on a vm
2. install gnustep from installers
gnustep-msys-system-0.30.0-setup.exe
gnustep-core-0.35.0-setup.exe
gnustep-devel-1.4.0-setup.exe
3. get sourcehttp://svn.gna.org/svn/gnustep/modules/core
4. cd core/base; ./configure


before brewing your own, would you mind testing the supplied gnustep 
stuff to run the application you need and see if it works? that would 
check if the supplied stuff works on your setup.


I run on Win 7, both x68 and amd64 and it works fine and w2k8 r2 is 
roughly equivalent.


I hope Adam soon gives us his base configure flags, if any.

Riccardo

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: 32bit GS on 64bit Win rebuild base from src

[Fred Kiefer]

Riccardo, I think you are missing the point here. For some reason, which I 
don't understand, Giah wants to use the 32 bit version of base on a 64 bit 
system. This will work out of the box, but when doing the autoconfig the system 
gets confused. It detects the 64 bit environment and will try to use that 
instead. What is needed is some sort of cross compilation and I am not sure we 
are up to that.

Fred

On the road

Am 06.08.2016 um 22:44 schrieb Riccardo Mottola :

> Hi,
> 
> 
>> On 06/08/2016 19:25, Giah de Barag wrote:
>> 1. install w2k8 r2 x64 on a vm
>> 2. install gnustep from installers
>>gnustep-msys-system-0.30.0-setup.exe
>>gnustep-core-0.35.0-setup.exe
>>gnustep-devel-1.4.0-setup.exe
>> 3. get sourcehttp://svn.gna.org/svn/gnustep/modules/core
>> 4. cd core/base; ./configure
> 
> before brewing your own, would you mind testing the supplied gnustep stuff to 
> run the application you need and see if it works? that would check if the 
> supplied stuff works on your setup.
> 
> I run on Win 7, both x68 and amd64 and it works fine and w2k8 r2 is roughly 
> equivalent.
> 
> I hope Adam soon gives us his base configure flags, if any.
> 
> Riccardo
> 
> ___
> Gnustep-dev mailing list
> Gnustep-dev@gnu.org
> https://lists.gnu.org/mailman/listinfo/gnustep-dev


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: 32bit GS on 64bit Win rebuild base from src

[Giah de Barag]

Thank you for the clarification Fred. What if I add steps 1 and 5 to my recipe:

1. build win32 machine
2. install GNUstep installers
3. download core/base from svn
4. cd core/base; ./configure; make; make install
5. rsync c:/GNUstep from win32 machine to win64 machine

Here is what I am trying to achieve: On win64 debugging my app, I discover a 
bug in gnustep base and make the patch to the gnustep base code which is on a 
file share that both machines see, so I go on the win32 machine and just do 
make install; rsync c:/gnustep back to the win64 machine, come back over to the 
win64 machine and continue debugging my app from where I left off with the new 
patch in place. Does this work?

Thank you.

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: 32bit GS on 64bit Win rebuild base from src

[Fred Kiefer]

This may seem frustrating to you but I see it as a step forward, as now you are 
able to reproduce the issue in a controlled and valid environment. The main 
question now is, which version of libffi is getting used here? Maybe this isn't 
suited for the Intel Xeon processor? And could you please provide the config 
log section right before the crash?

Thank you,
Fred



On the road
Am 07.08.2016 um 09:10 schrieb Giah de Barag :

> It did not work. Same exact results with 32bit Win as previously reported 
> about 64bit Win.
> 
> Please review and advise:
> 
> 1. set up 32bit Windows Server Standard 2008 with Service Pack 2 and all 
> updates
> 
> 2. install GNUstep Windows installers
> gnustep-msys-system-0.30.0-setup.exe
> gnustep-core-0.35.0-setup.exe
> gnustep-devel-1.4.0-setup.exe
> gnustep-cairo-0.35.0-setup.exe
> gorm-1.2.23-35-setup.exe
> ProjectCenter-0.6.2-35-setup.exe
> 
> 3. get http://svn.gna.org/svn/gnustep/modules/core from svn
> 
> 4. cd core/base; ./configure crashes in FFI test.
> 
> 5. Gorm and ProjectCenter both crash.
> 
> 
> 
> ___
> Gnustep-dev mailing list
> Gnustep-dev@gnu.org
> https://lists.gnu.org/mailman/listinfo/gnustep-dev
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: 32bit GS on 64bit Win rebuild base from src

[Giah de Barag]

Thank you Fred.

> Which version of libffi is getting used here?

I cannot tell at the moment because I have uninstalled 0.35 and am moving 
forward using the 0.34 where these problems do not occur.

> Maybe this isn't suited for the Intel Xeon processor?

GNUstep works here on Windows on same Xeon processors since eight years, and 
these problems do not occur with 0.34 installer. Do you mean in general or 
specific to the 0.35 installer?

> And could you please provide the config log section right before the crash?

I lost the data because I deleted 0.35 and switched to 0.34. Is there another 
way to find out the answers to your questions or do you need me to replicate 
these problems again with 0.35?

Note: 0.34 successfully configures, builds (make), and tests (make check) the 
head of core/base. There were two fails that looked like real fails (popped up 
panels on the screen, saying “[something].exe has stopped working,” suspending 
the process until dismissed), one in NSDictionary, one in NSFileHandle.

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: 32bit GS on 64bit Win rebuild base from src

[Riccardo Mottola]

Hi,

Fred Kiefer wrote:

Riccardo, I think you are missing the point here. For some reason, which I 
don't understand, Giah wants to use the 32 bit version of base on a 64 bit 
system. This will work out of the box, but when doing the autoconfig the system 
gets confused. It detects the 64 bit environment and will try to use that 
instead. What is needed is some sort of cross compilation and I am not sure we 
are up to that.


I am unsure. If you use MINGW-32 (which is the one we supply) it is 
irrelevant if you are using windows 32bit or 64bit. At least, I did both 
and it works fine.
I do however build on an older, customized system so my configure 
options do not apply (I still use ffcall)


Riccardo

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: 32bit GS on 64bit Win rebuild base from src

[Giah de Barag]

A simple use-case that causes GDB to crash.

On Windows Server Standard 2008 R2, I install GNUstep from the 0.34 installer 
packages, configure, build, and install the latest make and base (using 
scripts/windows_build) with no special flags other than --disable-libdispatch. 
I build an objc tool with -O0 and -g. This tool has run on earlier GNUstep 
versions for a decade.

I gdb my program and do “break main” and “run,” expecting it to break in main().

GDB crashes.

I take the breakpoint out, and gdb does not crash and the program runs.

I build a simple C program and compile it. No such problem.

(I started with 0.35 but, as previously reported, it did not pass its own tests 
and was not able to configure base due to failed FFI test.)___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: 32bit GS on 64bit Win rebuild base from src

[Giah de Barag]

I am trying to figure out why GDB is crashing (see previous email).



1. Here is a dump of my mingw32 environment. Are the variables right? Is the 
path right? Is anything missing? Is anything conflicted? Is anything 
unnecessary?

1. install clean Windows Server 2008 R2
2. install emacs-24.5-bin-i686-mingw32.zip (c:/progra~2/emacs)
3. install gnustep-msys-system-0.30.0-setup.exe (c:/msys)
4. install gnustep-devel-1.4.0-setup.exe (c:/msys)
5. install tortoise svn client
6. set env to:
GNUSTEP . c:/msys/GNUstep
GNUSTEP_MAKEFILES c:/msys/GNUstep/System/Library/Makefiles
MANPATH . 
c:/msys/GNUstep/System/Library/Documentation/man;c:/msys/share/man
MSYS  c:/msys
MSYSTEM . mingw32
PATH
.
c:/msys/bin
c:/msys/msys/1.0/bin
c:/msys/mingw32/bin
c:/msys/gnustep/system/tools
c:/progra~1/tortoi~1/bin
c:/progra~2/emacs/bin
%systemroot%
%systemroot%/system32
%systemroot%/system32/wbem
%systemroot%/system32/windowspowershell/v1.0



2. In building gnustep-base32 on mingw32, the make/configure script could not 
determine my processor or hardware (vmware / x5675).

uname -s = mingw32_NT-6.1 (kernel name)
uname -r = 1.0.17(0.48/3/2) (kernel release)
uname -v = 2011-04-24 23:39 (kernel version)
uname -m = i686 (machine)
uname -p = unknown (processor)
uname -i = unknown (hardware)
uname -o = Msys (operating system)

Therefore, I added the following temporary hack to the windows-build script.

# Architecture Goop
ARCH=i686-pc-mingw32 # config.guess failed
ARCH_GOOP="--build ${ARCH} --target ${ARCH} --host ${ARCH}"
CONFIGURE="./configure ${ARCH_GOOP}"

Was i686-pc-mingw32 the right triple to use?



Thank you.___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: 32bit GS on 64bit Win rebuild base from src

[Ivan Vučica]

+cc fedor@

Adam, any thoughts?

And, could you update
http://wiki.gnustep.org/index.php/Installation_on_Windows based on what
you'd do to produce new installer, given a blank machine (of whatever OS)?

On Thu, Aug 11, 2016 at 5:40 AM Giah de Barag  wrote:

> I am trying to figure out why GDB is crashing (see previous email).
>
>
>
> 1. Here is a dump of my mingw32 environment. Are the variables right? Is
> the path right? Is anything missing? Is anything conflicted? Is anything
> unnecessary?
>
> 1. install clean Windows Server 2008 R2
> 2. install emacs-24.5-bin-i686-mingw32.zip (c:/progra~2/emacs)
> 3. install gnustep-msys-system-0.30.0-setup.exe (c:/msys)
> 4. install gnustep-devel-1.4.0-setup.exe (c:/msys)
> 5. install tortoise svn client
> 6. set env to:
> GNUSTEP . c:/msys/GNUstep
> GNUSTEP_MAKEFILES c:/msys/GNUstep/System/Library/Makefiles
> MANPATH .
> c:/msys/GNUstep/System/Library/Documentation/man;c:/msys/share/man
> MSYS  c:/msys
> MSYSTEM . mingw32
> PATH
> .
> c:/msys/bin
> c:/msys/msys/1.0/bin
> c:/msys/mingw32/bin
> c:/msys/gnustep/system/tools
> c:/progra~1/tortoi~1/bin
> c:/progra~2/emacs/bin
> %systemroot%
> %systemroot%/system32
> %systemroot%/system32/wbem
> %systemroot%/system32/windowspowershell/v1.0
>
>
>
> 2. In building gnustep-base32 on mingw32, the make/configure script could
> not determine my processor or hardware (vmware / x5675).
>
> uname -s = mingw32_NT-6.1 (kernel name)
> uname -r = 1.0.17(0.48/3/2) (kernel release)
> uname -v = 2011-04-24 23:39 (kernel version)
> uname -m = i686 (machine)
> uname -p = unknown (processor)
> uname -i = unknown (hardware)
> uname -o = Msys (operating system)
>
> Therefore, I added the following temporary hack to the windows-build
>  script.
>
> # Architecture Goop
> ARCH=i686-pc-mingw32 # config.guess failed
> ARCH_GOOP="--build ${ARCH} --target ${ARCH} --host ${ARCH}"
> CONFIGURE="./configure ${ARCH_GOOP}"
>
> Was i686-pc-mingw32 the right triple to use?
>
>
>
> Thank you.
> ___
> Gnustep-dev mailing list
> Gnustep-dev@gnu.org
> https://lists.gnu.org/mailman/listinfo/gnustep-dev
>
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: 32bit GS on 64bit Win rebuild base from src

[Adam Fedor]

> On Aug 12, 2016, at 7:59 AM, Ivan Vučica  wrote:
> 
> 
> 1. Here is a dump of my mingw32 environment. Are the variables right? Is the 
> path right? Is anything missing? Is anything conflicted? Is anything 
> unnecessary?
> 

I think I already have svn in the gnustep-devel package, but otherwise it looks 
fine.

> 
> 2. In building gnustep-base32 on mingw32, the make/configure script could not 
> determine my processor or hardware (vmware / x5675).
> 
> 
> # Architecture Goop
> ARCH=i686-pc-mingw32 # config.guess failed
> ARCH_GOOP="--build ${ARCH} --target ${ARCH} --host ${ARCH}"
> CONFIGURE="./configure ${ARCH_GOOP}"
> 
> Was i686-pc-mingw32 the right triple to use?
> 

I don’t know if that’s right and I’m not sure it matters much, but it might.

The issue is Windows is very very finicky.  You can get the problems you are 
seeing if something like the libtiff library is compiled with the wrong flag 
(I’ve had similar issues where that was the problem). It’s very difficult to 
figure out what might be wrong, except by going back to a system that is known 
to work and slowly adding things until it breaks.

FYI, I never use Windows.  I just make the installer because no one else does.

Adam

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: 32bit GS on 64bit Win rebuild base from src

[Giah de Barag]

If needed, I could volunteer to release Windows installers once a year.

I need assistance getting a clean build. I am frustrated at how hard it has 
been.

There should be a set of foolproof instructions for newcomers.

I would be happy to prepare them, but I need assistance.

Would someone be willing to collaborate?



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: 32bit GS on 64bit Win rebuild base from src

[Giah de Barag]

[AF] You can get the problems you are seeing if something like the libtiff 
library is compiled with the wrong flag

Why build installers without confidence that they are not going to produce such 
problems?



[AF] I never use Windows.  I just make the installer because no one else does.

That is nice of you and disappointing that Windows users do not help with that.



[AF] going back to a system that is known to work

I need to know a system that is known to work.

Windows users: Please recommend a working starting point and recipe for 
building?

Are there any Windows users? How many do you think there are?

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: 32bit GS on 64bit Win rebuild base from src

[Adam Fedor]

> 
> I need to know a system that is known to work.
> 
> Windows users: Please recommend a working starting point and recipe for 
> building?
> 
> Are there any Windows users? How many do you think there are?
> 

FYI, All the information I use to build the Windows installer is here:

http://svn.gna.org/svn/gnustep/tools/installers/trunk/nsis 


including packages to download and all the flags I use to compile (in 
native-compile.sh). Although if I was starting over trying to make an installer 
I would probably do it differently:

- I’d probably use 64-bit mingw.  There are other people who’ve used this and 
created instructions for it (as Richard mentioned in a previous email)
- Other people have mentioned that the nsis installer is old and a more modern 
one should be used (I forget what the new installer is or the arguments for 
using it).___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: 32bit GS on 64bit Win rebuild base from src

[Riccardo Mottola]

Hi,



On 12/08/2016 17:01, Adam Fedor wrote:


I don’t know if that’s right and I’m not sure it matters much, but it 
might.


The issue is Windows is very very finicky.  You can get the problems 
you are seeing if something like the libtiff library is compiled with 
the wrong flag (I’ve had similar issues where that was the problem). 
It’s very difficult to figure out what might be wrong, except by going 
back to a system that is known to work and slowly adding things until 
it breaks.


But if Giah uses the msys you supply, it should have the same libffi you 
used, so I do not understand.


Do you use any special flags to make or base?



FYI, I never use Windows.  I just make the installer because no one 
else does.


We appreciate your effort! You do the base, but on your work, I do quite 
some work to get programs work on windows, so don't feel alone!


Riccardo

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: 32bit GS on 64bit Win rebuild base from src

[Riccardo Mottola]

Hi,



On 13/08/2016 00:29, Adam Fedor wrote:

http://svn.gna.org/svn/gnustep/tools/installers/trunk/nsis

including packages to download and all the flags I use to compile (in 
native-compile.sh). Although if I was starting over trying to make an 
installer I would probably do it differently:


It seems quite plain to me? I wonder if Giah could run the same script 
or use the same flags.




- I’d probably use 64-bit mingw.  There are other people who’ve used 
this and created instructions for it (as Richard mentioned in a 
previous email)
- Other people have mentioned that the nsis installer is old and a 
more modern one should be used (I forget what the new installer is or 
the arguments for using it).


I'd stick for mingw for now. I follow development and mingw-64 vs mingw 
is not without friction. MinGW is quite proven, I wonder if it will 
continue to be easy to have both, I hope so.


About the installer, I'm neutral, what we have works and appears to 
continue to work !


Riccardo

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: 32bit GS on 64bit Win rebuild base from src

[Giah de Barag]

I am still confused and trying to understand the
variables / scripts / dependencies / repository
locations:

System: MSYS vs MSYS2

  Riccardo mentioned that MSYS is known and works. Adam
  & Seong-Gu like MSYS2. It is more like (Arch) Linux,
  has a standard package manager, pacman, and has lots
  more packages than MSYS. I stopped MSYS and started
  with MSYS2.

Architecture: 32 vs 64

  Richard and Seong-Gu indicate 64 is working (runtime
  errors in gui). Does base pass all its tests? Do
  objc2, blocks, and GCD work? Did anybody build 32 and
  64 side-by-side, each in its respective path on
  MSYS2? Was the choice of compilers and libs and flags
  different between 64 and 32?

Compiler: gcc vs clang

  Still a tad bit confused here. I understand latest
  gcc supports blocks. Should I do (a) or (b):
(a) (i) clang for libdispatch and libobjc2
(ii) gcc for everything else?
(b) clang for everything?

libdispatch from Nick Hutchinson's repo
which branch?
  https://github.com/nickhutchinson/libdispatch/tags/v0.1.3.1
  https://github.com/nickhutchinson/libdispatch/trunk

libobjc2 from David Chisnall's repo
which branch?
  https://github.com/gnustep/libobjc2/tags/v1.8
  https://github.com/gnustep/libobjc2/tags/v1.8.1
  https://github.com/gnustep/libobjc2/trunk


Here is what I am thinking:

System: MSYS2
Architecture: 64
Compiler:
  clang: libdispatch + libobjc2
  gcc (or clang, not sure?): everything else
libdispatch:
  https://github.com/nickhutchinson/libdispatch/tags/v0.1.3.1
  (or trunk, not sure?)
libobjc2:
  https://github.com/gnustep/libobjc2/tags/v1.8.1
  (or trunk, not sure?)


Richard + Seong-Gu: How does that compare to what you are doing?


Kind regards.

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: 32bit GS on 64bit Win rebuild base from src

[Giah de Barag]

On 0.35 installer:
make
gdb prog.exe
break main   # main(), not line number
run
gdb crashes
If both #if sections are disabled, gdb can break in main().
Can anyone verify?
Is this indicative of a serious problem?
If it is working for you, would you mind posting your makefiles? I am using a 
tool makefile with nothing added other than the source file and the tool name. 
I am using makefiles from 8 years ago. Where are the template makefiles for 
making new projects?
Thanks and regards.

—

#import 

#define GDB_BREAK_MAIN_CRASH_A 1
#define GDB_BREAK_MAIN_CRASH_B 1

#if GDB_BREAK_MAIN_CRASH_A
@interface SmartTool : NSObject {}
+ (void) hello;
@end

@implementation SmartTool
+ (void) hello { printf("NSObject Hello\n"); }
@end
#endif

@interface DumbTool {}
+ (void) hello;
@end

@implementation DumbTool
+ (void) hello { printf("Hello\n"); }
@end

int main( int argc, const char *argv[] )
{
#if GDB_BREAK_MAIN_CRASH_B
[NSString alloc];
#endif
[DumbTool hello];
return 0;
}

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: 32bit GS on 64bit Win rebuild base from src

[Giah de Barag]

Follow-up on 0.35 installer GDB crash:

Summary:
gdb-7.3.1/gdb/breakpoint.c:11006: internal-error: addr_string_to_sals: 
Assertion `sals.nelts == 1' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session?

Detail:
% gdb obj/prog.exe  # code for prog.m posted in previous email
GNU gdb (GDB) 7.3.1
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "mingw32".
For bug reporting instructions, please see:
...
Load new symbol table from "obj\prog.exe"? (y or n) y
Reading symbols from obj\prog.exe...done.
(gdb) b main
Reading in symbols for prog.m...done.
Breakpoint 1 at 0x401bb7: file prog.m, line 27.
(gdb) r
Starting program: obj\prog.exe
[New Thread 3484.0x13d0]
Reading symbols from C:\Windows\system32\ntdll.dll...(no debugging symbols 
found)...done.
Loaded symbols for C:\Windows\system32\ntdll.dll
Reading symbols from C:\Windows\syswow64\kernel32.dll...(no debugging symbols 
found)...done.
Loaded symbols for C:\Windows\syswow64\kernel32.dll
Reading symbols from C:\Windows\syswow64\KernelBase.dll...(no debugging symbols 
found)...done.
Loaded symbols for C:\Windows\syswow64\KernelBase.dll
Reading symbols from C:\Windows\syswow64\msvcrt.dll...(no debugging symbols 
found)...done.
Loaded symbols for C:\Windows\syswow64\msvcrt.dll
Reading symbols from c:\msys\GNUstep\System\Tools\gnustep-base-1_24.dll...done.
Loaded symbols for c:\msys\GNUstep\System\Tools\gnustep-base-1_24.dll
Reading symbols from c:\msys\bin\libgcc_s_dw2-1.dll...(no debugging symbols 
found)...done.
Loaded symbols for c:\msys\bin\libgcc_s_dw2-1.dll
Reading symbols from c:\msys\GNUstep\System\Tools\libffi-6.dll...done.
Loaded symbols for c:\msys\GNUstep\System\Tools\libffi-6.dll
Reading symbols from c:\msys\GNUstep\System\Tools\objc-4.dll...done.
Loaded symbols for c:\msys\GNUstep\System\Tools\objc-4.dll
Reading symbols from c:\msys\bin\pthreadGC2.dll...(no debugging symbols 
found)...done.
Loaded symbols for c:\msys\bin\pthreadGC2.dll
Reading symbols from C:\Windows\syswow64\advapi32.dll...(no debugging symbols 
found)...done.
Loaded symbols for C:\Windows\syswow64\advapi32.dll
Reading symbols from C:\Windows\SysWOW64\sechost.dll...(no debugging symbols 
found)...done.
Loaded symbols for C:\Windows\SysWOW64\sechost.dll
Reading symbols from C:\Windows\syswow64\rpcrt4.dll...(no debugging symbols 
found)...done.
Loaded symbols for C:\Windows\syswow64\rpcrt4.dll
Reading symbols from C:\Windows\syswow64\sspicli.dll...(no debugging symbols 
found)...done.
Loaded symbols for C:\Windows\syswow64\sspicli.dll
Reading symbols from C:\Windows\syswow64\cryptbase.dll...(no debugging symbols 
found)...done.
Loaded symbols for C:\Windows\syswow64\cryptbase.dll
Reading symbols from c:\msys\bin\libgnutls-26.dll...done.
Loaded symbols for c:\msys\bin\libgnutls-26.dll
Reading symbols from c:\msys\bin\libgcrypt-11.dll...done.
Loaded symbols for c:\msys\bin\libgcrypt-11.dll
Reading symbols from c:\msys\bin\libgpg-error-0.dll...done.
Loaded symbols for c:\msys\bin\libgpg-error-0.dll
Reading symbols from C:\Windows\syswow64\user32.dll...(no debugging symbols 
found)...done.
Loaded symbols for C:\Windows\syswow64\user32.dll
Reading symbols from C:\Windows\syswow64\gdi32.dll...(no debugging symbols 
found)...done.
Loaded symbols for C:\Windows\syswow64\gdi32.dll
Reading symbols from C:\Windows\syswow64\lpk.dll...(no debugging symbols 
found)...done.
Loaded symbols for C:\Windows\syswow64\lpk.dll
Reading symbols from C:\Windows\syswow64\usp10.dll...(no debugging symbols 
found)...done.
Loaded symbols for C:\Windows\syswow64\usp10.dll
Reading symbols from c:\msys\bin\libintl-8.dll...(no debugging symbols 
found)...done.
Loaded symbols for c:\msys\bin\libintl-8.dll
Reading symbols from c:\msys\bin\libiconv-2.dll...(no debugging symbols 
found)...done.
Loaded symbols for c:\msys\bin\libiconv-2.dll
Reading symbols from c:\msys\bin\libp11-kit-0.dll...done.
Loaded symbols for c:\msys\bin\libp11-kit-0.dll
Reading symbols from C:\Windows\syswow64\shell32.dll...(no debugging symbols 
found)...done.
Loaded symbols for C:\Windows\syswow64\shell32.dll
Reading symbols from C:\Windows\syswow64\shlwapi.dll...(no debugging symbols 
found)...done.
Loaded symbols for C:\Windows\syswow64\shlwapi.dll
Reading symbols from C:\Windows\syswow64\ws2_32.dll...(no debugging symbols 
found)...done.
Loaded symbols for C:\Windows\syswow64\ws2_32.dll
Reading symbols from C:\Windows\syswow64\nsi.dll...(no debugging symbols 
found)...done.
Loaded symbols for C:\Windows\syswow64\nsi.dll
Reading symbols from c:\msys\bin\libz-1.dll...(no debugging symbols 
found)...done.
Loaded symbols for c:\msys\bin\libz-1.dll
Reading symbols f

Re: 32bit GS on 64bit Win rebuild base from src

[Giah de Barag]

I’m trying to update 0.35 installer’s gdb

mingw-get.exe: *** WARNING *** c:\msys\var/lib/mingw-get/data/profile.xml: user 
configuration file missing
mingw-get.exe: *** INFO *** c:\msys\var/lib/mingw-get/data/defaults.xml: trying 
system default configuration

Do you still have the configuration files for mingw-get or can I regenerate 
them somehow?

I tried to regenerate them, but it doesn’t seem to work.


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: 32bit GS on 64bit Win rebuild base from src

[Adam Fedor]

> On Aug 14, 2016, at 2:33 AM, Riccardo Mottola  
> wrote:
> 
> 
> But if Giah uses the msys you supply, it should have the same libffi you 
> used, so I do not understand.
> 
> Do you use any special flags to make or base?

No I don’t, except perhaps -fno-omit-frame-pointer
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: 32bit GS on 64bit Win rebuild base from src

[Adam Fedor]

> On Aug 14, 2016, at 5:41 PM, Giah de Barag  wrote:
> 
> I’m trying to update 0.35 installer’s gdb
> 
> mingw-get.exe: *** WARNING *** c:\msys\var/lib/mingw-get/data/profile.xml: 
> user configuration file missing
> mingw-get.exe: *** INFO *** c:\msys\var/lib/mingw-get/data/defaults.xml: 
> trying system default configuration
> 
> Do you still have the configuration files for mingw-get or can I regenerate 
> them somehow?

Here’s the default file.  I don’t have a profile file.  Perhaps that’s just 
optional



defaults.xml
Description: XML document
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: 32bit GS on 64bit Win rebuild base from src

[Giah de Barag]

Regarding previously-reported GDB crash:

Problem is correlated with four-years-old installers [1].

Problem went away after installing latest mingw-get [2] and upgrading all 
packages.

Before:
gcc.exe (GCC) 4.6.1 (2011)
GNU gdb (GDB) 7.3.1 (2011)

After:
gcc.exe (GCC) 4.9.3 (2015)
GNU gdb (GDB) 7.6.1 (2013)

Question: What version of gcc built gnustep-core-0.35.0-setup.exe?



Ref:

1. “GNUstep MSYS System” and “GNUstep Devel” from 
http://www.gnustep.org/windows/installer.html 


2. “mingw-get-setup.exe” from http://www.mingw.org/wiki/Getting_Started 




P.S. Is this posting better for gnustep-dev or discuss-gnustep or both?




___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: 32bit GS on 64bit Win rebuild base from src

[Adam Fedor]

> On Aug 15, 2016, at 1:26 PM, Giah de Barag  wrote:
> 
> 
> Question: What version of gcc built gnustep-core-0.35.0-setup.exe?
> 

gcc 4.6.1___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: 32bit GS on 64bit Win rebuild base from src

[Giah de Barag]

Can anyone on MSYS2 replicate this recipe for crashing GDB?


1. Install MSYS2. Update pacman.

2. Install packages and build GS (modules/scripts).

3. Build the program below and run gdb on it.


gdb commands:

b main
r
tbreak 10 # in front of the return
c
print [ud objectForKey:@"foo”] # GDB crashes


program:

#import 

int main( int argc, const char *argv[] )
{
id pool = [NSAutoreleasePool new];
id ud   = [NSUserDefaults standardUserDefaults];
id foo  = [ud objectForKey:@"foo"];
printf("foo = %s\n", foo ? [foo cString] : "missing"); fflush(stdout);
[pool release];
#line 10
return 0;
}



Note:

Using old MSYS GNUstep installed from Installers, it crashes right on “b main” 
(as previously reported) and if update all packages with mingw-get and rebuild 
GNUstep, it crashes as above.
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: 32bit GS on 64bit Win rebuild base from src

[Fred Kiefer]

In line 10 the variable ud no longer has a defined value. The autorelease pool 
that manages this value gets released in line 9 and no mor references to that 
variable should happen. It isn't great that gdb just crashes, but on Windows 
they seem to have issues with illegal memory access.

Fred

On the road

Am 21.08.2016 um 14:12 schrieb Giah de Barag :

> Can anyone on MSYS2 replicate this recipe for crashing GDB?
> 
> 
> 1. Install MSYS2. Update pacman.
> 
> 2. Install packages and build GS (modules/scripts).
> 
> 3. Build the program below and run gdb on it.
> 
> 
> gdb commands:
> 
> b main
> r
> tbreak 10 # in front of the return
> c
> print [ud objectForKey:@"foo”] # GDB crashes
> 
> 
> program:
> 
> #import 
> 
> int main( int argc, const char *argv[] )
> {
>id pool = [NSAutoreleasePool new];
>id ud   = [NSUserDefaults standardUserDefaults];
>id foo  = [ud objectForKey:@"foo"];
>printf("foo = %s\n", foo ? [foo cString] : "missing"); fflush(stdout);
>[pool release];
> #line 10
>return 0;
> }
> 
> 
> 
> Note:
> 
> Using old MSYS GNUstep installed from Installers, it crashes right on “b 
> main” (as previously reported) and if update all packages with mingw-get and 
> rebuild GNUstep, it crashes as above.
> ___
> Gnustep-dev mailing list
> Gnustep-dev@gnu.org
> https://lists.gnu.org/mailman/listinfo/gnustep-dev


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: 32bit GS on 64bit Win rebuild base from src

[Giah de Barag]

Sorry, right, I should have said lines 7, 8, or 9 which crash GDB -- 
inexplicably. Other dynamic objc in GDB does not crash GDB. Could it be 
something with NSUserDefaults itself?

On Aug 21, 2016, at 9:04 AM, Fred Kiefer  wrote:

In line 10 the variable ud no longer has a defined value. The autorelease pool 
that manages this value gets released in line 9 and no mor references to that 
variable should happen. It isn't great that gdb just crashes, but on Windows 
they seem to have issues with illegal memory access.

Fred

On the road

Am 21.08.2016 um 14:12 schrieb Giah de Barag :

> Can anyone on MSYS2 replicate this recipe for crashing GDB?
> 
> 
> 1. Install MSYS2. Update pacman.
> 
> 2. Install packages and build GS (modules/scripts).
> 
> 3. Build the program below and run gdb on it.
> 
> 
> gdb commands:
> 
> b main
> r
> tbreak 10 # in front of the return
> c
> print [ud objectForKey:@"foo”] # GDB crashes
> 
> 
> program:
> 
> #import 
> 
> int main( int argc, const char *argv[] )
> {
>   id pool = [NSAutoreleasePool new];
>   id ud   = [NSUserDefaults standardUserDefaults];
>   id foo  = [ud objectForKey:@"foo"];
>   printf("foo = %s\n", foo ? [foo cString] : "missing"); fflush(stdout);
>   [pool release];
> #line 10
>   return 0;
> }
> 
> 
> 
> Note:
> 
> Using old MSYS GNUstep installed from Installers, it crashes right on “b 
> main” (as previously reported) and if update all packages with mingw-get and 
> rebuild GNUstep, it crashes as above.
> ___
> Gnustep-dev mailing list
> Gnustep-dev@gnu.org
> https://lists.gnu.org/mailman/listinfo/gnustep-dev



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: 32bit GS on 64bit Win rebuild base from src

[Giah de Barag]

Here is a bit more info. It is associated with using the @"" syntax to pass an 
NSString convenience variable. (0.23 did not have this problem.)

(gdb) b main
(gdb) r
(gdb) b 9
(gdb) c
(gdb) p [ud objectForKey:str]
$1 = (struct objc_object *) 0x0
(gdb) po [ud presistentDomainNames]
Target does not respond to this message selector.
(gdb) po [ud persistentDomainNames]
(gorm, ProjectCenter, MyTool, SystemPreferences, NSGlobalDomain)
(gdb) set $a = [NSString stringWithString:str]
Reading in symbols for NSString.m...done.
(gdb) po $a
foo
(gdb) set $a = [NSString stringWithString:@"foo”]
Segmentation fault
Debugger exited abnormally with code 5

#import 

int main( int argc, const char *argv[] )
{
id pool = [NSAutoreleasePool new];
id ud   = [NSUserDefaults standardUserDefaults];
id foo  = [ud objectForKey:@"foo"];
id str  = @"foo";
printf("foo = %s\n", foo ? [foo cString] : "missing"); fflush(stdout);
#line 10
[pool release];
return 0;
}


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: 32bit GS on 64bit Win rebuild base from src

[Giah de Barag]

Further info on this problem with GDB. Here is a C function "prn" that takes a 
char *. If I pass it a C string "foo" from the command-line in GDB, it receives 
a zero. So neither passing NSString convenience variables nor passing plain C 
string convenience variables works on latest GNUstep / MINGW32 / MSYS2.

#import 

void prn(char *a)
{
// when call prn("foo") from
// GDB command line breaking
// here to examine, variable
// a = 0x0 !!!
printf("char is \'%s\'\n", a); fflush(stdout);
}

int main( int argc, const char *argv[] )
{
idpool = [NSAutoreleasePool new];
idfoo  = @"foo";
char *s= [foo cString];
prn(s);
// now invoke prn from gdb
// b prn
// p prn("foo")
// p a
// $1 = 0x0
// "foo" --> 0x0 ???
[pool release];
return 0;
}




___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: 32bit GS on 64bit Win rebuild base from src

[Ivan Vučica]

If so, that sounds more like a problem with gdb and/or mingw?

Does this installation of gdb work with plain C programs?

On Sun, Aug 21, 2016 at 4:40 PM, Giah de Barag  wrote:

> Further info on this problem with GDB. Here is a C function "prn" that
> takes a char *. If I pass it a C string "foo" from the command-line in GDB,
> it receives a zero. So neither passing NSString convenience variables nor
> passing plain C string convenience variables works on latest GNUstep /
> MINGW32 / MSYS2.
>
> #import 
>
> void prn(char *a)
> {
> // when call prn("foo") from
> // GDB command line breaking
> // here to examine, variable
> // a = 0x0 !!!
> printf("char is \'%s\'\n", a); fflush(stdout);
> }
>
> int main( int argc, const char *argv[] )
> {
> idpool = [NSAutoreleasePool new];
> idfoo  = @"foo";
> char *s= [foo cString];
> prn(s);
> // now invoke prn from gdb
> // b prn
> // p prn("foo")
> // p a
> // $1 = 0x0
> // "foo" --> 0x0 ???
> [pool release];
> return 0;
> }
>
>
>
>
> ___
> Gnustep-dev mailing list
> Gnustep-dev@gnu.org
> https://lists.gnu.org/mailman/listinfo/gnustep-dev
>
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: 32bit GS on 64bit Win rebuild base from src

[Giah de Barag]

1. Where is the glue code that facilitates creating GNUstep NSString 
convenience variables on the GDB command line?

2. This problem does not affect programs not using GNUstep. Creating and 
passing C string convenience variables into C programs and plan vanilla ObjC 
programs of course works. The problem occurs when linking against GNUstep. In 
that case, creating end passing strings does not work, neither C strings nor 
NSStrings.

3. Here is the simplest recipe:

a. MSYS2 / MINGW32 / GNUstep (core/modules/scripts)

b. Create simplest imaginable GNUstep tool, break in main, run, and do:

(gdb) set $a = "foo"
(gdb) p $a
$3 = 
(gdb) set $b = @"bar"
Segmentation fault
Debugger exited abnormally with code 5



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: 32bit GS on 64bit Win rebuild base from src

[Giah de Barag]

Which class in the string cluster is to be instantiated by typing set $a = 
@"foo" in gdb?


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: 32bit GS on 64bit Win rebuild base from src

[Giah de Barag]

I posted a GDB bug report 
(https://sourceware.org/bugzilla/show_bug.cgi?id=20501).

The problem is not limited to Windows.

GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-80.el7
(gdb) p "foo"
$1 = # this is ridiculous
(gdb) p @"foo"
Segmentation fault (core dumped)

This is a serious issue. I wish some of you would also contact the GDB 
developers and help get this issue looked at.

GNU gdb 6.8 i686-pc-mingw32  does not have the bug
GNU gdb 7.3.1 mingw32 .. does not have the bug
GNU gdb 7.6.1-80.el7 x86_64-redhat-linux-gnu ... has the bug
GNU gdb 7.11.1 i686-w64-mingw32  has the bug
GNU gdb 7.11.1 x86_64-w64-mingw32 .. has the bug

Surprising.

In older versions of GDB where this worked, when you type p @"foo" in gdb, you 
see:
(gdb) p @"foo"
$2 = (class NSString *) 0x1e72198
(gdb) po $2
foo
(gdb) po [$2 class]
GSCBufferString




___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev