Re: Bug: linking shared libraries on Cygwin results in undefined references to __stack_chck_guard for code compiled with -fstack-protector
Yaakov (Cygwin/X) wrote:
> Bug confirmed. When code is compiled with -fstack-protector{,-all},
> GCC "emits extra code to check for buffer overflows, such as stack
> smashing attacks". This extra code uses symbols from libssp, and
> therefore (at least) Cygwin's GCC specs contain:
>
> *link_ssp:
> %{fstack-protector|fstack-protector-all:-lssp_nonshared -lssp}
>
> Therefore, when libtool fails to pass -fstack-protector{,-all} at link
> stage, the link fails.
>
> Patch attached. (Yes, I have a copyright assignment on file.)
One problem: this doesn't help with CXX, as -nostdlib is used,
circumventing this spec. Why can't libtool leave these details to the
linker?
Yaakov
Cygwin Ports
Re: Rewrite manual intro to be gender-neutral.
On Sun, 6 Jun 2010, Ralf Wildenhues wrote:
I'm really confused now. Is there any specific formulation, sentence,
or something in the manual that my change made worse in any way? If you
think so, can you please point it out precisely, including a suggestion
on how to improve it? Your comment seems very general, and while I can
guess that in general, the transformation from third to second person
singular can be problematic, I fail to see why this should be the case
in this patch.
It seems to me that the term 'you' is first person in the context of
the person doing the reading.
In all autotools manuals, use of "you" is already abundant.
I can't help that.
The problem with trying to be sexually agnostic is that the english
language was never designed for it. Until very recent times, it was
accepted that 'he' also meant 'she' unless specifically mentioned
otherwise. ('she' becomes subordinate to 'he' due to the biblical
story of how woman was created from Adam's rib). The result becomes
clumsy text.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Rewrite manual intro to be gender-neutral.
Hallo Ralf, Bob, On Jun 6, 2010, at 11:45 PM, Ralf Wildenhues wrote: Hello Bob, * Bob Friesenhahn wrote on Sun, Jun 06, 2010 at 05:15:11PM CEST: On Sun, 6 Jun 2010, Ralf Wildenhues wrote: This mirrors a similar recent fix to automake.texi. Any technical reasons against this patch? The rest of the manual greps ok. Regardless of Gary's affirmation, I don't think that replacing 'he' with 'you' is suitable. 'He' and 'you' are not at all equivalent terms. I'm really confused now. Is there any specific formulation, sentence, or something in the manual that my change made worse in any way? In all autotools manuals, use of "you" is already abundant. Actually, in this and many other cases I consider the use of "you" to be better style for a technical manual, since it actively engages the reader in a conversation by talking to the directly. Cheers, -- Gary V. Vaughan (g...@gnu.org)
Re: Rewrite manual intro to be gender-neutral.
On 6/6/2010 11:15 AM, Bob Friesenhahn wrote: > Regardless of Gary's affirmation, I don't think that replacing 'he' with > 'you' is suitable. 'He' and 'you' are not at all equivalent terms. If > there are two people in a room and one of them is 'you' then the other > one may be 'he' or 'she' but is definitely not 'you'. If one is talking > about the past, then the gentle reader might still have been in > elementary school at the time (or the womb) and so it is not suitable to > use the term 'you'. Welcome to the wonderful world of political correctness. I was taught, and English grammars still concur, that in English -- even that version spoken on the western side of the pond -- the neuter gender is represented by the masculine. But that's not acceptable to the arbiters of PC, so we're left with circumlocutions like using "one" as a pronoun (which forces one to use the passive tense), he/she, his/hers, him/her, and new spellings like "womyn" and "herstory" ... or inappropriate and excessive use of the second person instead of the third. Gah. -- Chuck
Re: Rewrite manual intro to be gender-neutral.
Hello Bob, * Bob Friesenhahn wrote on Sun, Jun 06, 2010 at 05:15:11PM CEST: > On Sun, 6 Jun 2010, Ralf Wildenhues wrote: > > >This mirrors a similar recent fix to automake.texi. > >Any technical reasons against this patch? > >The rest of the manual greps ok. > > Regardless of Gary's affirmation, I don't think that replacing 'he' > with 'you' is suitable. 'He' and 'you' are not at all equivalent > terms. If there are two people in a room and one of them is 'you' > then the other one may be 'he' or 'she' but is definitely not 'you'. > If one is talking about the past, then the gentle reader might still > have been in elementary school at the time (or the womb) and so it > is not suitable to use the term 'you'. I'm really confused now. Is there any specific formulation, sentence, or something in the manual that my change made worse in any way? If you think so, can you please point it out precisely, including a suggestion on how to improve it? Your comment seems very general, and while I can guess that in general, the transformation from third to second person singular can be problematic, I fail to see why this should be the case in this patch. In all autotools manuals, use of "you" is already abundant. Thanks, Ralf > >--- a/doc/libtool.texi > >+++ b/doc/libtool.texi > >@@ -230,13 +230,13 @@ Platform quirks > >@node Introduction > >@chapter Introduction > > > >-In the past, if a source code package developer wanted to take advantage > >-of the power of shared libraries, he needed to write custom support code > >-for each platform on which his package ran. He also had to design a > >-configuration interface so that the package installer could choose what > >-sort of libraries were built. > >+In the past, if you were a source code package developer and wanted to > >+take advantage of the power of shared libraries, you needed to write > >+custom support code for each platform on which your package ran. You > >+also had to design a configuration interface so that the package > >+installer could choose what sort of libraries were built. > > > >-GNU Libtool simplifies the developer's job by encapsulating both the > >+GNU Libtool simplifies your job by encapsulating both the > >platform-specific dependencies, and the user interface, in a single > >script. GNU Libtool is designed so that the complete functionality of > >each host type is available via a generic interface, but nasty quirks
Re: Rewrite manual intro to be gender-neutral.
On Sun, 6 Jun 2010, Ralf Wildenhues wrote: This mirrors a similar recent fix to automake.texi. Any technical reasons against this patch? The rest of the manual greps ok. Regardless of Gary's affirmation, I don't think that replacing 'he' with 'you' is suitable. 'He' and 'you' are not at all equivalent terms. If there are two people in a room and one of them is 'you' then the other one may be 'he' or 'she' but is definitely not 'you'. If one is talking about the past, then the gentle reader might still have been in elementary school at the time (or the womb) and so it is not suitable to use the term 'you'. Bob Thanks, Ralf Rewrite manual intro to be gender-neutral. * doc/libtool.texi (Introduction): Use gender-neutral formulation when addressing developers. diff --git a/doc/libtool.texi b/doc/libtool.texi index bbc22f4..051aec3 100644 --- a/doc/libtool.texi +++ b/doc/libtool.texi @@ -230,13 +230,13 @@ Platform quirks @node Introduction @chapter Introduction -In the past, if a source code package developer wanted to take advantage -of the power of shared libraries, he needed to write custom support code -for each platform on which his package ran. He also had to design a -configuration interface so that the package installer could choose what -sort of libraries were built. +In the past, if you were a source code package developer and wanted to +take advantage of the power of shared libraries, you needed to write +custom support code for each platform on which your package ran. You +also had to design a configuration interface so that the package +installer could choose what sort of libraries were built. -GNU Libtool simplifies the developer's job by encapsulating both the +GNU Libtool simplifies your job by encapsulating both the platform-specific dependencies, and the user interface, in a single script. GNU Libtool is designed so that the complete functionality of each host type is available via a generic interface, but nasty quirks -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: [SCM] GNU Libtool branch, master, updated. v2.2.7b-4-gaa75582
I should have proof read this before sending it: On 6 Jun 2010, at 20:19, Gary V. Vaughan wrote: > It's a pity that m4sh hasn't caught on. I find it to be a very > pleasant and productive shell script development environment. I > don't know whether that's because the compilation phase is still > immature, or simply because it's buried so deep in the current > Autoconf/Libtool distributions that no one has noticed it? It > would be nice if we could find some means to fix that though. Swapping the first two sentences makes it parse properly I think: "I find m4sh to be a very pleasant and productive shell script development environment. It's a pity that it hasn't caught on. I don't know whether that's because the compilation phase is still immature, or simply because it's buried so deeply in the current Autoconf/Libtool distributions that no one has noticed it? It would be nice if we could find some means to fix that though." Cheers, -- Gary V. Vaughan (g...@gnu.org)
Re: [SCM] GNU Libtool branch, master, updated. v2.2.7b-4-gaa75582
Hallo Ralf, Eric, On 6 Jun 2010, at 19:46, Ralf Wildenhues wrote: > * Gary V. Vaughan wrote on Sun, Jun 06, 2010 at 02:13:35PM CEST: >> On Jun 6, 2010, at 6:38 PM, Ralf Wildenhues wrote: >>> I see the point in the factorization of the option parsing, and I have >>> to admit to not having tested or even looked in detail at these >>> changes >>> yet, but on a general note, shouldn't we either just use gnulib's >>> announce-gen if it is good enough for us? And if it isn't, >>> shouldn't we >>> try to get the improvements of your version into gnulib's, or even try >>> to get gnulib to adopt the libtool variant? >> >> In general, I agree. But personally, I despise perl, and even had I >> invested the effort in figuring out the correct string of >> punctuation to make gnulib's version of announce-gen work for our >> release process... I probably wouldn't have been able to read that >> code a week later. > > Yes, granted, but, err, I'm not sure how to phrase it, if Jim is > maintaining that code, and we can just use it, with possibly minor > changes, why shouldn't we do it and not worry much about the > implementation language? (Disclaimer: I haven't tested either so > far.) If you don't want to get into the business of doing this bit > of work, maybe somebody else can do that? Sure. When I rewrote announce-gen in a maintainable language ;-) it was because I thought it unseemly to ask Jim to change some aspects of his script for Libtool's use... and also because it was more fun and less time consuming for me to spend an evening writing a few hundred lines of shell code than dirtying my hands with perl, and then trying to shepherd that code into Jim's script while I could still understand it! Still, if someone else wants to backport and translate the m4sh differences back into gnulib's perl code, that seems like a net win to me, and we should at least consider adopting that canonical version back into Libtool. > The next question is orthogonal to the announce-gen one: > >> Anyway, perl rants aside, I think that alongside Autoconf's >> m4sh.m4sh might make a better home for getopt.m4sh? > > I don't know, possibly yes, although the code uses quite a bit of > libtool-specific details (like all the referenced func_* thingies), > and I must admit having a pretty hard time grasping the m4. > (I'm much easier with perl, but hey, that might be something I should > just live with. ;-) That's true. But all the func_* thingies are very low level, and provide a nice layer to write shell scripts over, so I suppose they too would be a useful addition to m4sh, and are entirely contained in general.m4sh. I'll admit that some refactoring is certainly desirable if adoption of that code into autoconf turns out to be the path we take. It bears mentioning that my original vision for m4-2.0 was to implement and ship much of m4sh there, with key parts rewritten as loadable modules to improve performance over the pure m4 version... and that autoconf-3.0 would be able to build on. In that case, getopt.m4sh and general.m4sh more properly belong in m4-2.0's m4sh, although I don't think that precludes a version of pure m4 getopt.m4sh/general.m4sh living inside autoconf-2.xx in the mean time. >> I'm not against the idea of replacing perl code in gnulib with m4sh >> code either, though I think it might be a hard sell considering that >> our announce-gen requires a bootstrap time "compilation" step to >> turn announce-gen.m4sh into announce-gen the runnable shell script. > > Yes, that sounds like a hard sell. It's a pity that m4sh hasn't caught on. I find it to be a very pleasant and productive shell script development environment. I don't know whether that's because the compilation phase is still immature, or simply because it's buried so deep in the current Autoconf/Libtool distributions that no one has noticed it? It would be nice if we could find some means to fix that though. >> Anyway, I'm not attached to holding on to any of these files in >> libtool.git if there are better homes for them elsewhere. So, what >> next? Should I propose getopt.m4sh to autoconf-patc...@gnu.org? > > If it can be separated from libtool details, it sounds like a viable > approach. Let me put Eric in Cc: to see if the Autoconf maintainer > opposes this idea, to avoid you possibly-unnecessary work. Good idea. Thanks. >> And >> if accepted, propose adoption of our getopt.m4sh using maintainer >> scripts into gnulib? > > I bet that'll still be a hard sell even then. ;-) Agreed. :'( Cheers, -- Gary V. Vaughan (g...@gnu.org)
Re: Rewrite manual intro to be gender-neutral.
Hallo Ralf, On 6 Jun 2010, at 18:24, Ralf Wildenhues wrote: > This mirrors a similar recent fix to automake.texi. > Any technical reasons against this patch? Looks good to me. Thanks! > The rest of the manual greps ok. > > Thanks, > Ralf > >Rewrite manual intro to be gender-neutral. > >* doc/libtool.texi (Introduction): Use gender-neutral >formulation when addressing developers. Cheers, -- Gary V. Vaughan (g...@gnu.org)
Re: [SCM] GNU Libtool branch, master, updated. v2.2.7b-4-gaa75582
Hi Gary, Eric, * Gary V. Vaughan wrote on Sun, Jun 06, 2010 at 02:13:35PM CEST: > On Jun 6, 2010, at 6:38 PM, Ralf Wildenhues wrote: > >I see the point in the factorization of the option parsing, and I have > >to admit to not having tested or even looked in detail at these > >changes > >yet, but on a general note, shouldn't we either just use gnulib's > >announce-gen if it is good enough for us? And if it isn't, > >shouldn't we > >try to get the improvements of your version into gnulib's, or even try > >to get gnulib to adopt the libtool variant? > > In general, I agree. But personally, I despise perl, and even had I > invested the effort in figuring out the correct string of > punctuation to make gnulib's version of announce-gen work for our > release process... I probably wouldn't have been able to read that > code a week later. Yes, granted, but, err, I'm not sure how to phrase it, if Jim is maintaining that code, and we can just use it, with possibly minor changes, why shouldn't we do it and not worry much about the implementation language? (Disclaimer: I haven't tested either so far.) If you don't want to get into the business of doing this bit of work, maybe somebody else can do that? The next question is orthogonal to the announce-gen one: > Anyway, perl rants aside, I think that alongside Autoconf's > m4sh.m4sh might make a better home for getopt.m4sh? I don't know, possibly yes, although the code uses quite a bit of libtool-specific details (like all the referenced func_* thingies), and I must admit having a pretty hard time grasping the m4. (I'm much easier with perl, but hey, that might be something I should just live with. ;-) > I'm not against the idea of replacing perl code in gnulib with m4sh > code either, though I think it might be a hard sell considering that > our announce-gen requires a bootstrap time "compilation" step to > turn announce-gen.m4sh into announce-gen the runnable shell script. Yes, that sounds like a hard sell. > Anyway, I'm not attached to holding on to any of these files in > libtool.git if there are better homes for them elsewhere. So, what > next? Should I propose getopt.m4sh to autoconf-patc...@gnu.org? If it can be separated from libtool details, it sounds like a viable approach. Let me put Eric in Cc: to see if the Autoconf maintainer opposes this idea, to avoid you possibly-unnecessary work. > And > if accepted, propose adoption of our getopt.m4sh using maintainer > scripts into gnulib? I bet that'll still be a hard sell even then. ;-) Cheers, Ralf
Re: [SCM] GNU Libtool branch, master, updated. v2.2.7b-4-gaa75582
Hallo Ralf, On Jun 6, 2010, at 6:38 PM, Ralf Wildenhues wrote: * Gary V. Vaughan wrote on Fri, Jun 04, 2010 at 07:50:31PM CEST: Provide an m4sh reimplementation of announce-gen. * libltdl/config/getopt.m4sh (M4SH_GETOPTS): New macro that takes a quoted m4 list of command line options to be parsed, and generates the shell code to parse those options and collect the results into appropriately named 'opt_xxx' shell variables. Also, add some private supporting macros, and improve the comments radically. * libltdl/config/announce-gen.m4sh: New file, to generate and optionally post (an enhancement over the gnulib perl script of the same name) a release announcement. * Makefile.maint (announce-gen): Build a new announce-gen script in the build directory, from the contents of libltdl/config/announce-gen.m4sh. * HACKING (Release Procedure): Update the instructions to use announce-gen. (Alpha release note template, Full release note template): Removed. I see the point in the factorization of the option parsing, and I have to admit to not having tested or even looked in detail at these changes yet, but on a general note, shouldn't we either just use gnulib's announce-gen if it is good enough for us? And if it isn't, shouldn't we try to get the improvements of your version into gnulib's, or even try to get gnulib to adopt the libtool variant? In general, I agree. But personally, I despise perl, and even had I invested the effort in figuring out the correct string of punctuation to make gnulib's version of announce-gen work for our release process... I probably wouldn't have been able to read that code a week later. Anyway, perl rants aside, I think that alongside Autoconf's m4sh.m4sh might make a better home for getopt.m4sh? I'm not against the idea of replacing perl code in gnulib with m4sh code either, though I think it might be a hard sell considering that our announce-gen requires a bootstrap time "compilation" step to turn announce-gen.m4sh into announce-gen the runnable shell script. I realize my reaction to an earlier suggestion of yours about this was a bit inconsistent with this statement now, sorry about that. A bit more general, how come things like clcommit, mailnotify, and announge-gen live in the Libtool package? They are not very specific to library handling. Well, we don't ship any of them, they are in git to help me with commiting and releasing. Clcommit.m4sh and mailnotify.sh originally came from cvs-utils, but have since diverged after we moved to git, and ut seems cvs-utils is now unmaintained (and not terribly useful in GNU projects nowadays anyway). What do you think? And yes, I don't mind leaving things as they are, this is just an observation. I realize you've just invested quite a bit of work on this. Only announce-gen.m4sh is brand new, getopt.m4sh has been on my hard drive in one for or another for quite a few years already. Anyway, I'm not attached to holding on to any of these files in libtool.git if there are better homes for them elsewhere. So, what next? Should I propose getopt.m4sh to autoconf-patc...@gnu.org? And if accepted, propose adoption of our getopt.m4sh using maintainer scripts into gnulib? Cheers, -- Gary V. Vaughan (g...@gnu.org)
Re: [SCM] GNU Libtool branch, master, updated. v2.2.7b-4-gaa75582
Hi Gary, * Gary V. Vaughan wrote on Fri, Jun 04, 2010 at 07:50:31PM CEST: > Provide an m4sh reimplementation of announce-gen. > > * libltdl/config/getopt.m4sh (M4SH_GETOPTS): New macro that takes > a quoted m4 list of command line options to be parsed, and > generates the shell code to parse those options and collect the > results into appropriately named 'opt_xxx' shell variables. Also, > add some private supporting macros, and improve the comments > radically. > * libltdl/config/announce-gen.m4sh: New file, to generate and > optionally post (an enhancement over the gnulib perl script of the > same name) a release announcement. > * Makefile.maint (announce-gen): Build a new announce-gen script > in the build directory, from the contents of > libltdl/config/announce-gen.m4sh. > * HACKING (Release Procedure): Update the instructions to use > announce-gen. > (Alpha release note template, Full release note template): > Removed. I see the point in the factorization of the option parsing, and I have to admit to not having tested or even looked in detail at these changes yet, but on a general note, shouldn't we either just use gnulib's announce-gen if it is good enough for us? And if it isn't, shouldn't we try to get the improvements of your version into gnulib's, or even try to get gnulib to adopt the libtool variant? I realize my reaction to an earlier suggestion of yours about this was a bit inconsistent with this statement now, sorry about that. A bit more general, how come things like clcommit, mailnotify, and announge-gen live in the Libtool package? They are not very specific to library handling. What do you think? And yes, I don't mind leaving things as they are, this is just an observation. I realize you've just invested quite a bit of work on this. Cheers, and thanks, Ralf
Rewrite manual intro to be gender-neutral.
This mirrors a similar recent fix to automake.texi. Any technical reasons against this patch? The rest of the manual greps ok. Thanks, Ralf Rewrite manual intro to be gender-neutral. * doc/libtool.texi (Introduction): Use gender-neutral formulation when addressing developers. diff --git a/doc/libtool.texi b/doc/libtool.texi index bbc22f4..051aec3 100644 --- a/doc/libtool.texi +++ b/doc/libtool.texi @@ -230,13 +230,13 @@ Platform quirks @node Introduction @chapter Introduction -In the past, if a source code package developer wanted to take advantage -of the power of shared libraries, he needed to write custom support code -for each platform on which his package ran. He also had to design a -configuration interface so that the package installer could choose what -sort of libraries were built. +In the past, if you were a source code package developer and wanted to +take advantage of the power of shared libraries, you needed to write +custom support code for each platform on which your package ran. You +also had to design a configuration interface so that the package +installer could choose what sort of libraries were built. -GNU Libtool simplifies the developer's job by encapsulating both the +GNU Libtool simplifies your job by encapsulating both the platform-specific dependencies, and the user interface, in a single script. GNU Libtool is designed so that the complete functionality of each host type is available via a generic interface, but nasty quirks
Re: [PATCH] Update and simplify all m4sh scripts to use latest getopt.m4sh.
Hallo Ralf, On 6 Jun 2010, at 16:50, Ralf Wildenhues wrote: > * Gary V. Vaughan wrote on Sat, Jun 05, 2010 at 11:08:47AM CEST: >> Itchy trigger finger. I meant to add: >> >> Okay to push? > > Well, the M4SH_GETOPTS part certainly is rather hard to read because of > those long lines and long indents. This part? I thought it much easier to read than the shell loop it replaces. Although it looks like git-format-patch messed up the tabstops in the version I posted. > +dnl SHORTLONG DEFAULT INIT > +dnl -- > +dnl There are several options supported below for backwards compatibility, > +dnl but which are not mentioned in the help. > +M4SH_GETOPTS( > + [C^!],[--carbon-copy], [], [], > + [F^!],[--from], [], [], > + [...@+],[--filename], [], [], > + [...@!],[--headers], [], [], > + [m+!],[--mime-type],[], [ > +case [$]1 in > + text/*) ;; > + */*) func_error "\`[$]1': only text/* mime-types supported" > + ;; > + *) func_error "invalid mime-type, \`[$]1'" > + exit_cmd=exit > + ;; > +esac], > + [n], [], [],[], > + [o!], [--output-file], [],[], > + [s^!],[--subject], [],[], > + [v], [--verbose], [],[], > + [], [--dry-run|--dryrun], [],[], Of course, that assumes that you can trust the implementation of M4SH_GETOPTS that I commited with announce-gen, and used to make the 2.2.8 release message. > Other than that, I don't actually > use either of those scripts for patch handling, so if the changes work > for you and others that use them ... I've used them successfully for the entire last round of patches and releases, so I'll take that as an implicit "okay" :) Cheers, -- Gary V. Vaughan (g...@gnu.org)
Re: [PATCH] Update and simplify all m4sh scripts to use latest getopt.m4sh.
Hi Gary, * Gary V. Vaughan wrote on Sat, Jun 05, 2010 at 11:08:47AM CEST: > Itchy trigger finger. I meant to add: > > Okay to push? Well, the M4SH_GETOPTS part certainly is rather hard to read because of those long lines and long indents. Other than that, I don't actually use either of those scripts for patch handling, so if the changes work for you and others that use them ... Cheers, Ralf > On Jun 5, 2010, at 11:45 AM, Gary V. Vaughan wrote: > > >* clcommit.m4sh, libltdl/config/mailnotify.m4sh: Rewrite option > >parsing loop over M4SH_GETOPTS macro, and adjust all clients of > >option variables to use generated option names.
