[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Testing for drawing fixes r30523
From: |
Doug Simons |
Subject: |
Re: Testing for drawing fixes r30523 |
Date: |
Tue, 8 Jun 2010 10:00:01 -0600 |
Quentin,
I don't know if this will help you or not, but we install everything in core in
the SYSTEM domain, which requires these steps:
cd base
./configure --with-installation-domain=SYSTEM
make GNUSTEP_INSTALLATION_DOMAIN=SYSTEM install
cd ../gui
make GNUSTEP_INSTALLATION_DOMAIN=SYSTEM install
cd ../back
make GNUSTEP_INSTALLATION_DOMAIN=SYSTEM install
The ./configure step is only needed in base. If you have previously installed
things, you may need to do a 'make GNUSTEP_INSTALLATION_DOMAIN=SYSTEM
distclean' in each directory first.
Good luck!
Doug
On Jun 8, 2010, at 3:54 AM, Quentin Mathé wrote:
>
> Le 7 juin 2010 à 18:39, Doug Simons a écrit :
>
>> Thanks Quentin, we appreciate it!
>>
>> For the sake of tracking this issue, I've opened bug #30069 in the bug
>> system.
>
> ok. For now, I'm still trying to get GNUstep core & Gorm from svn trunk
> properly installed on top of a GNUstep install with the Windows installers
> from this page: http://www.gnustep.org/experience/Windows.html
> I initially tried an install from scratch with the README.MinGW doc, but I
> had various issues and had to give up on the fact GCC was unable to find the
> libobjc headers when everything was set up.
>
> On my new install, when compiling the core libs, GNUstep Base and Gui headers
> appear to be installed incorrectly. e.g. GNUstep/Local/Headers/Foundation
> once installed contains no headers and GNUstep/Local/Library/Headers/AppKit
> contains the headers that should be the GNUstepGUI directory (quite weird).
> As a result of this, GSXibLoading.h is currently not found when I try to
> compile Gorm.
>
> SystemPreferences from svn trunk once compiled and installed is also unable
> to find libPreferencePanes-1.dll each time a .prefPane is loaded (I get a
> warning dialog and an empty SystemPreferences window once the app launch is
> done).
>
> If you have suggestions to solve these problems, I'm interested :-)
>
> Cheers,
> Quentin.
- Re: Testing for drawing fixes r30523, (continued)
- Re: Testing for drawing fixes r30523, Quentin Mathé, 2010/06/03
- Re: Testing for drawing fixes r30523, Doug Simons, 2010/06/03
- Re: Testing for drawing fixes r30523, Doug Simons, 2010/06/04
- Re: Testing for drawing fixes r30523, Quentin Mathé, 2010/06/07
- Re: Testing for drawing fixes r30523, Doug Simons, 2010/06/07
- Re: Testing for drawing fixes r30523, Quentin Mathé, 2010/06/08
- Re: Testing for drawing fixes r30523, Nicola Pero, 2010/06/08
- Re: Testing for drawing fixes r30523, Quentin Mathé, 2010/06/23
- Re: Testing for drawing fixes r30523, Nicola Pero, 2010/06/23
- Re: Testing for drawing fixes r30523, Quentin Mathé, 2010/06/23
- Re: Testing for drawing fixes r30523,
Doug Simons <=
- Re: Testing for drawing fixes r30523, Eric Wasylishen, 2010/06/08
- Re: Testing for drawing fixes r30523, Quentin Mathé, 2010/06/09
- Re: Testing for drawing fixes r30523, Quentin Mathé, 2010/06/09
- Re: Testing for drawing fixes r30523, Quentin Mathé, 2010/06/11
- Re: Testing for drawing fixes r30523, Riccardo Mottola, 2010/06/11
- Re: Testing for drawing fixes r30523, David Chisnall, 2010/06/11
- Re: Testing for drawing fixes r30523, Lars Sonchocky-Helldorf, 2010/06/11
- Re: Testing for drawing fixes r30523, David Chisnall, 2010/06/11
- Re: Testing for drawing fixes r30523, Gregory Casamento, 2010/06/12
- Re: Testing for drawing fixes r30523, David Wetzel, 2010/06/13