public inbox for cygwin-xfree@sourceware.org
help / color / mirror / Atom feed
* RE: DDD 3.3.8 (i686-pc-cygwin) gets `Segmentation fault WAS Re: c ompiling DDD
@ 2003-12-04 21:28 Richard Campbell
2003-12-04 23:54 ` libtool created import libs broken? was RE: DDD 3.3.8 (i686-pc-cygwin) gets `Segmentation fault Brian Ford
0 siblings, 1 reply; 20+ messages in thread
From: Richard Campbell @ 2003-12-04 21:28 UTC (permalink / raw)
To: 'cygwin-xfree@cygwin.com'; +Cc: bug-ddd
bash-2.05b$ autoreconf --install --force
configure.ac:248: warning: AC_CANONICAL_HOST invoked multiple times
autoconf/specific.m4:363: AC_CYGWIN is expanded from...
configure.ac:248: the top level
autoheader: WARNING: Using auxiliary files such as `acconfig.h',
`config.h.bot'
autoheader: WARNING: and `config.h.top', to define templates for
`config.h.in'
autoheader: WARNING: is deprecated and discouraged.
autoheader:
autoheader: WARNING: Using the third argument of `AC_DEFINE' and
autoheader: WARNING: `AC_DEFINE_UNQUOTED' allows to define a template
without
autoheader: WARNING: `acconfig.h':
autoheader:
autoheader: WARNING: AC_DEFINE([NEED_FUNC_MAIN], 1,
autoheader: [Define if a function `main' is needed.])
autoheader:
autoheader: WARNING: More sophisticated templates can also be produced, see
the
autoheader: WARNING: documentation.
configure.in:54: error: possibly undefined macro: AC_PROG_CC_GNU
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure.in:65: error: possibly undefined macro: AC_PROG_CC_G
configure.in:198: error: do not use LIBOBJS directly, use AC_LIBOBJ (see
section `AC_LIBOBJ vs LIBOBJS'
configure.in:310: error: possibly undefined macro: AC_PROG_CC_WORKS
autoreconf: /usr/autotool/devel/bin/autoconf failed with exit status: 1
bash-2.05b$ autoreconf --version
autoreconf (GNU Autoconf) 2.59
^ permalink raw reply [flat|nested] 20+ messages in thread
* libtool created import libs broken? was RE: DDD 3.3.8 (i686-pc-cygwin) gets `Segmentation fault
2003-12-04 21:28 DDD 3.3.8 (i686-pc-cygwin) gets `Segmentation fault WAS Re: c ompiling DDD Richard Campbell
@ 2003-12-04 23:54 ` Brian Ford
2003-12-05 3:11 ` Charles Wilson
0 siblings, 1 reply; 20+ messages in thread
From: Brian Ford @ 2003-12-04 23:54 UTC (permalink / raw)
To: 'cygwin-xfree@cygwin.com'; +Cc: bug-ddd, cygwin
Charles Wilson,
Could you look at the problem discovered in the thread below and give us a
comment? Thanks.
http://www.cygwin.com/ml/cygwin-xfree/2003-12/msg00053.html
I'm not an autotool expert, but:
On Thu, 4 Dec 2003, Richard Campbell wrote:
> bash-2.05b$ autoreconf --install --force
These are just warnings, so I think this part worked fine. I guess the
ddd people should clean these up?
> configure.ac:248: warning: AC_CANONICAL_HOST invoked multiple times
> autoconf/specific.m4:363: AC_CYGWIN is expanded from...
> configure.ac:248: the top level
> autoheader: WARNING: Using auxiliary files such as `acconfig.h',
> `config.h.bot'
> autoheader: WARNING: and `config.h.top', to define templates for
> `config.h.in'
> autoheader: WARNING: is deprecated and discouraged.
> autoheader:
> autoheader: WARNING: Using the third argument of `AC_DEFINE' and
> autoheader: WARNING: `AC_DEFINE_UNQUOTED' allows to define a template
> without
> autoheader: WARNING: `acconfig.h':
> autoheader:
> autoheader: WARNING: AC_DEFINE([NEED_FUNC_MAIN], 1,
> autoheader: [Define if a function `main' is needed.])
> autoheader:
> autoheader: WARNING: More sophisticated templates can also be produced, see
> the
> autoheader: WARNING: documentation.
>
Here is where we should have stopped, although I don't know how to do
that with autoreconf. The following are errors from subdirectories that
use older (circa 2.13) autoconf scripts. autoreconf does not support
mixed versions, I guess?
> configure.in:54: error: possibly undefined macro: AC_PROG_CC_GNU
> If this token and others are legitimate, please use m4_pattern_allow.
> See the Autoconf documentation.
> configure.in:65: error: possibly undefined macro: AC_PROG_CC_G
> configure.in:198: error: do not use LIBOBJS directly, use AC_LIBOBJ (see
> section `AC_LIBOBJ vs LIBOBJS'
> configure.in:310: error: possibly undefined macro: AC_PROG_CC_WORKS
> autoreconf: /usr/autotool/devel/bin/autoconf failed with exit status: 1
>
So, if this hasn't left your tree broken, I think it would test what I
wanted. You should now have libtool 1.5 for the main ddd tree. I think
it would fix this.
New in 1.5: 2002-04-14; CVS version 1.4e, Libtool team:
* Support auto-import patch to binutils on cygwin for much improved dll
support.
--
Brian Ford
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
Phone: 314-551-8460
Fax: 314-551-8444
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: libtool created import libs broken? was RE: DDD 3.3.8 (i686-pc-cygwin) gets `Segmentation fault
2003-12-04 23:54 ` libtool created import libs broken? was RE: DDD 3.3.8 (i686-pc-cygwin) gets `Segmentation fault Brian Ford
@ 2003-12-05 3:11 ` Charles Wilson
2003-12-05 12:46 ` Arnaud Desitter
0 siblings, 1 reply; 20+ messages in thread
From: Charles Wilson @ 2003-12-05 3:11 UTC (permalink / raw)
To: cygwin-xfree; +Cc: bug-ddd, cygwin
Brian Ford wrote:
> Charles Wilson,
>
> Could you look at the problem discovered in the thread below and give us a
> comment? Thanks.
>
> http://www.cygwin.com/ml/cygwin-xfree/2003-12/msg00053.html
There are a couple of problems.
1) OOB, DDD uses libtool-1.4.2 -- which has very minimal support for
cygwin. It works (barely) -- and it takes a whole chapter in the
autobook http://sources.redhat.com/autobook/ to explain the differences
from "normal" unix shared lib creation. The new 1.5+ procedure (with
binutils/gcc autoimport, autoexport, and .dll.a naming convention
support) is much more unix-like. Although ltmodules don't seem to work
very well, except in toy cases. :-(
2) Old libtool, when it finds a .la file (which specifies the DLL
name and the static lib name, AND the import lib name) doesn't appear to
handle the implib properly -- it thinks that it does not exist, and
attempts to recreate it from scratch using the export table from the
DLL. But it uses old, buggy, obsolete, unmaintained, code to do so.
Now, there are only four libraries in your link list that have .la
files: expat, fontconfig, freetype, and Xm. And whaddaya know -- those
are precisely the libs that cause problems in your link command.
QuickNDirty answer: hide those four .la files and re-run configure.
Long answer: update to the most recent autotools (relibtoolize).
However....
>>bash-2.05b$ autoreconf --install --force
>
>
> These are just warnings, so I think this part worked fine. I guess the
> ddd people should clean these up?
>
Yes, they should -- when they are ready to move to autoconf-2.5x,
automake-1.7.x, and libtool-1.5+. But as you can see, there are
incompatibilities between autoconf-2.13 and -2.5x. Basically, you CAN
write a configure.in file that works with both -- but 2.13 was much more
forgiving than 2.5x, so most existing configure.in's need to be brought
up to 'spec' in order to work with 2.5x.
And the _easiest_ way to do THAT is to make changes to the configure.in
that are NOT backwards compatible with 2.13! So, it's possible to allow
both versions to work with your configure.in, but much harder than just
upgrading in a non-backwards-compatible way.
So most projects (like gcc/binutils until recently) have taken a
wait-and-see approach to autoconf-2.5x. Which leaves us poor cygwin
folks, who NEED libtool-1.5 for decent DLL support, out in the cold --
because libtool-1.5 requires automake-1.7.x which requires autoconf-2.5x...
(And, even though it is conceivable to use ac-2.5x with old-style
automake-1.4p6, the cygwin wrapper system doesn't let you do that. So,
if you re-autoconf with ac-2.5x, you'll also need to re-automake with
am-1.[67].x -- which brings its own share of possible incompatibilities
in the Makefile.am's. And you'll want to add -no-undefined to the
libXXXXX_LDFLAGS setting for any libraries that DDD builds)
>>configure.ac:248: warning: AC_CANONICAL_HOST invoked multiple times
>>autoconf/specific.m4:363: AC_CYGWIN is expanded from...
>>configure.ac:248: the top level
>>autoheader: WARNING: Using auxiliary files such as `acconfig.h',
>>`config.h.bot'
>>autoheader: WARNING: and `config.h.top', to define templates for
>>`config.h.in'
>>autoheader: WARNING: is deprecated and discouraged.
>>autoheader:
>>autoheader: WARNING: Using the third argument of `AC_DEFINE' and
>>autoheader: WARNING: `AC_DEFINE_UNQUOTED' allows to define a template
>>without
>>autoheader: WARNING: `acconfig.h':
>>autoheader:
>>autoheader: WARNING: AC_DEFINE([NEED_FUNC_MAIN], 1,
>>autoheader: [Define if a function `main' is needed.])
>>autoheader:
>>autoheader: WARNING: More sophisticated templates can also be produced, see
>>the
>>autoheader: WARNING: documentation.
Yep, you're gonna have to take care of this stuff by hand. I believe
that support for config.h.top etc will be going away in autoconf-2.60,
but that's **just** a guess. And anyway, 2.60 isn't expected for at
least several months (and 2.59 won't go 'poof' then, anyway)
> Here is where we should have stopped, although I don't know how to do
> that with autoreconf. The following are errors from subdirectories that
> use older (circa 2.13) autoconf scripts. autoreconf does not support
> mixed versions, I guess?
No, not at all. That's why Zack Weinberg (Nathaniel Nerode?) over on
the gcc list are updating gcc's (and friends') configure.in's by hand,
one directory at a time.
Bringing the autotool infrastructure up to snuff for a large project,
like DDD, is a significant challenge. And it's not a job that anyone
really wants to do -- so if you've the itch, the only person who will
scratch it is you. You'll need to do all this work yourself, and then
send your patches back to the DDD developers as a fait accompli, and
HOPE that they are ready to 'take the plunge', accept your patch, and
**force all of their developers to switch to using the new autotools**.
It's that last bit that causes trouble. And until they accept the
patches and take the plunge, you'll have to maintain your changes
out-of-baseline. And keep reapplying-and-reautotooling each time you
update to a new version of DDD.
One thing to keep in mind: when doing this, it helps to keep your
patches in separate 'piles'. I usually keep a 'pre-autotool' set, which
are the changes to configure.in, Makefile.am's, acinclude.m4's, etc.
Then, there's the 'post-autotool' set, which are the changes to those
files which are automagically updated by re-running
autoconf/automake/libtoolize (I usually include a 'bootstrap' script as
part of my 'pre-autotool' pile-o-patches [*]). Then, there's the 'code'
set (changes to actual code), and the 'cygwin-packinging' set (stuff
that goes in <srcdir>/CYGWIN-PATCHES/ like cyg-specific README, .hint,
postinstall script, etc -- that the upstream maintainers would NEVER be
interested in.)
[*] When actually releasing the cygwin package, there are two ways to do
this. The first way is to combine all four piles into one mondo patch,
and ship it as "the" patch for the package. (patchutils is your
friend). The downside is, often these patches are > 3M uncompressed,
thanks to the MASSIVE changes to the configure script, the
Makefile.in's, etc -- IOW, the 'post-autotool' pile-o-patches. The
second way is to only ship the pre-autotool, code, and cygwin-packaging
piles as the 'mondo' patch, and then adapt cygwin's
generic-packaging-script to run bootstrap as part of it's prep() phase.
This way, the patch is much smaller -- AND it's easier for you to
maintain. The downside is that (a) if anybody else wants to build your
version of the package, they must have the autotools installed, (b)
building is slow, because you have to run bootstrap each time [twice! --
again during mkpatch() for reasons I won't go into here -- if you're
interested, I can send one of my old packages where I had to do this,
and you can see how I did it and why. None of my current packages on
sourceware need to do this anymore...yay me.]
It's a royal pain...but there's no other choice, if (a) your-fav-pkg
won't compile properly on cygwin without modern autotool support, (b)
the upstream maintainers are unable/unwilling/properly-cautious to 'take
the plunge' and refuse to integrate your patches for a few release cycles.
>>configure.in:54: error: possibly undefined macro: AC_PROG_CC_GNU
>> If this token and others are legitimate, please use m4_pattern_allow.
>> See the Autoconf documentation.
>>configure.in:65: error: possibly undefined macro: AC_PROG_CC_G
>>configure.in:198: error: do not use LIBOBJS directly, use AC_LIBOBJ (see
>>section `AC_LIBOBJ vs LIBOBJS'
>>configure.in:310: error: possibly undefined macro: AC_PROG_CC_WORKS
>>autoreconf: /usr/autotool/devel/bin/autoconf failed with exit status: 1
>>
>
> So, if this hasn't left your tree broken, I think it would test what I
> wanted. You should now have libtool 1.5 for the main ddd tree. I think
> it would fix this.
But if the subtrees are configured separately AND the subtrees use
libtool, then each subtree will create its own libtool during its own
sub-configure step -- and you're back to the mixed-version problem
again. Blech.
> New in 1.5: 2002-04-14; CVS version 1.4e, Libtool team:
> * Support auto-import patch to binutils on cygwin for much improved dll
> support.
Yep.
--
Chuck
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: libtool created import libs broken? was RE: DDD 3.3.8 (i686-pc-cygwin) gets `Segmentation fault
2003-12-05 3:11 ` Charles Wilson
@ 2003-12-05 12:46 ` Arnaud Desitter
0 siblings, 0 replies; 20+ messages in thread
From: Arnaud Desitter @ 2003-12-05 12:46 UTC (permalink / raw)
To: Charles Wilson; +Cc: bug-ddd, cygwin-xfree
Hi,
Points taken. ddd requires autoconf 2.5x. It may well be that more work
is needed in the configure machinery to make it work with the most recent
versions of the autotools. Patches are welcome. For instance,
ddd/acconfig.h should be converted. Again any help is welcome.
An additional problem is that libiberty is bundled but has not been
converted yet to autoconf 2.5x. This causes problems but there is not
much we can do at the moment (except not using it in the first place).
The ddd cvs repository lives at http://sourceforge.net/projects/ddd/.
Patches posted at ddd@gnu.org will be considered.
Best regards,
----- Original Message -----
From: "Charles Wilson" <cygwin@cwilson.fastmail.fm>
Newsgroups:
gmane.os.cygwin,gmane.os.cygwin.xfree,gmane.comp.debugging.ddd.bugs
Cc: <bug-ddd@gnu.org>; <cygwin@cygwin.com>
Sent: Friday, December 05, 2003 3:13 AM
Subject: Re: libtool created import libs broken? was RE: DDD 3.3.8
(i686-pc-cygwin) gets `Segmentation fault
> Brian Ford wrote:
> > Charles Wilson,
> >
> > Could you look at the problem discovered in the thread below and give us
a
> > comment? Thanks.
> >
> > http://www.cygwin.com/ml/cygwin-xfree/2003-12/msg00053.html
>
> There are a couple of problems.
>
> 1) OOB, DDD uses libtool-1.4.2 -- which has very minimal support for
> cygwin. It works (barely) -- and it takes a whole chapter in the
> autobook http://sources.redhat.com/autobook/ to explain the differences
> from "normal" unix shared lib creation. The new 1.5+ procedure (with
> binutils/gcc autoimport, autoexport, and .dll.a naming convention
> support) is much more unix-like. Although ltmodules don't seem to work
> very well, except in toy cases. :-(
>
> 2) Old libtool, when it finds a .la file (which specifies the DLL
> name and the static lib name, AND the import lib name) doesn't appear to
> handle the implib properly -- it thinks that it does not exist, and
> attempts to recreate it from scratch using the export table from the
> DLL. But it uses old, buggy, obsolete, unmaintained, code to do so.
>
> Now, there are only four libraries in your link list that have .la
> files: expat, fontconfig, freetype, and Xm. And whaddaya know -- those
> are precisely the libs that cause problems in your link command.
>
> QuickNDirty answer: hide those four .la files and re-run configure.
>
> Long answer: update to the most recent autotools (relibtoolize).
> However....
>
> >>bash-2.05b$ autoreconf --install --force
> >
> >
> > These are just warnings, so I think this part worked fine. I guess the
> > ddd people should clean these up?
> >
>
> Yes, they should -- when they are ready to move to autoconf-2.5x,
> automake-1.7.x, and libtool-1.5+. But as you can see, there are
> incompatibilities between autoconf-2.13 and -2.5x. Basically, you CAN
> write a configure.in file that works with both -- but 2.13 was much more
> forgiving than 2.5x, so most existing configure.in's need to be brought
> up to 'spec' in order to work with 2.5x.
>
> And the _easiest_ way to do THAT is to make changes to the configure.in
> that are NOT backwards compatible with 2.13! So, it's possible to allow
> both versions to work with your configure.in, but much harder than just
> upgrading in a non-backwards-compatible way.
>
> So most projects (like gcc/binutils until recently) have taken a
> wait-and-see approach to autoconf-2.5x. Which leaves us poor cygwin
> folks, who NEED libtool-1.5 for decent DLL support, out in the cold --
> because libtool-1.5 requires automake-1.7.x which requires
autoconf-2.5x...
>
> (And, even though it is conceivable to use ac-2.5x with old-style
> automake-1.4p6, the cygwin wrapper system doesn't let you do that. So,
> if you re-autoconf with ac-2.5x, you'll also need to re-automake with
> am-1.[67].x -- which brings its own share of possible incompatibilities
> in the Makefile.am's. And you'll want to add -no-undefined to the
> libXXXXX_LDFLAGS setting for any libraries that DDD builds)
>
> >>configure.ac:248: warning: AC_CANONICAL_HOST invoked multiple times
> >>autoconf/specific.m4:363: AC_CYGWIN is expanded from...
> >>configure.ac:248: the top level
> >>autoheader: WARNING: Using auxiliary files such as `acconfig.h',
> >>`config.h.bot'
> >>autoheader: WARNING: and `config.h.top', to define templates for
> >>`config.h.in'
> >>autoheader: WARNING: is deprecated and discouraged.
> >>autoheader:
> >>autoheader: WARNING: Using the third argument of `AC_DEFINE' and
> >>autoheader: WARNING: `AC_DEFINE_UNQUOTED' allows to define a template
> >>without
> >>autoheader: WARNING: `acconfig.h':
> >>autoheader:
> >>autoheader: WARNING: AC_DEFINE([NEED_FUNC_MAIN], 1,
> >>autoheader: [Define if a function `main' is needed.])
> >>autoheader:
> >>autoheader: WARNING: More sophisticated templates can also be produced,
see
> >>the
> >>autoheader: WARNING: documentation.
>
> Yep, you're gonna have to take care of this stuff by hand. I believe
> that support for config.h.top etc will be going away in autoconf-2.60,
> but that's **just** a guess. And anyway, 2.60 isn't expected for at
> least several months (and 2.59 won't go 'poof' then, anyway)
>
> > Here is where we should have stopped, although I don't know how to do
> > that with autoreconf. The following are errors from subdirectories that
> > use older (circa 2.13) autoconf scripts. autoreconf does not support
> > mixed versions, I guess?
>
> No, not at all. That's why Zack Weinberg (Nathaniel Nerode?) over on
> the gcc list are updating gcc's (and friends') configure.in's by hand,
> one directory at a time.
>
> Bringing the autotool infrastructure up to snuff for a large project,
> like DDD, is a significant challenge. And it's not a job that anyone
> really wants to do -- so if you've the itch, the only person who will
> scratch it is you. You'll need to do all this work yourself, and then
> send your patches back to the DDD developers as a fait accompli, and
> HOPE that they are ready to 'take the plunge', accept your patch, and
> **force all of their developers to switch to using the new autotools**.
>
> It's that last bit that causes trouble. And until they accept the
> patches and take the plunge, you'll have to maintain your changes
> out-of-baseline. And keep reapplying-and-reautotooling each time you
> update to a new version of DDD.
>
> One thing to keep in mind: when doing this, it helps to keep your
> patches in separate 'piles'. I usually keep a 'pre-autotool' set, which
> are the changes to configure.in, Makefile.am's, acinclude.m4's, etc.
> Then, there's the 'post-autotool' set, which are the changes to those
> files which are automagically updated by re-running
> autoconf/automake/libtoolize (I usually include a 'bootstrap' script as
> part of my 'pre-autotool' pile-o-patches [*]). Then, there's the 'code'
> set (changes to actual code), and the 'cygwin-packinging' set (stuff
> that goes in <srcdir>/CYGWIN-PATCHES/ like cyg-specific README, .hint,
> postinstall script, etc -- that the upstream maintainers would NEVER be
> interested in.)
>
> [*] When actually releasing the cygwin package, there are two ways to do
> this. The first way is to combine all four piles into one mondo patch,
> and ship it as "the" patch for the package. (patchutils is your
> friend). The downside is, often these patches are > 3M uncompressed,
> thanks to the MASSIVE changes to the configure script, the
> Makefile.in's, etc -- IOW, the 'post-autotool' pile-o-patches. The
> second way is to only ship the pre-autotool, code, and cygwin-packaging
> piles as the 'mondo' patch, and then adapt cygwin's
> generic-packaging-script to run bootstrap as part of it's prep() phase.
> This way, the patch is much smaller -- AND it's easier for you to
> maintain. The downside is that (a) if anybody else wants to build your
> version of the package, they must have the autotools installed, (b)
> building is slow, because you have to run bootstrap each time [twice! --
> again during mkpatch() for reasons I won't go into here -- if you're
> interested, I can send one of my old packages where I had to do this,
> and you can see how I did it and why. None of my current packages on
> sourceware need to do this anymore...yay me.]
>
> It's a royal pain...but there's no other choice, if (a) your-fav-pkg
> won't compile properly on cygwin without modern autotool support, (b)
> the upstream maintainers are unable/unwilling/properly-cautious to 'take
> the plunge' and refuse to integrate your patches for a few release cycles.
>
> >>configure.in:54: error: possibly undefined macro: AC_PROG_CC_GNU
> >> If this token and others are legitimate, please use
m4_pattern_allow.
> >> See the Autoconf documentation.
> >>configure.in:65: error: possibly undefined macro: AC_PROG_CC_G
> >>configure.in:198: error: do not use LIBOBJS directly, use AC_LIBOBJ (see
> >>section `AC_LIBOBJ vs LIBOBJS'
> >>configure.in:310: error: possibly undefined macro: AC_PROG_CC_WORKS
> >>autoreconf: /usr/autotool/devel/bin/autoconf failed with exit status: 1
> >>
> >
> > So, if this hasn't left your tree broken, I think it would test what I
> > wanted. You should now have libtool 1.5 for the main ddd tree. I think
> > it would fix this.
>
> But if the subtrees are configured separately AND the subtrees use
> libtool, then each subtree will create its own libtool during its own
> sub-configure step -- and you're back to the mixed-version problem
> again. Blech.
>
> > New in 1.5: 2002-04-14; CVS version 1.4e, Libtool team:
> > * Support auto-import patch to binutils on cygwin for much improved dll
> > support.
>
> Yep.
>
> --
> Chuck
>
>
>
>
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: DDD 3.3.8 (i686-pc-cygwin) gets `Segmentation fault WAS Re: c ompiling DDD
@ 2003-12-04 20:26 Richard Campbell
0 siblings, 0 replies; 20+ messages in thread
From: Richard Campbell @ 2003-12-04 20:26 UTC (permalink / raw)
To: 'cygwin-xfree@cygwin.com'
Almost. When I figure out the minimum number of changes, I'll repost, and
then test on
the current (3.3.8) build.
-Richard Campbell.
>Does this result in a working version of ddd? If so, I can package it
>up for Cygwin's setup.exe.
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: DDD 3.3.8 (i686-pc-cygwin) gets `Segmentation fault WAS Re: c ompiling DDD
@ 2003-12-04 20:24 Richard Campbell
0 siblings, 0 replies; 20+ messages in thread
From: Richard Campbell @ 2003-12-04 20:24 UTC (permalink / raw)
To: 'cygwin-xfree@cygwin.com'; +Cc: bug-ddd
bash ./configure --disable-static
Only got me halfway - if old_archive_from_expsyms_cmds has a value, it will
override the
"build_old_libs=no" option in libtool. Strange.
-Richard Campbell.
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: DDD 3.3.8 (i686-pc-cygwin) gets `Segmentation fault WAS Re: c ompiling DDD
@ 2003-12-04 20:09 Richard Campbell
2003-12-04 20:23 ` Harold L Hunt II
2003-12-04 21:09 ` Brian Ford
0 siblings, 2 replies; 20+ messages in thread
From: Richard Campbell @ 2003-12-04 20:09 UTC (permalink / raw)
To: 'cygwin-xfree@cygwin.com'; +Cc: bug-ddd
>What version of libtool is ddd-3.3.8 using?
Automatically generated by configure?
I reconfigured with:
bash ./configure --disable-static
And libtool now has the settings I had hoped for - I'm running a make now,
and I'm pretty confident that will work.
Which would boil my steps down to (for 3.3.7):
1. Remove all "#pragma interface" and "#pragma implementation" lines.
2. Configure with: "bash ./configure --disable-static".
3. Make as usual.
(For 3.3.8, add the following:
0. Copy gcc/include into libiberty/include, or whatever exactly Arnaud said
)
-Richard Campbell.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: DDD 3.3.8 (i686-pc-cygwin) gets `Segmentation fault WAS Re: c ompiling DDD
2003-12-04 20:09 Richard Campbell
@ 2003-12-04 20:23 ` Harold L Hunt II
2003-12-04 21:09 ` Brian Ford
1 sibling, 0 replies; 20+ messages in thread
From: Harold L Hunt II @ 2003-12-04 20:23 UTC (permalink / raw)
To: cygwin-xfree
Richard,
Richard Campbell wrote:
>>What version of libtool is ddd-3.3.8 using?
>
>
> Automatically generated by configure?
>
> I reconfigured with:
> bash ./configure --disable-static
>
> And libtool now has the settings I had hoped for - I'm running a make now,
> and I'm pretty confident that will work.
>
> Which would boil my steps down to (for 3.3.7):
>
> 1. Remove all "#pragma interface" and "#pragma implementation" lines.
> 2. Configure with: "bash ./configure --disable-static".
> 3. Make as usual.
>
> (For 3.3.8, add the following:
> 0. Copy gcc/include into libiberty/include, or whatever exactly Arnaud said
> )
Does this result in a working version of ddd? If so, I can package it
up for Cygwin's setup.exe.
Harold
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: DDD 3.3.8 (i686-pc-cygwin) gets `Segmentation fault WAS Re: c ompiling DDD
2003-12-04 20:09 Richard Campbell
2003-12-04 20:23 ` Harold L Hunt II
@ 2003-12-04 21:09 ` Brian Ford
1 sibling, 0 replies; 20+ messages in thread
From: Brian Ford @ 2003-12-04 21:09 UTC (permalink / raw)
To: cygwin-xfree; +Cc: bug-ddd
On Thu, 4 Dec 2003, Richard Campbell wrote:
> Brian Ford wrote:
> >What version of libtool is ddd-3.3.8 using?
> >
> Automatically generated by configure?
>
I checked. In ltmain.sh for ddd-3.3.8 it says VERSION=1.4.2. I don't
know what it was in 3.3.7. The latest is 1.5.
> >Does re-libtoolizing fix it?
> >
Could you try "autoreconf --install --force", re-configure, and report the
results? It would be nice to know if the latest autotools are still
broken.
Thanks.
--
Brian Ford
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
Phone: 314-551-8460
Fax: 314-551-8444
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: DDD 3.3.8 (i686-pc-cygwin) gets `Segmentation fault WAS Re: c ompiling DDD
@ 2003-12-04 19:52 Richard Campbell
2003-12-04 20:06 ` Brian Ford
0 siblings, 1 reply; 20+ messages in thread
From: Richard Campbell @ 2003-12-04 19:52 UTC (permalink / raw)
To: cygwin-xfree; +Cc: bug-ddd
>> Now, I guess, to try and walk back all of the automatic steps to figure
>> out why ddd ended up linking against that libimp-cygXm-2.a file.
>
>Credit or blame libtool for that.
Specifically, the following two settings:
# Whether or not to build static libraries.
build_old_libs=yes
# Create a temporary old-style archive to link instead of a shared archive.
old_archive_from_expsyms_cmds="\$DLLTOOL --as=\$AS --dllname \$soname --def
\$output_objdir/\$soname-def --output-lib \$output_objdir/\$newlib"
If commented out, everything works cleanly.
Now, the bizarre part of the generated libtool is the following:
# Whether or not to build shared libraries.
build_libtool_libs=yes
# Whether or not to build static libraries.
build_old_libs=yes
Why would you have both "shared" and "static" turned on?
Now, to configure, I suppose...
-Richard Campbell.
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: DDD 3.3.8 (i686-pc-cygwin) gets `Segmentation fault WAS Re: c ompiling DDD
2003-12-04 19:52 Richard Campbell
@ 2003-12-04 20:06 ` Brian Ford
0 siblings, 0 replies; 20+ messages in thread
From: Brian Ford @ 2003-12-04 20:06 UTC (permalink / raw)
To: cygwin-xfree; +Cc: bug-ddd
On Thu, 4 Dec 2003, Richard Campbell wrote:
> Arnaud Desitter wrote:
> >Richard Campbell wrote:
> >> Now, I guess, to try and walk back all of the automatic steps to figure
> >> out why ddd ended up linking against that libimp-cygXm-2.a file.
> >>
> >Credit or blame libtool for that.
> >
What version of libtool is ddd-3.3.8 using?
Does re-libtoolizing fix it?
When these two questions are answered, it is probably time to move this to
cygwin@cygwin.com or libtool@gnu.org where the Cygwin libtool experts are.
> Specifically, the following two settings:
>
> # Whether or not to build static libraries.
> build_old_libs=yes
>
> # Create a temporary old-style archive to link instead of a shared archive.
> old_archive_from_expsyms_cmds="\$DLLTOOL --as=\$AS --dllname \$soname --def
> \$output_objdir/\$soname-def --output-lib \$output_objdir/\$newlib"
>
> If commented out, everything works cleanly.
>
> Now, the bizarre part of the generated libtool is the following:
>
> # Whether or not to build shared libraries.
> build_libtool_libs=yes
>
> # Whether or not to build static libraries.
> build_old_libs=yes
>
> Why would you have both "shared" and "static" turned on?
>
To have the option of either, obviously. Some packages default this way
as a courtesy.
Static libs are useful when profiling, distributing binaries without
worrying about associated libs, etc.
--
Brian Ford
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
Phone: 314-551-8460
Fax: 314-551-8444
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: DDD 3.3.8 (i686-pc-cygwin) gets `Segmentation fault WAS Re: c ompiling DDD
@ 2003-12-04 18:13 Richard Campbell
0 siblings, 0 replies; 20+ messages in thread
From: Richard Campbell @ 2003-12-04 18:13 UTC (permalink / raw)
To: 'cygwin-xfree@cygwin.com'; +Cc: bug-ddd
>But first, I'll run that last g++ linking step for ddd after editing it to
>remove those .libs
>links.
Yep. The following edited line produces a segfaulting binary:
g++ -DNDEBUG -O2 -g -W -Wall -trigraphs -o ddd.exe ddd.o basename.o
compare.o cook.o cwd.o glob.o
<snip many lines of .o files>
UndoBuffer.o UndoBE.o WhatNextCB.o configinfo.o -L/usr/X11R6/lib
.libs/libimp-cygXm-2.a -lXft -lXrender .libs/libimp-cygfontconfig-1.a
.libs/libimp-cygfreetype-6.a -lz .libs/libimp-cygexpat-0.a -lXt -lXpm -lXp
-lXext -lX11 -lSM -lICE -lncurses -ly ../libiberty/libiberty.a -Wl,--rpath
-Wl,/usr/X11R6/lib -Wl,--rpath -Wl,/usr/X11R6/lib
And the following edited line produces a running (at least for simple test,
breakpoint, step
through, browse source, etc.) binary:
g++ -DNDEBUG -O2 -g -W -Wall -trigraphs -o ddd.exe ddd.o basename.o
compare.o cook.o cwd.o glob.o
<snip many lines of .o files>
UndoBuffer.o UndoBE.o WhatNextCB.o configinfo.o -L/usr/X11R6/lib -lXm -lXt
-lXpm -lXp -lXext -lX11 -lSM -lICE -lncurses -ly ../libiberty/libiberty.a
-Wl,--rpath -Wl,/usr/X11R6/lib -Wl,--rpath -Wl,/usr/X11R6/lib
That line, the bugged one anyway, was produced by libtool.
So the question becomes, what is libtool doing wrong?
Which will probably require shifting over to the main cygwin list and
delving into hideous
problems, but C'est la vie.
Thanks muchly, Arnaud.
-Richard Campbell.
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: DDD 3.3.8 (i686-pc-cygwin) gets `Segmentation fault WAS Re: c ompiling DDD
@ 2003-12-04 17:50 Richard Campbell
0 siblings, 0 replies; 20+ messages in thread
From: Richard Campbell @ 2003-12-04 17:50 UTC (permalink / raw)
To: cygwin-xfree; +Cc: bug-ddd
>So I guess that it should be something along the lines:
>gcc -Wall -I/usr/X11R6/include Xmcheck.c -L/usr/X11R6/lib
>.libs/libimp-cygXm-2.a
>using whather .libs/libimp-cygXm-2.a points to.
Ok, yeah, that seems to be the problem.
bash-2.05b$ gcc -Wall -I/usr/X11R6/include Xmcheck.c -L/usr/X11R6/lib -lXm
Info: resolving _xmUseVersion by linking to __imp__xmUseVersion
(auto-import)
bash-2.05b$ ./a.exe
xmUseVersion=2001 XmVersion=2001
bash-2.05b$ gcc -Wall -I/usr/X11R6/include Xmcheck.c -L/usr/X11R6/lib
ddd/.libs/libimp-cygXm-2.a
bash-2.05b$ ./a.exe
xmUseVersion=1089480191 XmVersion=2001
Now, I guess, to try and walk back all of the automatic steps to figure out
why ddd ended
up linking against that libimp-cygXm-2.a file.
But first, I'll run that last g++ linking step for ddd after editing it to
remove those .libs
links.
-Richard Campbell.
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: DDD 3.3.8 (i686-pc-cygwin) gets `Segmentation fault WAS Re: c ompiling DDD
@ 2003-12-04 16:54 Richard Campbell
0 siblings, 0 replies; 20+ messages in thread
From: Richard Campbell @ 2003-12-04 16:54 UTC (permalink / raw)
To: cygwin-xfree; +Cc: bug-ddd
>Please try on Cygwin:
>>cat Xmcheck.c
>#include <Xm/Xm.h>
>#include <stdio.h>
>int main(void){
> printf("xmUseVersion=%d XmVersion=%d\n",
> xmUseVersion, XmVersion);
> return 0;
>}
>>gcc -Wall -I/usr/X11R6/include Xmcheck.c -L/usr/X11R6/lib -lXm
>>./a.out
>xmUseVersion=2002 XmVersion=2002
>
>If it gives different numbers, there is a good chance that your lesstif
>library won't work properly.
bash-2.05b$ gcc -Wall -I/usr/X11R6/include Xmcheck.c -L/usr/X11R6/lib -lXm
Info: resolving _xmUseVersion by linking to __imp__xmUseVersion
(auto-import)
bash-2.05b$ ./a.exe
xmUseVersion=2001 XmVersion=2001
Same numbers.
-Richard Campbell.
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: DDD 3.3.8 (i686-pc-cygwin) gets `Segmentation fault WAS Re: c ompiling DDD
@ 2003-12-04 15:51 Richard Campbell
2003-12-04 15:59 ` Harold L Hunt II
0 siblings, 1 reply; 20+ messages in thread
From: Richard Campbell @ 2003-12-04 15:51 UTC (permalink / raw)
To: 'cygwin-xfree@cygwin.com'; +Cc: bug-ddd
>The problem is not with Cygwin's LessTif... the problem is in how DDD is
>detecting LessTif on Cygwin. It must be assuming that the file name for
>the import library with be of the format foo.a whereas the name is of
>the format foo.dll.a on Cygwin.
This would be detection inside the actual execution, then? The link step
is libtoolized and ends up being:
g++ -DNDEBUG -O2 -g -W -Wall -trigraphs -o ddd.exe ddd.o basename.o
compare.o cook.o cwd.o glob.o
<snip many more *.o files>
UndoBuffer.o UndoBE.o WhatNextCB.o configinfo.o -L/usr/X11R6/lib
.libs/libimp-cygXm-2.a -lXft -lXrender .libs/libimp-cygfontconfig-1.a
.libs/libimp-cygfreetype-6.a -lz .libs/libimp-cygexpat-0.a -lXaw -lXmu -lXt
-lXpm -lXp -lXext -lX11 -lSM -lICE -lncurses -ly ../libiberty/libiberty.a
-Wl,--rpath -Wl,/usr/X11R6/lib -Wl,--rpath -Wl,/usr/X11R6/lib
Which looks sorta automagic for the dlls, right?
-Richard Campbell.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: DDD 3.3.8 (i686-pc-cygwin) gets `Segmentation fault WAS Re: c ompiling DDD
2003-12-04 15:51 Richard Campbell
@ 2003-12-04 15:59 ` Harold L Hunt II
0 siblings, 0 replies; 20+ messages in thread
From: Harold L Hunt II @ 2003-12-04 15:59 UTC (permalink / raw)
To: cygwin-xfree; +Cc: bug-ddd
Richard Campbell wrote:
>>The problem is not with Cygwin's LessTif... the problem is in how DDD is
>>detecting LessTif on Cygwin. It must be assuming that the file name for
>>the import library with be of the format foo.a whereas the name is of
>>the format foo.dll.a on Cygwin.
>
>
> This would be detection inside the actual execution, then? The link step
> is libtoolized and ends up being:
>
> g++ -DNDEBUG -O2 -g -W -Wall -trigraphs -o ddd.exe ddd.o basename.o
> compare.o cook.o cwd.o glob.o
> <snip many more *.o files>
> UndoBuffer.o UndoBE.o WhatNextCB.o configinfo.o -L/usr/X11R6/lib
> .libs/libimp-cygXm-2.a -lXft -lXrender .libs/libimp-cygfontconfig-1.a
> .libs/libimp-cygfreetype-6.a -lz .libs/libimp-cygexpat-0.a -lXaw -lXmu -lXt
> -lXpm -lXp -lXext -lX11 -lSM -lICE -lncurses -ly ../libiberty/libiberty.a
> -Wl,--rpath -Wl,/usr/X11R6/lib -Wl,--rpath -Wl,/usr/X11R6/lib
>
> Which looks sorta automagic for the dlls, right?
I'm not an expert (or even a user of DDD), but it wouldn't be the first
time if I saw something detected incorrectly in configure (picking Motif
versus LessTif), followed by a clean compile, followed by a crash on
execution.
Remember, Motif and LessTif are supposed to have the same interface, so
code written for either should compile and link against the other, but
the code may not work (segfault). So, I would suspect that DDD's
configure is detecting Motif (or assuming Motif by default), compiling
some conditional segments for Motif instead of for LessTif (introducing
buggy code), followed by linking with LessTif (leading to a crash when
the code that works with Motif but not LessTif is run).
Again, this is speculation, but that is where I would be looking at the
moment.
Harold
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: DDD 3.3.8 (i686-pc-cygwin) gets `Segmentation fault WAS Re: c ompiling DDD
@ 2003-12-04 14:49 Richard Campbell
2003-12-04 15:49 ` Harold L Hunt II
0 siblings, 1 reply; 20+ messages in thread
From: Richard Campbell @ 2003-12-04 14:49 UTC (permalink / raw)
To: 'cygwin-xfree@cygwin.com'; +Cc: bug-ddd
>That is a bug in gcc on cygwin related to "#pragma interface".
>Please look for help on the cygwin mailing list.
Arnaud, the problem is with both "#pragma interface" and "#pragma
implementation".
http://www.cygwin.com/ml/cygwin/2003-07/msg00463.html
Guarding all "#pragma interface" and "#pragma implementation" calls with
ifndef __CYGWIN__
allows everything to compile cleanly - is this something that could be
applied to the main baseline?
>Modifying ddd/config.h will not help. There is a problem with the
>lesstif distribution on cygwin. See:
>http://www.lesstif.org/INSTALL.html
Is the following what you are referring to?
"On windows using Cygwin, U/WIN or Interix, LessTif must be built as
static libraries. Because, one of the biggest issues with X on Win32
is the moronic DLL format. Specifically - it is not possible to export
data from a Win32 DLL in a form that can be used to statically initialize
another global variable. Data access from a DLL requires at least one
pointer indirection, and hence executable code. This is why X11R6 doesn't
have DLLs for Xt/Xmu/Xaw (and Motif) on Win32."
If yes, these rules have been changing. Brian, isn't this what you
were specifically working on recently?
-Richard Campbell.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: DDD 3.3.8 (i686-pc-cygwin) gets `Segmentation fault WAS Re: c ompiling DDD
2003-12-04 14:49 Richard Campbell
@ 2003-12-04 15:49 ` Harold L Hunt II
2003-12-04 17:34 ` Arnaud Desitter
0 siblings, 1 reply; 20+ messages in thread
From: Harold L Hunt II @ 2003-12-04 15:49 UTC (permalink / raw)
To: cygwin-xfree; +Cc: bug-ddd
Richard Campbell wrote:
>>Modifying ddd/config.h will not help. There is a problem with the
>>lesstif distribution on cygwin. See:
>>http://www.lesstif.org/INSTALL.html
>
>
> Is the following what you are referring to?
>
> "On windows using Cygwin, U/WIN or Interix, LessTif must be built as
> static libraries. Because, one of the biggest issues with X on Win32
> is the moronic DLL format. Specifically - it is not possible to export
> data from a Win32 DLL in a form that can be used to statically initialize
> another global variable. Data access from a DLL requires at least one
> pointer indirection, and hence executable code. This is why X11R6 doesn't
> have DLLs for Xt/Xmu/Xaw (and Motif) on Win32."
>
> If yes, these rules have been changing. Brian, isn't this what you
> were specifically working on recently?
The statement in quotes above is now misleading and completely
incorrect. We are distributing *only* a shared version of LessTif on
Cygwin now. The various problems mentioned in the quote all have
work-arounds, some of which were already used by OS/2; we enabled those
work-arounds and adding one or two more of our own and the shared
LessTif library compiles and works fine now.
The problem is not with Cygwin's LessTif... the problem is in how DDD is
detecting LessTif on Cygwin. It must be assuming that the file name for
the import library with be of the format foo.a whereas the name is of
the format foo.dll.a on Cygwin.
Harold
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: DDD 3.3.8 (i686-pc-cygwin) gets `Segmentation fault WAS Re: c ompiling DDD
2003-12-04 15:49 ` Harold L Hunt II
@ 2003-12-04 17:34 ` Arnaud Desitter
2003-12-04 19:00 ` Harold L Hunt II
0 siblings, 1 reply; 20+ messages in thread
From: Arnaud Desitter @ 2003-12-04 17:34 UTC (permalink / raw)
To: cygwin-xfree, huntharo
----- Original Message -----
From: "Harold L Hunt II" <huntharo@msu.edu>
Newsgroups: gmane.os.cygwin.xfree,gmane.comp.debugging.ddd.bugs
Cc: <bug-ddd@gnu.org>
Sent: Thursday, December 04, 2003 3:49 PM
Subject: Re: DDD 3.3.8 (i686-pc-cygwin) gets `Segmentation fault WAS Re: c
ompiling DDD
> Richard Campbell wrote:
> >>http://www.lesstif.org/INSTALL.html
> >
> > "On windows using Cygwin, U/WIN or Interix, LessTif must be built as
> > static libraries. Because, one of the biggest issues with X on Win32
> > is the moronic DLL format. Specifically - it is not possible to export
> > data from a Win32 DLL in a form that can be used to statically
initialize
> > another global variable. Data access from a DLL requires at least one
> > pointer indirection, and hence executable code. This is why X11R6
doesn't
> > have DLLs for Xt/Xmu/Xaw (and Motif) on Win32."
> >
> > If yes, these rules have been changing. Brian, isn't this what you
> > were specifically working on recently?
>
> The statement in quotes above is now misleading and completely
> incorrect. We are distributing *only* a shared version of LessTif on
> Cygwin now. The various problems mentioned in the quote all have
> work-arounds, some of which were already used by OS/2; we enabled those
> work-arounds and adding one or two more of our own and the shared
> LessTif library compiles and works fine now.
>
Fill free to contact the lesstif guys to fix it.
Regards,
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: DDD 3.3.8 (i686-pc-cygwin) gets `Segmentation fault WAS Re: c ompiling DDD
2003-12-04 17:34 ` Arnaud Desitter
@ 2003-12-04 19:00 ` Harold L Hunt II
0 siblings, 0 replies; 20+ messages in thread
From: Harold L Hunt II @ 2003-12-04 19:00 UTC (permalink / raw)
To: Arnaud Desitter; +Cc: cygwin-xfree
Arnaud Desitter wrote:
>>>If yes, these rules have been changing. Brian, isn't this what you
>>>were specifically working on recently?
>>
>>The statement in quotes above is now misleading and completely
>>incorrect. We are distributing *only* a shared version of LessTif on
>>Cygwin now. The various problems mentioned in the quote all have
>>work-arounds, some of which were already used by OS/2; we enabled those
>>work-arounds and adding one or two more of our own and the shared
>>LessTif library compiles and works fine now.
>>
>
>
> Fill free to contact the lesstif guys to fix it.
>
> Regards,
Regards,
My bad... I'm just a clueless newbie to this whole open-source
development thingy majig.
Harold
^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2003-12-05 12:46 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-12-04 21:28 DDD 3.3.8 (i686-pc-cygwin) gets `Segmentation fault WAS Re: c ompiling DDD Richard Campbell
2003-12-04 23:54 ` libtool created import libs broken? was RE: DDD 3.3.8 (i686-pc-cygwin) gets `Segmentation fault Brian Ford
2003-12-05 3:11 ` Charles Wilson
2003-12-05 12:46 ` Arnaud Desitter
-- strict thread matches above, loose matches on Subject: below --
2003-12-04 20:26 DDD 3.3.8 (i686-pc-cygwin) gets `Segmentation fault WAS Re: c ompiling DDD Richard Campbell
2003-12-04 20:24 Richard Campbell
2003-12-04 20:09 Richard Campbell
2003-12-04 20:23 ` Harold L Hunt II
2003-12-04 21:09 ` Brian Ford
2003-12-04 19:52 Richard Campbell
2003-12-04 20:06 ` Brian Ford
2003-12-04 18:13 Richard Campbell
2003-12-04 17:50 Richard Campbell
2003-12-04 16:54 Richard Campbell
2003-12-04 15:51 Richard Campbell
2003-12-04 15:59 ` Harold L Hunt II
2003-12-04 14:49 Richard Campbell
2003-12-04 15:49 ` Harold L Hunt II
2003-12-04 17:34 ` Arnaud Desitter
2003-12-04 19:00 ` Harold L Hunt II
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).