Update of bug #35557 (project gnustep):
Category: Base/Foundation = Makefiles
Open/Closed:Open = Closed
___
Follow-up Comment #3:
Thanks. I applied
Update of bug #35459 (project gnustep):
Open/Closed:Open = Closed
___
Follow-up Comment #1:
Thanks... good point. Done.
Thanks
Update of bug #35233 (project gnustep):
Open/Closed:Open = Closed
___
Follow-up Comment #1:
Thanks!
___
Reply to this item at:
Follow-up Comment #1, bug #34658 (project gnustep):
This depends on how you configure gnustep-make. gnustep-make's
configure has the --enable-debug-by-default option. From the
configure documentation:
--enable-debug-by-default
Enable building with 'make debug=yes' by default. When you use
Update of bug #34658 (project gnustep):
Open/Closed:Open = Analyzed
___
Reply to this item at:
http://savannah.gnu.org/bugs/?34658
___
Follow-up Comment #3, bug #34602 (project gnustep):
__block is not a reserved word, but just a preprocessor define --
#define __block __attribute__((__blocks__(byref)))
Of course, I suppose Apple may change this in the future.
Thanks
___
Hi Joe,
GNUstep is not currently supported on Cygwin. The recommended way to
installing GNUstep on Windows
is by using MinGW. See
http://www.gnustep.org/resources/sources.html#windows
Thanks
On 2 Jul 2011, at 02:02, Joe Castro wrote:
I'm trying to build/install the GNUStep package in a
GNUstep is not supported on Cygwin. Feel free to figure out to make it work
there, and contribute patches!
Thanks
On 29 Jun 2011, at 06:45, 王奎懿（王益） wrote:
I am building gnustep-startup-0.26.1 on Cygwin. The step of building libobjc
stops with the following error messages. (The
Follow-up Comment #1, bug #33502 (project gnustep):
The problem is that SOPE has no been updated to use the Modern
Objective-C runtime API when using the GNU runtime.
The file that doesn't compiles starts with
#if GNU_RUNTIME
# include objc/objc-api.h
# include objc/encoding.h
#endif
...
Update of bug #33502 (project gnustep):
Status:None = Invalid
Open/Closed:Open = Closed
___
Reply to this item at:
Helen,
cygwin is not supported out of the box. MinGW is supported though! :-)
Thanks
-Original Message-
From: Helen Tang nyhelen2...@yahoo.com.hk
Sent: Wednesday, 8 June, 2011 12:53
To: bug-gnustep@gnu.org
Subject: Installation of libobjc failed
Follow-up Comment #4, bug #33392 (project gnustep):
IIRC, if GCC is compiling for a general x86 machine, it will
generate code that can run on any i386 processor even produced;
hence it won't use CPU operations available only in newer CPUs.
So atomic builtins will become calls to custom
Follow-up Comment #7, bug #33392 (project gnustep):
Yes. :-)
It may be slightly more complicated but we'll need to address
the complication. :-(
I think we'd like gnustep-make to generally add -march=xxx
(where xxx is something more recent than i386, a CPU released
24 years ago) but make it
Update of bug #33189 (project gnustep):
Severity: 4 - Important = 5 - Blocker
___
Follow-up Comment #5:
Well, according to your config.log, clang is recognized as a
version of gcc, except (as we
Follow-up Comment #3, bug #33189 (project gnustep):
gnustep-make 2.6.0 is supposed to try and detect if you're using GCC or clang
at configure time.
If you're using GCC, it will do the partial linking using -r, while if you're
using clang, it will do the partial linking using -Wl,-r.
What is
Update of bug #32876 (project gnustep):
Category:None = Makefiles
___
Reply to this item at:
http://savannah.gnu.org/bugs/?32876
___
Follow-up Comment #15, bug #30470 (project gnustep):
Ok, I implemented this for gnustep-make as well.
Thanks
___
Reply to this item at:
http://savannah.gnu.org/bugs/?30470
___
Message sent
Follow-up Comment #7, bug #32383 (project gnustep):
-- is this what you are referring to in order
to get the class loaded?
Yes and no. Obviously referring to the class by name to get it
loaded kind of defeats the purpose of NSClassFromString() ;-)
I was referring to a standard trick that
Follow-up Comment #2, bug #32383 (project gnustep):
It certainly isn't a bug in NSClassFromString(), but I do wonder
if it is a bug in the compiler/linker or not. :-(
On my GNU/Linux, the example works; the class is loaded
and available automatically even when not explicitly referenced.
So
Update of bug #30683 (project gnustep):
Open/Closed:Open = Closed
___
Follow-up Comment #4:
Thanks for reporting back :-)
Thanks
Follow-up Comment #3, bug #25869 (project gnustep):
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45953
Thanks
___
Reply to this item at:
http://savannah.gnu.org/bugs/?25869
___
Message
Follow-up Comment #1, bug #30683 (project gnustep):
The error suggests that Renaissance was not installed or not linked
correctly.
Do you have any more details on how Renaissance was installed ? That may
help :-)
Any unusual messages when you compiled and installed Renaissance ?
Thanks
Update of bug #30683 (project gnustep):
Category: Backend = Libraries
___
Reply to this item at:
http://savannah.gnu.org/bugs/?30683
___
Follow-up Comment #2, bug #30683 (project gnustep):
Hi Paul
it's hard to know without more information. Here are a couple of experiments
that you could do to gather a bit more information.
First of all, try using 'ldd' to get the list of libraries linked into your
program: type
ldd
Follow-up Comment #4, bug #30556 (project gnustep):
Does it work now from trunk ? Can we close it ? :-)
Thanks
___
Reply to this item at:
http://savannah.gnu.org/bugs/?30556
___
Message
How could I know whether is something here suspicious?
Here is the output of the command:
linux-vdso.so.1 = (0x7fff693d1000)
libgnustep-gui.so.0.18 =
/usr/GNUstep/System/Library/Libraries/libgnustep-gui.so.0.18
(0x7fd53c545000)
libgnustep-base.so.1.20 =
Finally, it goes! :)
So, on Debian it is not need to add this line, but on Gentoo it is,
right?
Yes, I guess so. Presumably Gentoo is using a more aggressive linker
setup ?
Anyway, leaving that line in the source code will make it work
everywhere, so I would
leave it in on Debian as
Update of bug #30548 (project gnustep):
Open/Closed:Open = In Test
___
Follow-up Comment #2:
Thanks Sergey
it's delicate as your test required two features that were unsupported up to
Follow-up Comment #3, bug #30548 (project gnustep):
Forgot to say ... please confirm if it now works for you or not! :-)
Thanks
___
Reply to this item at:
http://savannah.gnu.org/bugs/?30548
Update of bug #30548 (project gnustep):
Open/Closed: In Test = Closed
___
Follow-up Comment #5:
Excellent
Thanks for you help, the test case was really good. ;-)
Update of bug #29897 (project gnustep):
Open/Closed: In Test = Closed
___
Reply to this item at:
http://savannah.gnu.org/bugs/?29897
___
Update of bug #30239 (project gnustep):
Open/Closed: In Test = Closed
___
Follow-up Comment #4:
It seems this was tested and can be closed.
Thanks
Update of bug #30474 (project gnustep):
Open/Closed:Open = Closed
___
Follow-up Comment #3:
gnustep-make removes obsolete variables and features from the default setup
only 5 years after
Update of bug #29368 (project gnustep):
Open/Closed:Open = Closed
___
Reply to this item at:
http://savannah.gnu.org/bugs/?29368
___
Follow-up Comment #2, bug #30556 (project gnustep):
Did you configure gnustep-make with --enable-strict-v2-mode by any chance ?
If so, try again from subversion trunk and let me know :-)
Thanks
___
Reply to this item at:
Follow-up Comment #8, bug #30470 (project gnustep):
By the way, to clarify, the issue has nothing to do with old or new variables
(Richard was right in creating a separate issue for that). ;-)
For example, Derek's LD_LIBRARY_PATH is set to:
Follow-up Comment #10, bug #30470 (project gnustep):
Sorry for posting again, just wanted to make sure people searching for this
topic find updated information --
I can see a case for extending this, but it's not clear how:
Perhaps just to disable the USER domain entirely.
Perhaps to map the
Follow-up Comment #1, bug #30299 (project gnustep):
Thanks Yavor
very useful feedback - this is related to bug #24109 (again, thanks for the
suggestions in there!) in the sense that the current default behaviour of
gnustep-make when linking libraries (all libraries, not just gnustep-gui or
Update of bug #29897 (project gnustep):
Status:None = Fixed
Open/Closed:Open = In Test
___
Follow-up Comment #1:
Thanks David
that
Follow-up Comment #3, bug #29761 (project gnustep):
Thanks David
just for me to understand exactly, in the comparison picture, the part on the
right is how it is now. The part on the left is how you'd like it to be ?
The difference being that on the right the popup button is bigger than
Follow-up Comment #1, bug #29730 (project gnustep):
Thanks Quentin
yes, that's a known issue in gnustep-base's makefiles/configure. It's time
to fix it :-)
It works that way because the GNUmakefiles are partially generated by
./configure, so you need to do a full ./configure before you can
Follow-up Comment #1, bug #29761 (project gnustep):
Are you sure that it is a Renaissance bug ?
I tried some Apple OS X applications (eg, Mail, Address Book) looked at their
NSPopUpButtons, and they seem to look in the same way. When you click on
them, they popup and take quite a lot of white
Follow-up Comment #1, bug #29634 (project gnustep):
Well done Jamison!
Not only this is the right place to report the bug, but your fix looks spot
on :-)
Great stuff. A few comments -
* in newer versions of gnustep-make, we're trying to allow people to use
LIBRARY_NAME=Foo and
Update of bug #29634 (project gnustep):
Status:None = Fixed
Open/Closed:Open = Closed
___
Follow-up Comment #2:
Ok ... done.
Update of bug #25356 (project gnustep):
Status:None = Fixed
___
Follow-up Comment #15:
Ok ... I fixed this in gnustep-base trunk. Hopefully it now works fine and
it will be fixed
Follow-up Comment #16, bug #25356 (project gnustep):
Forgot to say that installation-domains.conf now works fine for me on
Windows. :-)
Worth having more testing though.
Thanks
___
Reply to this item at:
Follow-up Comment #7, bug #29291 (project gnustep):
The gnustep-base configure.ac script seems wrong ...
CPPFLAGS=$CPPFLAGS -I$GNUSTEP_SYSTEM_HEADERS
-I$GNUSTEP_LOCAL_HEADERS/$LIBRARY_COMBO
LDFLAGS=$LDFLAGS -L$GNUSTEP_SYSTEM_LIBRARIES
-L$GNUSTEP_LOCAL_LIBRARIES
These just ignore the
Follow-up Comment #1, bug #29368 (project gnustep):
Gregory,
can you provide a practical example of what you are trying to do that you
can't do with the current setup ?
--
With regard to your second point, as discussed many times, if
GNUSTEP_SYSTEM_TOOLS is not in the PATH, then the GNUstep
Follow-up Comment #1, bug #29301 (project gnustep):
I could not get the latest svn version of gnustep-base to
compile properly
Can you report what problems you had ?
It worked for me just about a week ago, using the instructions on
core/make/Documentation/README.MinGW. :-)
Thanks
Follow-up Comment #1, bug #29291 (project gnustep):
It should work.
Can you provide more details of what you did ?
My understanding is that you did
cd /xxx/core/make
./configure --disable-flattened
su -c 'make install'
cd /xxx/dev-libs/libobjc2
make
su -c 'make install'
cd /xxx/core/make
Follow-up Comment #2, bug #29291 (project gnustep):
I guess you're getting the problem when trying to configure gnustep-base, not
gnustep-make.
I'll need to check on that.
Thanks for reporting the problem :-)
___
Reply to this item at:
Follow-up Comment #4, bug #29203 (project gnustep):
Are there any plans to add sync support to gcc's libobjc any
time soon? If not, I'd be in favor of removing sync support from
GNUstep's libobjc and not getting into the troubles of adding an
autoconf test.
GCC is currently frozen (only
Follow-up Comment #2, bug #29203 (project gnustep):
I guess the solution is to remove sync support from the libobjc
code as it's now in base. seems a lot simpler than adding
autoconf tests and conditionally compiling the sync stuff.
Not sure. Once the libobjc shipped with GCC gets sync
Follow-up Comment #14, bug #25356 (project gnustep):
I managed to reproduce this, and to track it down.
First of all, if you do './configure' directly inside Source/pathconfig, the
correct installation domain (SYSTEM) is used.
The problem only occurs if you do './configure' at the top-level.
Update of bug #27801 (project gnustep):
Open/Closed: In Test = Closed
___
Follow-up Comment #5:
Closing since it has been implemented and I tested it.
I hope someone (other than me) tested
Update of bug #27801 (project gnustep):
Status:None = Fixed
Open/Closed:Open = In Test
___
Follow-up Comment #4:
I implemented
# make message=yes GNUSTEP_INSTALLATION_DOMAIN=SYSTEM
I can help with the typo :-) ... this line needs to be
make messages=yes GNUSTEP_INSTALLATION_DOMAIN=SYSTEM
(messages, not message)
Thanks
___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
At work, one part of our application is used to 'scan' data
gathered from various devices, normalizes it, and inserts it into
the database as measurements. This is very performance-critical,
and for a very large percentage of the cases, we are only ever
inserting rows (new
Follow-up Comment #1, bug #27801 (project gnustep):
Could you clarify ?
If you have an example, could you attach/describe it in the issue ?
Examples are wonderful at clarifying these things. :-)
Thanks
___
Reply to this item at:
Follow-up Comment #12, bug #25356 (project gnustep):
Thanks - that's interesting.
Could you also send the file
Source/pathconfig/config.log
But it looks like I'll need to get access to a Windows machine to sort this
(and the other new Windows building issues) out. Hmmm.
Thanks
Update of bug #26280 (project gnustep):
Open/Closed:Open = Closed
___
Follow-up Comment #4:
Ok ... in trunk I implemented the check and printing a warning. :-)
Thanks
Update of bug #25536 (project gnustep):
Open/Closed:Open = Closed
___
Follow-up Comment #3:
Closing to tidy up the list of bugs - it was a particular situation with
conflicting libobjc
Follow-up Comment #9, bug #25356 (project gnustep):
Can you provide the output of a plain ./configure of gnustep-base ?
And also the various config log files ? :-)
Thanks
___
Reply to this item at:
http://savannah.gnu.org/bugs/?25356
On 3 Oct 2009, at 23:20, Markus Hitter wrote:
Having just gnustep-config in the PATH is pretty useless ... I mean
when
users install Gorm, how are they going to run it if the Gorm
executable is not
in the PATH ?
Well, either by typing Gorm in a terminal or by selecting Gorm
from the
Follow-up Comment #5, bug #26437 (project gnustep):
Yes, this is not a gnustep-base problem.
In fact, it's not even a GNUstep problem :-). You'll have the same problem
with any other software that is installed into a custom, non-native location.
Eg, if you install some package into
Follow-up Comment #7, bug #26437 (project gnustep):
I suppose we could prompt the ubuntu package manager for
gnustep-make to submit a new filesystem layout file defining
where gnustep-config should be put to be in the PATH.
I actually think they should either use the FHS layout, so that
Follow-up Comment #4, bug #27517 (project gnustep):
What is happening is that GCC, on cygwin, is generating the autodependency
file and using filenames such as
G:/GNUstep/mingw/include/stdlib.h
in the autodependency file. Unfortunately GNU make can't really work with
filenames that contain
Update of bug #27517 (project gnustep):
Open/Closed:Open = Closed
___
Follow-up Comment #5:
Ok ... I turned off autodependencies on cygwin.
Thanks
Follow-up Comment #1, bug #27517 (project gnustep):
What compiler are you using ?
Can you send the file obj/GSCategories.m.d ?
By the way, as a workaround you can edit
/usr/GNUstep/System/Library/Makefiles/config.make (or wherever your installed
config.make is) and change AUTO_DEPENDENCIES
Update of bug #27433 (project gnustep):
Open/Closed:Open = Closed
___
Follow-up Comment #3:
Thanks
I made these changes (renaming of everything, updating references etc) to
trunk - they
Update of bug #27432 (project gnustep):
Open/Closed:Open = Closed
___
Follow-up Comment #2:
Thanks Michel,
good catch! :-)
I fixed the typo in subversion. Since this is a typo in the
Follow-up Comment #1, bug #27433 (project gnustep):
Thanks
this looks good. But I guess we also need to rename all the .texi files, and
update the
@setfilename filesystem.info
command at the beginning of each .texi ?
Thanks
___
Follow-up Comment #1, bug #26055 (project gnustep):
I think this has been fixed by the recent Cygwin patches.
Riccardo, can you confirm and close the issue ? :-)
Thanks!
___
Reply to this item at:
http://savannah.gnu.org/bugs/?26055
Update of bug #26280 (project gnustep):
Assigned to:None = nico
___
Follow-up Comment #2:
This seems to be a common problem with gnustep-make, so I need to add code to
gnustep-make to
Update of bug #26410 (project gnustep):
Open/Closed:Open = Closed
___
Follow-up Comment #3:
Thanks ... I updated and fixed the patch, and applied it.
It seems to work ... hopefully will
Update of bug #27222 (project gnustep):
Open/Closed:Open = Closed
___
Follow-up Comment #3:
Thanks Yavor
I made the change. It seems to work for me - let me know if it works for
you.
Update of bug #27170 (project gnustep):
Open/Closed:Open = Closed
___
Follow-up Comment #1:
Thanks Yaakov!
I applied your patch. It looks brilliant - but I don't have a Windows/Cygwin
Follow-up Comment #1, bug #26280 (project gnustep):
Hi Jonathan
sorry for the late reply.
The problem you're experiencing might be due to a misunderstanding / lack of
explanations in the gnustep-make documentation.
I guess I'll quote stuff from gnustep-make --
# If you want to insert your
Follow-up Comment #1, bug #27033 (project gnustep):
Sounds good to me.
Thanks
___
Reply to this item at:
http://savannah.gnu.org/bugs/?27033
___
Message sent via/by Savannah
Follow-up Comment #1, bug #27222 (project gnustep):
We can certainly change the default flags to be -g -O2. Sounds like a good
idea.
If we get some agreement on what the flags should be, we can easily implement
them. I guess you were thinking of
* debug=yes (default): -g -O2
* debug=no:
Follow-up Comment #2, bug #26053 (project gnustep):
Could you *always* include the output of 'make messages=yes' when
reporting issues ?
Thanks
___
Reply to this item at:
http://savannah.gnu.org/bugs/?26053
Follow-up Comment #2, bug #25909 (project gnustep):
It sounds like when you launch Gomoku from the MinGW shell,
you probably have sourced GNUstep.sh so have all the
GNUSTEP_XXX environment variables set.
When you launch it by double-clicking on it, no
environment variables are set.
That
On 26 Feb 2009, at 22:31, Julien Isorce wrote:
Hi,
I have a project where several different build must coexist together
(libtool, CMake, ...)
I would like to rename my GNUmakefile to GNUmakefile.gnustep,
because the main build is using libtool and so I want avoid
conflicts when typing
me know (can you
provide me the output of 'make messages=yes' when trying to link the
library). Make sure you install the library
before trying to link it. ;-)
Thanks
2009/2/24 Nicola Pero nicola.p...@meta-innovation.com
You want to use subprojects :-)
Your top level GNUmakefile should
Update of bug #25606 (project gnustep):
Open/Closed:Open = Closed
___
Follow-up Comment #1:
OK - thanks - good point - I fixed it on trunk. :-)
Thanks
Follow-up Comment #1, bug #25536 (project gnustep):
Well it seems that you have two conflicting libobjc libraries :-(
... and the wrong one is in /usr/local/lib so it gets picked up.
That sounds like a problem in the ports system. You have to be
careful also because gnustep-make will be using
You want to use subprojects :-)
Your top level GNUmakefile should look like
include $(GNUSTEP_MAKEFILES)/common.make
LIBRARY_NAME = mylib
mylib_SUBPROJECTS = source1 source2
include $(GNUSTEP_MAKEFILES)/library.make
This will compile a single library, at top level, by linking together
Update of bug #9445 (project gnustep):
Status: Postponed = Fixed
___
Reply to this item at:
http://savannah.gnu.org/bugs/?9445
___
?
At the moment, the main difference is that bundles copy, while gswbundles
symlink.
That's the only real difference I can think of.
Thanks
-Original Message-
From: David Ayers ay...@fsfe.org
Sent: Monday, 16 February, 2009 13:06
To: Nicola Pero nicola.p...@meta-innovation.com
Cc: GNUstep
Update of bug #9445 (project gnustep):
Open/Closed: In Test = Closed
___
Follow-up Comment #6:
I implemented parallel build stuff
Thanks
Update of bug #25552 (project gnustep):
Open/Closed:Open = Closed
___
Follow-up Comment #6:
Good :-)
Thanks
___
Reply to this
Update of bug #13383 (project gnustep):
Open/Closed:Open = Closed
___
Follow-up Comment #8:
Being worked on as #25602
Thanks
___
Update of bug #25570 (project gnustep):
Open/Closed:Open = Closed
___
Follow-up Comment #2:
OK - thanks Riccardo, I did the GNUmakefile change. It should compile on
Windows now. :-)
Follow-up Comment #1, bug #25524 (project gnustep):
Hi Lucas
great to see about MidnightBSD. Looks like a very cool project. :-)
Since it's a fork of FreeBSD, would it be more efficient to just use the
FreeBSD
compile/link flags ? As a comparison, there are millions of Linux
distributions
Update of bug #24665 (project gnustep):
Open/Closed:Open = Closed
___
Follow-up Comment #5:
OK. I'll close the issue. Please reopen it (or file a new issue) if you
manage
to reproduce
Follow-up Comment #1, bug #25552 (project gnustep):
Which version of gnustep-base produces the error ? Is it trunk ?
Thanks
___
Reply to this item at:
http://savannah.gnu.org/bugs/?25552
Update of bug #9445 (project gnustep):
Open/Closed:Open = In Test
___
Follow-up Comment #5:
OK ... I experimentally implemented my idea for tools and
libraries. Once that works for the
Carol, thanks for your feedback - and sorry for the late reply
And why is there not a precompiled version of the Renaissance 0.9.0
Framework posted?
Would you be interested in producing precompiled versions of
Renaissance for Apple OS X? :-)
We can very happily make them available on
Update of bug #25462 (project gnustep):
Category:None = Makefiles
Assigned to:None = nico
___
Follow-up Comment #1:
Giuseppe,
linking
Follow-up Comment #4, bug #25439 (project gnustep):
Matt
it's a good point - but it's expected behaviour - on Windows all libraries
are always
linked in, on GNU/Linux only the essential ones.
Now maybe that's not the best behaviour on GNU/Linux - there is already a
bug
open about that.
Thanks
1 - 100 of 470 matches
Mail list logo
