* bug#7848: 23.2.91; Can't build with MinGW
@ 2011-01-15 7:34 Kazuhiro Ito
2011-01-16 0:41 ` Eli Zaretskii
0 siblings, 1 reply; 8+ messages in thread
From: Kazuhiro Ito @ 2011-01-15 7:34 UTC (permalink / raw)
To: 7848
When I build emacs-23 branch at present with MinGW, below error
occurs while linking.
> oo-spd/i386/temacs1.a(image.o):image.c:(.text+0xa8fa): undefined reference to `SET_SYMBOL_VAL'
> collect2: ld returned 1 exit status
> make[1]: *** [oo-spd/i386/temacs.exe] Error 1
> make[1]: Leaving directory `/f/build/emacs-23/src'
> make: *** [all-other-dirs-gmake] Error 2
SET_SYMBOL_VAL is defined in src/lisp.h on trunk but not on emacs-23
branch.
--
Kazuhiro Ito
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#7848: 23.2.91; Can't build with MinGW
2011-01-15 7:34 bug#7848: 23.2.91; Can't build with MinGW Kazuhiro Ito
@ 2011-01-16 0:41 ` Eli Zaretskii
2011-01-16 4:41 ` Stefan Monnier
2011-01-16 6:16 ` Kazuhiro Ito
0 siblings, 2 replies; 8+ messages in thread
From: Eli Zaretskii @ 2011-01-16 0:41 UTC (permalink / raw)
To: Kazuhiro Ito; +Cc: 7848
> Date: Sat, 15 Jan 2011 16:34:08 +0900
> From: Kazuhiro Ito <kzhr@d1.dion.ne.jp>
> Cc:
>
> When I build emacs-23 branch at present with MinGW, below error
> occurs while linking.
>
> > oo-spd/i386/temacs1.a(image.o):image.c:(.text+0xa8fa): undefined reference to `SET_SYMBOL_VAL'
> > collect2: ld returned 1 exit status
> > make[1]: *** [oo-spd/i386/temacs.exe] Error 1
> > make[1]: Leaving directory `/f/build/emacs-23/src'
> > make: *** [all-other-dirs-gmake] Error 2
>
> SET_SYMBOL_VAL is defined in src/lisp.h on trunk but not on emacs-23
> branch.
Sorry. Please try replacing this:
SET_SYMBOL_VAL (XSYMBOL (Qlibpng_version), make_number (PNG_LIBPNG_VER));
with this:
XSYMBOL (Qlibpng_version)->value = make_number (PNG_LIBPNG_VER);
and make a similar change in this line:
SET_SYMBOL_VAL (XSYMBOL (Qlibpng_version), make_number (-1));
I cannot test this where I'm typing this mail, but if you tell me that
these two changes fix the problem, I will commit this change to the
release branch.
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#7848: 23.2.91; Can't build with MinGW
2011-01-16 0:41 ` Eli Zaretskii
@ 2011-01-16 4:41 ` Stefan Monnier
2011-01-16 10:03 ` Eli Zaretskii
2011-01-16 6:16 ` Kazuhiro Ito
1 sibling, 1 reply; 8+ messages in thread
From: Stefan Monnier @ 2011-01-16 4:41 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Kazuhiro Ito, 7848
> Sorry. Please try replacing this:
> SET_SYMBOL_VAL (XSYMBOL (Qlibpng_version), make_number (PNG_LIBPNG_VER));
[...]
> XSYMBOL (Qlibpng_version)->value = make_number (PNG_LIBPNG_VER);
I would recommend to stay away from such low-level code unless you're
writing code that tries to implement part of the binding-semantics
of Emacs. I.e. just use Fset.
Stefan
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#7848: 23.2.91; Can't build with MinGW
2011-01-16 0:41 ` Eli Zaretskii
2011-01-16 4:41 ` Stefan Monnier
@ 2011-01-16 6:16 ` Kazuhiro Ito
2011-01-16 9:57 ` Eli Zaretskii
1 sibling, 1 reply; 8+ messages in thread
From: Kazuhiro Ito @ 2011-01-16 6:16 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 7848
> > When I build emacs-23 branch at present with MinGW, below error
> > occurs while linking.
> >
> > > oo-spd/i386/temacs1.a(image.o):image.c:(.text+0xa8fa): undefined reference to `SET_SYMBOL_VAL'
(snip)
> > SET_SYMBOL_VAL is defined in src/lisp.h on trunk but not on emacs-23
> > branch.
>
> Sorry. Please try replacing this:
>
> SET_SYMBOL_VAL (XSYMBOL (Qlibpng_version), make_number (PNG_LIBPNG_VER));
>
> with this:
>
> XSYMBOL (Qlibpng_version)->value = make_number (PNG_LIBPNG_VER);
>
> and make a similar change in this line:
>
> SET_SYMBOL_VAL (XSYMBOL (Qlibpng_version), make_number (-1));
>
> I cannot test this where I'm typing this mail, but if you tell me that
> these two changes fix the problem, I will commit this change to the
> release branch.
Thanks, I confirmed above changes fixed my problem (not tested in the
case of no PNG support).
--
Kazuhiro Ito
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#7848: 23.2.91; Can't build with MinGW
2011-01-16 6:16 ` Kazuhiro Ito
@ 2011-01-16 9:57 ` Eli Zaretskii
0 siblings, 0 replies; 8+ messages in thread
From: Eli Zaretskii @ 2011-01-16 9:57 UTC (permalink / raw)
To: Kazuhiro Ito; +Cc: 7848-done
> Date: Sun, 16 Jan 2011 15:16:31 +0900
> From: Kazuhiro Ito <kzhr@d1.dion.ne.jp>
> Cc: 7848@debbugs.gnu.org
>
> > Sorry. Please try replacing this:
> >
> > SET_SYMBOL_VAL (XSYMBOL (Qlibpng_version), make_number (PNG_LIBPNG_VER));
> >
> > with this:
> >
> > XSYMBOL (Qlibpng_version)->value = make_number (PNG_LIBPNG_VER);
> >
> > and make a similar change in this line:
> >
> > SET_SYMBOL_VAL (XSYMBOL (Qlibpng_version), make_number (-1));
> >
> > I cannot test this where I'm typing this mail, but if you tell me that
> > these two changes fix the problem, I will commit this change to the
> > release branch.
>
> Thanks, I confirmed above changes fixed my problem (not tested in the
> case of no PNG support).
Thanks, I installed these changes on the emacs-23 branch.
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#7848: 23.2.91; Can't build with MinGW
2011-01-16 4:41 ` Stefan Monnier
@ 2011-01-16 10:03 ` Eli Zaretskii
2011-01-16 15:21 ` Stefan Monnier
0 siblings, 1 reply; 8+ messages in thread
From: Eli Zaretskii @ 2011-01-16 10:03 UTC (permalink / raw)
To: Stefan Monnier; +Cc: kzhr, 7848
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Kazuhiro Ito <kzhr@d1.dion.ne.jp>, 7848@debbugs.gnu.org
> Date: Sat, 15 Jan 2011 23:41:51 -0500
>
> > Sorry. Please try replacing this:
>
> > SET_SYMBOL_VAL (XSYMBOL (Qlibpng_version), make_number (PNG_LIBPNG_VER));
> [...]
> > XSYMBOL (Qlibpng_version)->value = make_number (PNG_LIBPNG_VER);
>
> I would recommend to stay away from such low-level code unless you're
> writing code that tries to implement part of the binding-semantics
> of Emacs. I.e. just use Fset.
Using Fset here would be a terrible overkill, IMO. I'm not even sure
I understand all of its semantics, and not sure it will work correctly
in the context of an init_* function that is called when Emacs is
dumped. OTOH, direct assignments of symbol's value like above _are_
used in several init_* functions and elsewhere.
Also, I wanted to un-break the release branch as fast as I could.
Having said all that, feel free to change what I did to use Fset, both
on the branch and on the trunk.
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#7848: 23.2.91; Can't build with MinGW
2011-01-16 10:03 ` Eli Zaretskii
@ 2011-01-16 15:21 ` Stefan Monnier
2011-01-16 15:58 ` Eli Zaretskii
0 siblings, 1 reply; 8+ messages in thread
From: Stefan Monnier @ 2011-01-16 15:21 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: kzhr, 7848
>> I would recommend to stay away from such low-level code unless you're
>> writing code that tries to implement part of the binding-semantics
>> of Emacs. I.e. just use Fset.
> Using Fset here would be a terrible overkill, IMO.
Overkill? For code that's not even inside a loop? What are you talking about?
> I'm not even sure I understand all of its semantics,
The semantics of Fset are the same as the ones of `setq' which you use
days-in days-out in Elisp. I.e. it's the semantics you know best,
whereas the semantics of SET_SYMBOL_VAL are a lot more tricky.
> and not sure it will work correctly in the context of an init_*
> function that is called when Emacs is dumped.
Yes, it'll work just fine, pretty much in any context (the only tricky
context in this respect is when/before the `nil' symbol&variable and the
`unbound' value are built, AFAIK).
> OTOH, direct assignments of symbol's value like above _are_
> used in several init_* functions and elsewhere.
I've fixed some of those in the past, and feel free to fix more of them.
> Also, I wanted to un-break the release branch as fast as I could.
I'm not complaining, at all. Just giving advice.
Stefan
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#7848: 23.2.91; Can't build with MinGW
2011-01-16 15:21 ` Stefan Monnier
@ 2011-01-16 15:58 ` Eli Zaretskii
0 siblings, 0 replies; 8+ messages in thread
From: Eli Zaretskii @ 2011-01-16 15:58 UTC (permalink / raw)
To: Stefan Monnier; +Cc: kzhr, 7848
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: kzhr@d1.dion.ne.jp, 7848@debbugs.gnu.org
> Date: Sun, 16 Jan 2011 10:21:53 -0500
>
> >> I would recommend to stay away from such low-level code unless you're
> >> writing code that tries to implement part of the binding-semantics
> >> of Emacs. I.e. just use Fset.
> > Using Fset here would be a terrible overkill, IMO.
>
> Overkill? For code that's not even inside a loop? What are you talking about?
Look at its body, man. All I want is to assign a simple value to a
simple global-scope variable. Look how many unrelated use-cases the
implementation of Fset handles. How can a mere mortal who was never
privy to the intimate details of whatever-local variables possibly
grasp what is going on there? How can I be expected to be able to
install a quick and safe fix on a release branch with all that
complexity that is utterly unrelated to what I want to do?
If you want to avoid code that knows too much about variable
internals, we should have a much simpler utility function to do this
kind of job in such special cases. SET_SYMBOL_VAL looked like such a
utility.
> > I'm not even sure I understand all of its semantics,
>
> The semantics of Fset are the same as the ones of `setq' which you use
> days-in days-out in Elisp.
I use no Lisp at all during dumping. There are certain things one
shouldn't do at that time. My everyday experience in Emacs does not
help me in this case.
> I.e. it's the semantics you know best, whereas the semantics of
> SET_SYMBOL_VAL are a lot more tricky.
If it is tricky, please consider putting a suitable commentary near it
to explain the trickery, and also tell why this macro should be used
with care, or be avoided, or whatever.
> > and not sure it will work correctly in the context of an init_*
> > function that is called when Emacs is dumped.
>
> Yes, it'll work just fine, pretty much in any context (the only tricky
> context in this respect is when/before the `nil' symbol&variable and the
> `unbound' value are built, AFAIK).
And I'm supposed to learn this from where, exactly? And how do I know
whether any specific code runs after that critical point?
That's precisely why I avoided Fset: because I could not convince
myself that it is always safe to use it in a function that runs during
dumping. If Fset's implementation was simpler, I could have
understood that myself.
> I'm not complaining, at all. Just giving advice.
Thanks for the advice.
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2011-01-16 15:58 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-01-15 7:34 bug#7848: 23.2.91; Can't build with MinGW Kazuhiro Ito
2011-01-16 0:41 ` Eli Zaretskii
2011-01-16 4:41 ` Stefan Monnier
2011-01-16 10:03 ` Eli Zaretskii
2011-01-16 15:21 ` Stefan Monnier
2011-01-16 15:58 ` Eli Zaretskii
2011-01-16 6:16 ` Kazuhiro Ito
2011-01-16 9:57 ` Eli Zaretskii
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.