Bug 140791 - [PATCH] textproc/libtre: Fix build on systems where GCC stack protection was enabled for userland
Summary: [PATCH] textproc/libtre: Fix build on systems where GCC stack protection was ...
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: Normal Affects Only Me
Assignee: Brendan Fabeny
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-11-22 20:50 UTC by Mario Sergio Fujikawa Ferreira
Modified: 2010-08-08 23:13 UTC (History)
1 user (show)

See Also:


Attachments
libtre-0.7.6.patch (614 bytes, patch)
2009-11-22 20:50 UTC, Mario Sergio Fujikawa Ferreira
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Mario Sergio Fujikawa Ferreira freebsd_committer 2009-11-22 20:50:00 UTC
- Fix build on systems (FreeBSD 8+) where GCC stack protection (aka
  Propolice) was enabled for userland on src/share/mk/bsd.sys.mk
  (SVN rev 180012 on 2008-06-25 21:33:28Z by ru)
- For OSVERSION >= 800040, add -fstack-protector to LDFLAGS
Comment 1 Edwin Groothuis freebsd_committer 2009-11-22 20:50:22 UTC
Responsible Changed
From-To: freebsd-ports-bugs->lioux

Submitter has GNATS access (via the GNATS Auto Assign Tool)
Comment 2 Edwin Groothuis freebsd_committer 2009-11-22 20:50:24 UTC
Maintainer of textproc/libtre,

Please note that PR ports/140791 has just been submitted.

If it contains a patch for an upgrade, an enhancement or a bug fix
you agree on, reply to this email stating that you approve the patch
and a committer will take care of it.

The full text of the PR can be found at:
    http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/140791

-- 
Edwin Groothuis via the GNATS Auto Assign Tool
edwin@FreeBSD.org
Comment 3 Edwin Groothuis freebsd_committer 2009-11-22 20:50:26 UTC
State Changed
From-To: open->feedback

Awaiting maintainers feedback (via the GNATS Auto Assign Tool)
Comment 4 b. f. 2009-11-22 21:06:34 UTC
>
>  .include <bsd.port.pre.mk>
>
> +# Around the time GCC stack protection (aka Propolice) for userland
> +# was enabled on src/share/mk/bsd.sys.mk
> +# SVN rev 180012 on 2008-06-25 21:33:28Z by ru
> +.if ${OSVERSION} >= 800040
> +LDFLAGS+=	-fstack-protector
> +.endif


This is not how this ought to be done:

-- it will not help those who have added stack protection to their
CFLAGS on other versions of FreeBSD that support it; and
-- it will not please people that have removed stack-protection from
their CFLAGS in /etc/make.conf or another included Makefile, in order
to avoid performance penalties, or because they built their system
WITHOUT_SSP, or for whatever other reason.

Instead, you should add:

LDFLAGS+=${CFLAGS:M-fstack-protector*}

which ought to work for -fstack-protector-all as well as
-fstack-protector.  Because this applies to many ports, portmgr ought
to consider doing this globally, rather than on a per-port basis.
Unfortunately, right now many ports do not respect LDFLAGS and
CPPFLAGS.  There needs to be a big cleanup so that they do, not only
for changes like this, and the recent Fortran problems, but also
because more people are soon probably be going to use compilers other
than the base system compiler for many of their ports.  You should
revert the corresponding changes you have made to other ports, like
multimedia/x264.

Regards,
                  b.
Comment 5 b. f. 2009-11-22 22:12:56 UTC
On 11/22/09, b. f. <bf1783@googlemail.com> wrote:

.

>
> Instead, you should add:
>
> LDFLAGS+=${CFLAGS:M-fstack-protector*}
>

Sorry, the pattern ought to have been:

LDFLAGS+=${CFLAGS:M-f*stack-protector*}

which accounts for the case when the user may toggle stack-protection
off not by overwriting CFLAGS, but by appending -fno-stack-protector
to CFLAGS.

Another thing that ought to be considered when thinking about doing
this globally is whether a port uses a compiler to do linking, or
invokes the  linker directly, or uses both alternately.  The
appropriate flags may differ in each case.

Regards,
               b.
Comment 6 Mario Sergio Fujikawa Ferreira freebsd_committer 2009-11-22 22:51:12 UTC
b. f. wrote:
>>  .include <bsd.port.pre.mk>
>>
>> +# Around the time GCC stack protection (aka Propolice) for userland
>> +# was enabled on src/share/mk/bsd.sys.mk
>> +# SVN rev 180012 on 2008-06-25 21:33:28Z by ru
>> +.if ${OSVERSION} >= 800040
>> +LDFLAGS+=	-fstack-protector
>> +.endif
> 
> 
> This is not how this ought to be done:
> 
> -- it will not help those who have added stack protection to their
> CFLAGS on other versions of FreeBSD that support it; and
> 
> -- it will not please people that have removed stack-protection from
> their CFLAGS in /etc/make.conf or another included Makefile, in order
> to avoid performance penalties, or because they built their system
> WITHOUT_SSP, or for whatever other reason.
> 
> Instead, you should add:
> 
> LDFLAGS+=${CFLAGS:M-fstack-protector*}

	Actually, this does not work because I do not have -fstack-protector on 
my CFLAGS, yet it is required to correctly linking libtre.

	The thing is. libc was build with it because it is been enabled on 
bsd.sys.mk. Then, for some reason I am now aware of, libtre is been 
bitten by this.

> which ought to work for -fstack-protector-all as well as
> -fstack-protector.  Because this applies to many ports, portmgr ought
> to consider doing this globally, rather than on a per-port basis.
> Unfortunately, right now many ports do not respect LDFLAGS and
> CPPFLAGS.  There needs to be a big cleanup so that they do, not only
> for changes like this, and the recent Fortran problems, but also
> because more people are soon probably be going to use compilers other
> than the base system compiler for many of their ports.  You should
> revert the corresponding changes you have made to other ports, like
> multimedia/x264.

   I would like to get input from others. Perhaps, gerald. I am going to 
CC him on this one.

   I understand your concerns. For now, I have only touched net/mldonkey 
and multimedia/x264. Unless there is a better fix (I know there is ought 
to be a better one), I am keeping the fix because I need it to get the 
applications working.


   Regards,
     Mario Ferreira
Comment 7 b. f. 2009-11-23 01:14:49 UTC
On 11/22/09, Mario Sergio Fujikawa Ferreira <lioux@freebsd.org> wrote:
> b. f. wrote:

>
>    I would like to get input from others. Perhaps, gerald. I am going to
> CC him on this one.

Alexander Kabaev has been dealing with these issues in the base
system, so I have copied him.  Have you only encountered problems with
libtre and the other ports that you have mentioned?  If so,
considering the number of ports that link against the system C
library, this suggests that the problem has something to do with
features peculiar to these ports.  Are you using the WITH_PGO option
that you created?  I am unable to reproduce your problem on 9-CURRENT
amd64 r199626 or 9-CURRENT i386 r199624.  Can you post a log of the
build/installation failures?

>
>    I understand your concerns. For now, I have only touched net/mldonkey
> and multimedia/x264. Unless there is a better fix (I know there is ought
> to be a better one), I am keeping the fix because I need it to get the
> applications working.
>

You can easily use a per-port LDFLAGS in /etc/make.conf -- there is no
reason to impose the change on other users of -CURRENT:

.if${.CURDIR:M*/usr/ports/textproc/libtre*}
LDFLAGS+=-fstack-protector
.endif

etc.

Regards,
                  b.
Comment 8 kabaev 2009-11-23 03:26:28 UTC
On Mon, 23 Nov 2009 01:14:49 +0000
"b. f." <bf1783@googlemail.com> wrote:

> On 11/22/09, Mario Sergio Fujikawa Ferreira <lioux@freebsd.org> wrote:
> > b. f. wrote:
> 
> >
> >    I would like to get input from others. Perhaps, gerald. I am
> > going to CC him on this one.
> 
> Alexander Kabaev has been dealing with these issues in the base
> system, so I have copied him.  Have you only encountered problems with
> libtre and the other ports that you have mentioned?  If so,
> considering the number of ports that link against the system C
> library, this suggests that the problem has something to do with
> features peculiar to these ports.  Are you using the WITH_PGO option
> that you created?  I am unable to reproduce your problem on 9-CURRENT
> amd64 r199626 or 9-CURRENT i386 r199624.  Can you post a log of the
> build/installation failures?
> 
> >
> >    I understand your concerns. For now, I have only touched
> > net/mldonkey and multimedia/x264. Unless there is a better fix (I
> > know there is ought to be a better one), I am keeping the fix
> > because I need it to get the applications working.
> >
> 
> You can easily use a per-port LDFLAGS in /etc/make.conf -- there is no
> reason to impose the change on other users of -CURRENT:
> 
> .if${.CURDIR:M*/usr/ports/textproc/libtre*}
> LDFLAGS+=-fstack-protector
> .endif
> 
> etc.
> 
> Regards,
>                   b.

You do of course realize that copying anyone from the middle of
conversation without providing any context is pretty much useless,
right? What is that you wanted to ask me about exactly? Unfortunately,
I cannot figure that about just from the text above.

-- 
Alexander Kabaev
Comment 9 b. f. 2009-11-23 04:29:06 UTC
On 11/23/09, Alexander Kabaev <kabaev@gmail.com> wrote:
> On Mon, 23 Nov 2009 01:14:49 +0000
> "b. f." <bf1783@googlemail.com> wrote:
>
>> On 11/22/09, Mario Sergio Fujikawa Ferreira <lioux@freebsd.org> wrote:
>> > b. f. wrote:

> You do of course realize that copying anyone from the middle of
> conversation without providing any context is pretty much useless,
> right? What is that you wanted to ask me about exactly? Unfortunately,
> I cannot figure that about just from the text above.

Sorry, I thought you might take a look at the full thread at:

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=ports/140791

There are two questions:

1) what is the source of the problems described by lioux@ in the three
ports he has mentioned (we may need to wait for him to furnish more
information if others cannot reproduce the failures he reports);

and

2) how can we best accommodate the use of the stack protector in other
ports -- making the minimal changes that are necessary to handle
linking in both the case when it is used, and when it is not?
Comment 10 Mario Sergio Fujikawa Ferreira freebsd_committer 2009-11-24 00:36:44 UTC
b. f. wrote:
> ---------- Forwarded message ----------
> From: "b. f." <bf1783@googlemail.com>
> Date: Mon, 23 Nov 2009 04:27:00 +0000
> Subject: Re: ports/140791: [PATCH] textproc/libtre: Fix build on
> systems where GCC stack protection was enabled for userland
> To: Alexander Kabaev <kabaev@gmail.com>
>
> On 11/23/09, Alexander Kabaev <kabaev@gmail.com> wrote:
>> On Mon, 23 Nov 2009 01:14:49 +0000
>> "b. f." <bf1783@googlemail.com> wrote:
>>
>>> On 11/22/09, Mario Sergio Fujikawa Ferreira <lioux@freebsd.org> wrote:
>>>> b. f. wrote:
>
>> You do of course realize that copying anyone from the middle of
>> conversation without providing any context is pretty much useless,
>> right? What is that you wanted to ask me about exactly? Unfortunately,
>> I cannot figure that about just from the text above.
>
> Sorry, I thought you might take a look at the full thread at:
>
> http://www.FreeBSD.org/cgi/query-pr.cgi?pr=ports/140791
>
> There are two questions:
>
> 1) what is the source of the problems described by lioux@ in the three
> ports he has mentioned (we may need to wait for him to furnish more
> information if others cannot reproduce the failures he reports);
>
> and
>
> 2) how can we best accommodate the use of the stack protector in other
> ports -- making the minimal changes that are necessary to handle
> linking in both the case when it is used, and when it is not?

  I apologize for the delay but I was otherwise engaged with work. :(

  You can fetch all files mentioned below on a single package:
Comment 11 Mario Sergio Fujikawa Ferreira freebsd_committer 2009-11-24 00:36:44 UTC
   I apologize for the delay but I was otherwise engaged with work. :(

   You can fetch all files mentioned below on a single package:

http://people.freebsd.org/~lioux/stack_protector/stack_protector.tbz

   1) The list of affected ports so far (on my system that is, I haven't 
verified this elsewhere yet):
	1.1) mail/crm114
	1.2) multimedia/x264
	1.3) net-p2p/mldonkey
	1.4) textproc/libtre
	1.5) x11/yelp

   2) I was able to build all ports that was previously broken after the 
addition of LDFLAGS "fix".

   3) I backtracked my steps to produce a better report. It follows:
	3.1) mail/crm114
		3.1.1) Diagnostic: I can't build it with vanilla CFLAGS. Built without 
PGO.
		3.1.2) Broken build log:
http://people.freebsd.org/~lioux/stack_protector/crm114-broken-log.txt
		3.1.3) Broken build log snippet:

cc -I/usr/local/include -L/usr/local/lib -fprofile-generate 
-L/usr/local/lib -liconv -lintl crm_main.o crm_compiler.o 
crm_errorhandlers.o  crm_math_exec.o
crm_var_hash_table.o crm_expandvar.o  crm_stmt_parser.o 
crm_vector_tokenize.o  crm_expr_alter.o crm_expr_match.o 
crm_css_maintenance.o  crm_markovian.o crm
_osb_bayes.o crm_osb_hyperspace.o  crm_correlate.o crm_osb_winnow.o 
crm_winnow_maintenance.o  crm_osbf_bayes.o crm_osbf_maintenance.o 
crm_bit_entropy.o  cr
m_neural_net.o crm_expr_clump.o  crm_expr_window.o crm_expr_isolate.o 
crm_expr_file_io.o  crm_expr_syscall.o crm_expr_classify.o 
crm_expr_translate.o  crm_
exec_engine.o crm_debugger.o crm_str_funcs.o  crm_preprocessor.o 
crmregex_tre.c  crm_expr_sks.o crm_stats.o crm_expr_svm.o 
crm_fast_substring_compression.
o  -ltre -lm -o crm114
/usr/lib/libgcov.a(_gcov.o)(.text+0x1459): In function `gcov_exit':
: undefined reference to `__stack_chk_fail_local'

	3.2) textproc/libtre
		3.2.1) Diagnostic: it can be built with vanilla CFLAGS. However, it 
breaks with CFLAGS optimizations. Built without PGO.
		3.2.2) Build log:
http://people.freebsd.org/~lioux/stack_protector/libtre-works-log.txt
		3.2.2) Broken build log:
http://people.freebsd.org/~lioux/stack_protector/libtre-broken-log.txt
		3.2.3) When it breaks, it breaks during the configure phase. I a am 
providing the work directory for evaluation.
http://people.freebsd.org/~lioux/stack_protector/libtre__broken__work.tar.bz2

	3.3) net-p2p/mldonkey
		3.3.1) Diagnostic: my mistake. This port is not broken. It is just a 
matter of properly setting LDFLAGS.
		3.3.2) Build log:
http://people.freebsd.org/~lioux/stack_protector/mldonkey-works-log.txt
		3.3.2) Broken build log:
http://people.freebsd.org/~lioux/stack_protector/mldonkey-broken-log.txt

	3.4) multimedia/x264
		3.4.1) Diagnostic: it can be built with vanilla CFLAGS. However, it 
breaks with CFLAGS optimizations. Built without PGO.
		3.4.2) Build log:
http://people.freebsd.org/~lioux/stack_protector/x264-works-log.txt
		3.4.2) Broken build log:
http://people.freebsd.org/~lioux/stack_protector/x264-broken-log.txt
		3.4.3) Broken build log snippet:

cc -o x264 x264.o matroska.o muxers.o libx264.a -L/usr/local/lib 
-L/usr/local/lib -L/usr/X11R6/lib -lX11 -lm -pthread -lgpac -s 
-fprofile-generate
/usr/bin/ld.orig: warning: libm.so.3, needed by 
/usr/local/lib/libGL.so.1, may conflict with libm.so.5
/usr/bin/ld.orig: warning: libc.so.5, needed by 
/usr/local/lib/libGLcore.so.1, may conflict with libc.so.7
/usr/local/lib/compat/libc.so.5: warning: WARNING!  setkey(3) not 
present in the system!
/usr/local/lib/compat/libc.so.5: warning: warning: this program uses 
gets(), which is unsafe.
/usr/local/lib/compat/libc.so.5: warning: warning: mktemp() possibly 
used unsafely; consider using mkstemp()
/usr/local/lib/compat/libc.so.5: warning: WARNING!  des_setkey(3) not 
present in the system!
/usr/local/lib/compat/libc.so.5: warning: WARNING!  encrypt(3) not 
present in the system!
/usr/local/lib/compat/libc.so.5: warning: warning: tmpnam() possibly 
used unsafely; consider using mkstemp()
/usr/local/lib/compat/libc.so.5: warning: warning: this program uses 
f_prealloc(), which is not recommended.
/usr/local/lib/compat/libc.so.5: warning: WARNING!  des_cipher(3) not 
present in the system!
/usr/local/lib/compat/libc.so.5: warning: warning: tempnam() possibly 
used unsafely; consider using mkstemp()
/usr/lib/libgcov.a(_gcov.o)(.text+0x1459): In function `gcov_exit':
: undefined reference to `__stack_chk_fail_local'

	3.3) x11/yelp
		3.3.1) Diagnostic: I can't build it with vanilla CFLAGS.
		3.3.2) Broken build log:
http://people.freebsd.org/~lioux/stack_protector/yelp-broken-log.txt
		3.3.3) Broken build log snippet:

c++ -DORBIT2=1 -D_REENTRANT -D_THREAD_SAFE -I/usr/local/include/glib-2.0 
-I/usr/local/lib/glib-2.0/include -I/usr/local/include/gconf/2 
-I/usr/local/includ
e/orbit-2.0 -I/usr/local/include/dbus-1.0 
-I/usr/local/include/dbus-1.0/include 
-I/usr/local/include/gtk-unix-print-2.0 -I/usr/local/include/gtk-2.0 -I/usr
/local/include/atk-1.0 -I/usr/local/include/cairo 
-I/usr/local/include/pango-1.0 -I/usr/local/lib/gtk-2.0/include 
-I/usr/local/include -I/usr/local/include
/pixman-1 -I/usr/local/include/freetype2 
-I/usr/local/include/libglade-2.0 -I/usr/local/include/libxml2 
-I/usr/local/include/libgnome-2.0 -I/usr/local/incl
ude/gnome-vfs-2.0 -I/usr/local/lib/gnome-vfs-2.0/include 
-I/usr/local/include/libbonobo-2.0 
-I/usr/local/include/bonobo-activation-2.0 -I/usr/local/include
/libgnomeui-2.0 -I/usr/local/include/libart-2.0 
-I/usr/local/include/gnome-keyring-1 
-I/usr/local/include/libbonoboui-2.0 -I/usr/local/include/libgnomecanv
as-2.0 -I/usr/local/include/gail-1.0 
-I/usr/local/include/startup-notification-1.0 
-I/usr/local/include/rarian -fshort-wchar -I/usr/local/include/libxul/st
able -I/usr/local/include/nspr -fshort-wchar 
-I/usr/local/include/libxul/stable -I/usr/local/include/nspr 
-fshort-wchar -I/usr/local/include/libxul/unstabl
e -I/usr/local/include/nspr -fno-rtti -fshort-wchar -O2 -pipe 
-march=athlon-mp -fno-strict-aliasing -Wall -Wno-unused 
-Wno-ctor-dtor-privacy -Wno-non-virtu
al-dtor -O2 -pipe -march=athlon-mp -fno-strict-aliasing -o yelp 
yelp-Yelper.o yelp-yelp-base.o yelp-yelp-bookmarks.o yelp-yelp-debug.o 
yelp-yelp-error.o ye
lp-yelp-gecko-utils.o yelp-yelp-html.o yelp-yelp-io-channel.o 
yelp-yelp-settings.o yelp-yelp-utils.o yelp-yelp-window.o 
yelp-yelp-marshal.o yelp-yelp-main.
o yelp-yelp-print.o yelp-yelp-page.o yelp-yelp-transform.o 
yelp-yelp-gecko-services.o yelp-yelp-document.o yelp-yelp-toc.o 
yelp-yelp-docbook.o yelp-yelp-db
-print.o yelp-yelp-man-parser.o yelp-yelp-man.o yelp-yelp-info.o 
yelp-yelp-info-parser.o yelp-gtkentryaction.o yelp-yelp-search.o 
yelp-yelp-search-parser.o
  -pthread -Wl,-rpath -Wl,/usr/local/lib/libxul -pthread 
-L/usr/local/lib /usr/local/lib/libglade-2.0.so 
/usr/local/lib/libgnomeui-2.so /usr/local/lib/libg
nome-keyring.so /usr/local/lib/libbonoboui-2.so 
/usr/local/lib/libgnomecanvas-2.so /usr/local/lib/libgailutil.so 
/usr/local/lib/libgnome-2.so /usr/local/li
b/libgnomevfs-2.so -lssl -lcrypto /usr/local/lib/libavahi-glib.so 
/usr/local/lib/libavahi-client.so /usr/local/lib/libavahi-common.so 
-lssp -lutil /usr/loc
al/lib/libesd.so /usr/local/lib/libaudiofile.so 
/usr/local/lib/libpopt.so /usr/local/lib/libbonobo-2.so 
/usr/local/lib/libbonobo-activation.so /usr/local/l
ib/libORBitCosNaming-2.so /usr/local/lib/libart_lgpl_2.so 
/usr/local/lib/libgtk-x11-2.0.so /usr/local/lib/libgdk-x11-2.0.so 
/usr/local/lib/libatk-1.0.so /u
sr/local/lib/libgdk_pixbuf-2.0.so /usr/local/lib/libpangocairo-1.0.so 
/usr/local/lib/libgio-2.0.so /usr/local/lib/libXinerama.so 
/usr/local/lib/libXi.so /u
sr/local/lib/libXrandr.so /usr/local/lib/libXcursor.so 
/usr/local/lib/libXcomposite.so /usr/local/lib/libXext.so 
/usr/local/lib/libXdamage.so /usr/local/li
b/libpangoft2-1.0.so /usr/local/lib/libXfixes.so 
/usr/local/lib/libcairo.so /usr/local/lib/libpixman-1.so 
/usr/local/lib/libglitz.so -lpng /usr/local/lib/l
ibxcb-render-util.so /usr/local/lib/libxcb-render.so 
/usr/local/lib/libXrender.so /usr/local/lib/libpango-1.0.so 
/usr/local/lib/libfontconfig.so /usr/local
/lib/libfreetype.so /usr/local/lib/libexpat.so 
/usr/local/lib/libgconf-2.so /usr/local/lib/libORBit-2.so 
/usr/local/lib/libgthread-2.0.so /usr/local/lib/li
bgmodule-2.0.so /usr/local/lib/libexslt.so /usr/local/lib/libxslt.so 
/usr/local/lib/libgcrypt.so /usr/local/lib/libgpg-error.so 
/usr/local/lib/libxml2.so -
lm /usr/local/lib/libstartup-notification-1.so 
/usr/local/lib/libxcb-aux.so /usr/local/lib/libxcb-event.so 
/usr/local/lib/libxcb-atom.so /usr/local/lib/lib
dbus-glib-1.so /usr/local/lib/libdbus-1.so -pthread 
/usr/local/lib/libgobject-2.0.so /usr/local/lib/libglib-2.0.so -licui18n 
/usr/local/lib/libintl.so /usr
/local/lib/libiconv.so /usr/local/lib/libpcre.so 
/usr/local/lib/librarian.so -lz -lbz2 /usr/local/lib/libSM.so 
/usr/local/lib/libICE.so /usr/local/lib/libX
11.so /usr/local/lib/libxcb.so /usr/local/lib/libXau.so 
/usr/local/lib/libXdmcp.so -lrpcsvc -L/usr/local/lib/libxul/sdk/lib 
-L/usr/local/lib/libxul -lxpcom
glue_s -lxpcom -lplds4 -lplc4 -lnspr4 -L/usr/local/lib/libxul/sdk/bin 
-lxul   -Wl,--rpath -Wl,/usr/local/lib -Wl,--rpath -Wl,/usr/local/lib 
-Wl,--rpath -Wl
,/usr/local/lib/libxul
/usr/local/lib/libxul/sdk/lib/libxpcomglue_s.a(nsStringAPI.o)(.text+0xe89): 
In function `nsACString::AppendInt(int, int)':
: undefined reference to `__stack_chk_fail_local'
/usr/local/lib/libxul/sdk/lib/libxpcomglue_s.a(nsStringAPI.o)(.text+0x1422): 
In function `nsAString::AppendInt(int, int)':
: undefined reference to `__stack_chk_fail_local'
gmake[3]: *** [yelp] Error 1
gmake[3]: Leaving directory `/usr/ports/x11/yelp/work/yelp-2.26.0/src'
gmake[2]: *** [all] Error 2
gmake[2]: Leaving directory `/usr/ports/x11/yelp/work/yelp-2.26.0/src'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `/usr/ports/x11/yelp/work/yelp-2.26.0'
gmake: *** [all] Error 2
*** Error code 1

   4) It seems we can classify the broken builds as follows:
	4.1) Incorrect LDFLAGS.
		4.1.1) net-p2p/mldonkey
		4.1.2) Analysis: Human operator mistake. Problem solved.
	4.2) Vanilla CFLAGS, /usr/lib/libgcov.a linking problem
		4.2.1) mail/crm114
	4.3) Optimized CFLAGS, /usr/lib/libgcov.a linking problem
		4.3.1) multimedia/x264
	4.4) /usr/local/lib/libxul/sdk/lib/libxpcomglue_s.a linking problem
		4.4.1) x11/yelp
	4.5) Optimized CFLAGS.
		4.5.1) textproc/libtre

   5) How do we procceed?

	Regards,
		Mario Ferreira
Comment 12 b. f. 2009-11-24 01:31:44 UTC
I think that your 8.0-PRERELEASE includes:

http://svn.freebsd.org/changeset/base/198304

but not:

http://svn.freebsd.org/changeset/base/198471

which arose from similar problems:

http://lists.freebsd.org/pipermail/svn-src-all/2009-October/014724.html
http://lists.freebsd.org/pipermail/svn-src-all/2009-October/014726.html

Right? This probably accounts for 4.2 and 4.3, and it is likely that
there is a similar problem in the other cases.  I will look into it
when I have a moment. kan@ would know more about the details of a
r198471 MFC.

Regards,
                b.
Comment 13 Jeremy Messenger 2009-11-24 03:46:35 UTC
I share with your (b.f.) thought. It's why I wanted to hold on with this:  
http://www.freebsd.org/cgi/query-pr.cgi?pr=140789

I don't think (w/out check details about the stack protector) it's right  
way to put -fstack-protector in the every failure ports. Should be done by  
globally or whatever that is outside in cat/port/Makefile. But I will be  
able to check more details about the stack protector this week.

<snip of full details, thanks a lot that should help us understand what  
error you are getting>
>
>    5) How do we procceed?

I wonder too so far.

/me goes back to watch American football (the halftime should be done).

Cheers,
Mezz
-- 
mezz7@cox.net  -  mezz@FreeBSD.org
FreeBSD GNOME Team
http://www.FreeBSD.org/gnome/  -  gnome@FreeBSD.org
Comment 14 Mario Sergio Fujikawa Ferreira freebsd_committer 2009-11-24 23:11:47 UTC
b. f. wrote:
 > I think that your 8.0-PRERELEASE includes:
 >
 > http://svn.freebsd.org/changeset/base/198304
 >
 > but not:
 >
 > http://svn.freebsd.org/changeset/base/198471
 >
 > which arose from similar problems:
 >
 > http://lists.freebsd.org/pipermail/svn-src-all/2009-October/014724.html
 > http://lists.freebsd.org/pipermail/svn-src-all/2009-October/014726.html
 >
 > Right? This probably accounts for 4.2 and 4.3, and it is likely that
 > there is a similar problem in the other cases.  I will look into it
 > when I have a moment. kan@ would know more about the details of a
 > r198471 MFC.
 >
 > On 11/24/09, Mario Sergio Fujikawa Ferreira <lioux@freebsd.org> wrote:
 >> b. f. wrote:
 >>  > ---------- Forwarded message ----------
 >>  > From: "b. f." <bf1783@googlemail.com>
 >>  > Date: Mon, 23 Nov 2009 04:27:00 +0000
 >>  > Subject: Re: ports/140791: [PATCH] textproc/libtre: Fix build on
 >>  > systems where GCC stack protection was enabled for userland
 >>  > To: Alexander Kabaev <kabaev@gmail.com>
 >>  >
 >>  > On 11/23/09, Alexander Kabaev <kabaev@gmail.com> wrote:
 >>  >> On Mon, 23 Nov 2009 01:14:49 +0000
 >>  >> "b. f." <bf1783@googlemail.com> wrote:
 >>  >>
 >>  >>> On 11/22/09, Mario Sergio Fujikawa Ferreira <lioux@freebsd.org> 
wrote:
 >>  >>>> b. f. wrote:
 >>  >
 >>  >> You do of course realize that copying anyone from the middle of
 >>  >> conversation without providing any context is pretty much useless,
 >>  >> right? What is that you wanted to ask me about exactly? 
Unfortunately,
 >>  >> I cannot figure that about just from the text above.
 >>  >
 >>  > Sorry, I thought you might take a look at the full thread at:
 >>  >
 >>  > http://www.FreeBSD.org/cgi/query-pr.cgi?pr=ports/140791
 >>  >
 >>  > There are two questions:
 >>  >
 >>  > 1) what is the source of the problems described by lioux@ in the 
three
 >>  > ports he has mentioned (we may need to wait for him to furnish more
 >>  > information if others cannot reproduce the failures he reports);
 >>  >
 >>  > and
 >>  >
 >>  > 2) how can we best accommodate the use of the stack protector in 
other
 >>  > ports -- making the minimal changes that are necessary to handle
 >>  > linking in both the case when it is used, and when it is not?
 >>
 >>    I apologize for the delay but I was otherwise engaged with work. :(
 >>
 >>    You can fetch all files mentioned below on a single package:
 >>
 >> http://people.freebsd.org/~lioux/stack_protector/stack_protector.tbz
 >>
 >>    1) The list of affected ports so far (on my system that is, I haven't
 >> verified this elsewhere yet):
 >> 	1.1) mail/crm114
 >> 	1.2) multimedia/x264
 >> 	1.3) net-p2p/mldonkey
 >> 	1.4) textproc/libtre
 >> 	1.5) x11/yelp
 >>
 >>    2) I was able to build all ports that was previously broken after the
 >> addition of LDFLAGS "fix".
 >>
 >>    3) I backtracked my steps to produce a better report. It follows:
 >> 	3.1) mail/crm114
 >> 		3.1.1) Diagnostic: I can't build it with vanilla CFLAGS. Built without
 >> PGO.
 >> 		3.1.2) Broken build log:
 >> http://people.freebsd.org/~lioux/stack_protector/crm114-broken-log.txt
 >> 		3.1.3) Broken build log snippet:
 >>
 >> cc -I/usr/local/include -L/usr/local/lib -fprofile-generate
 >> -L/usr/local/lib -liconv -lintl crm_main.o crm_compiler.o
 >> crm_errorhandlers.o  crm_math_exec.o
 >> crm_var_hash_table.o crm_expandvar.o  crm_stmt_parser.o
 >> crm_vector_tokenize.o  crm_expr_alter.o crm_expr_match.o
 >> crm_css_maintenance.o  crm_markovian.o crm
 >> _osb_bayes.o crm_osb_hyperspace.o  crm_correlate.o crm_osb_winnow.o
 >> crm_winnow_maintenance.o  crm_osbf_bayes.o crm_osbf_maintenance.o
 >> crm_bit_entropy.o  cr
 >> m_neural_net.o crm_expr_clump.o  crm_expr_window.o crm_expr_isolate.o
 >> crm_expr_file_io.o  crm_expr_syscall.o crm_expr_classify.o
 >> crm_expr_translate.o  crm_
 >> exec_engine.o crm_debugger.o crm_str_funcs.o  crm_preprocessor.o
 >> crmregex_tre.c  crm_expr_sks.o crm_stats.o crm_expr_svm.o
 >> crm_fast_substring_compression.
 >> o  -ltre -lm -o crm114
 >> /usr/lib/libgcov.a(_gcov.o)(.text+0x1459): In function `gcov_exit':
 >> : undefined reference to `__stack_chk_fail_local'
 >>
 >> 	3.2) textproc/libtre
 >> 		3.2.1) Diagnostic: it can be built with vanilla CFLAGS. However, it
 >> breaks with CFLAGS optimizations. Built without PGO.
 >> 		3.2.2) Build log:
 >> http://people.freebsd.org/~lioux/stack_protector/libtre-works-log.txt
 >> 		3.2.2) Broken build log:
 >> http://people.freebsd.org/~lioux/stack_protector/libtre-broken-log.txt
 >> 		3.2.3) When it breaks, it breaks during the configure phase. I a am
 >> providing the work directory for evaluation.
 >> 
http://people.freebsd.org/~lioux/stack_protector/libtre__broken__work.tar.bz2
 >>
 >> 	3.3) net-p2p/mldonkey
 >> 		3.3.1) Diagnostic: my mistake. This port is not broken. It is just a
 >> matter of properly setting LDFLAGS.
 >> 		3.3.2) Build log:
 >> http://people.freebsd.org/~lioux/stack_protector/mldonkey-works-log.txt
 >> 		3.3.2) Broken build log:
 >> http://people.freebsd.org/~lioux/stack_protector/mldonkey-broken-log.txt
 >>
 >> 	3.4) multimedia/x264
 >> 		3.4.1) Diagnostic: it can be built with vanilla CFLAGS. However, it
 >> breaks with CFLAGS optimizations. Built without PGO.
 >> 		3.4.2) Build log:
 >> http://people.freebsd.org/~lioux/stack_protector/x264-works-log.txt
 >> 		3.4.2) Broken build log:
 >> http://people.freebsd.org/~lioux/stack_protector/x264-broken-log.txt
 >> 		3.4.3) Broken build log snippet:
 >>
 >> cc -o x264 x264.o matroska.o muxers.o libx264.a -L/usr/local/lib
 >> -L/usr/local/lib -L/usr/X11R6/lib -lX11 -lm -pthread -lgpac -s
 >> -fprofile-generate
 >> /usr/bin/ld.orig: warning: libm.so.3, needed by
 >> /usr/local/lib/libGL.so.1, may conflict with libm.so.5
 >> /usr/bin/ld.orig: warning: libc.so.5, needed by
 >> /usr/local/lib/libGLcore.so.1, may conflict with libc.so.7
 >> /usr/local/lib/compat/libc.so.5: warning: WARNING!  setkey(3) not
 >> present in the system!
 >> /usr/local/lib/compat/libc.so.5: warning: warning: this program uses
 >> gets(), which is unsafe.
 >> /usr/local/lib/compat/libc.so.5: warning: warning: mktemp() possibly
 >> used unsafely; consider using mkstemp()
 >> /usr/local/lib/compat/libc.so.5: warning: WARNING!  des_setkey(3) not
 >> present in the system!
 >> /usr/local/lib/compat/libc.so.5: warning: WARNING!  encrypt(3) not
 >> present in the system!
 >> /usr/local/lib/compat/libc.so.5: warning: warning: tmpnam() possibly
 >> used unsafely; consider using mkstemp()
 >> /usr/local/lib/compat/libc.so.5: warning: warning: this program uses
 >> f_prealloc(), which is not recommended.
 >> /usr/local/lib/compat/libc.so.5: warning: WARNING!  des_cipher(3) not
 >> present in the system!
 >> /usr/local/lib/compat/libc.so.5: warning: warning: tempnam() possibly
 >> used unsafely; consider using mkstemp()
 >> /usr/lib/libgcov.a(_gcov.o)(.text+0x1459): In function `gcov_exit':
 >> : undefined reference to `__stack_chk_fail_local'
 >>
 >> 	3.3) x11/yelp
 >> 		3.3.1) Diagnostic: I can't build it with vanilla CFLAGS.
 >> 		3.3.2) Broken build log:
 >> http://people.freebsd.org/~lioux/stack_protector/yelp-broken-log.txt
 >> 		3.3.3) Broken build log snippet:
 >>
 >> c++ -DORBIT2=1 -D_REENTRANT -D_THREAD_SAFE -I/usr/local/include/glib-2.0
 >> -I/usr/local/lib/glib-2.0/include -I/usr/local/include/gconf/2
 >> -I/usr/local/includ
 >> e/orbit-2.0 -I/usr/local/include/dbus-1.0
 >> -I/usr/local/include/dbus-1.0/include
 >> -I/usr/local/include/gtk-unix-print-2.0 -I/usr/local/include/gtk-2.0 
-I/usr
 >> /local/include/atk-1.0 -I/usr/local/include/cairo
 >> -I/usr/local/include/pango-1.0 -I/usr/local/lib/gtk-2.0/include
 >> -I/usr/local/include -I/usr/local/include
 >> /pixman-1 -I/usr/local/include/freetype2
 >> -I/usr/local/include/libglade-2.0 -I/usr/local/include/libxml2
 >> -I/usr/local/include/libgnome-2.0 -I/usr/local/incl
 >> ude/gnome-vfs-2.0 -I/usr/local/lib/gnome-vfs-2.0/include
 >> -I/usr/local/include/libbonobo-2.0
 >> -I/usr/local/include/bonobo-activation-2.0 -I/usr/local/include
 >> /libgnomeui-2.0 -I/usr/local/include/libart-2.0
 >> -I/usr/local/include/gnome-keyring-1
 >> -I/usr/local/include/libbonoboui-2.0 -I/usr/local/include/libgnomecanv
 >> as-2.0 -I/usr/local/include/gail-1.0
 >> -I/usr/local/include/startup-notification-1.0
 >> -I/usr/local/include/rarian -fshort-wchar -I/usr/local/include/libxul/st
 >> able -I/usr/local/include/nspr -fshort-wchar
 >> -I/usr/local/include/libxul/stable -I/usr/local/include/nspr
 >> -fshort-wchar -I/usr/local/include/libxul/unstabl
 >> e -I/usr/local/include/nspr -fno-rtti -fshort-wchar -O2 -pipe
 >> -march=athlon-mp -fno-strict-aliasing -Wall -Wno-unused
 >> -Wno-ctor-dtor-privacy -Wno-non-virtu
 >> al-dtor -O2 -pipe -march=athlon-mp -fno-strict-aliasing -o yelp
 >> yelp-Yelper.o yelp-yelp-base.o yelp-yelp-bookmarks.o yelp-yelp-debug.o
 >> yelp-yelp-error.o ye
 >> lp-yelp-gecko-utils.o yelp-yelp-html.o yelp-yelp-io-channel.o
 >> yelp-yelp-settings.o yelp-yelp-utils.o yelp-yelp-window.o
 >> yelp-yelp-marshal.o yelp-yelp-main.
 >> o yelp-yelp-print.o yelp-yelp-page.o yelp-yelp-transform.o
 >> yelp-yelp-gecko-services.o yelp-yelp-document.o yelp-yelp-toc.o
 >> yelp-yelp-docbook.o yelp-yelp-db
 >> -print.o yelp-yelp-man-parser.o yelp-yelp-man.o yelp-yelp-info.o
 >> yelp-yelp-info-parser.o yelp-gtkentryaction.o yelp-yelp-search.o
 >> yelp-yelp-search-parser.o
 >>   -pthread -Wl,-rpath -Wl,/usr/local/lib/libxul -pthread
 >> -L/usr/local/lib /usr/local/lib/libglade-2.0.so
 >> /usr/local/lib/libgnomeui-2.so /usr/local/lib/libg
 >> nome-keyring.so /usr/local/lib/libbonoboui-2.so
 >> /usr/local/lib/libgnomecanvas-2.so /usr/local/lib/libgailutil.so
 >> /usr/local/lib/libgnome-2.so /usr/local/li
 >> b/libgnomevfs-2.so -lssl -lcrypto /usr/local/lib/libavahi-glib.so
 >> /usr/local/lib/libavahi-client.so /usr/local/lib/libavahi-common.so
 >> -lssp -lutil /usr/loc
 >> al/lib/libesd.so /usr/local/lib/libaudiofile.so
 >> /usr/local/lib/libpopt.so /usr/local/lib/libbonobo-2.so
 >> /usr/local/lib/libbonobo-activation.so /usr/local/l
 >> ib/libORBitCosNaming-2.so /usr/local/lib/libart_lgpl_2.so
 >> /usr/local/lib/libgtk-x11-2.0.so /usr/local/lib/libgdk-x11-2.0.so
 >> /usr/local/lib/libatk-1.0.so /u
 >> sr/local/lib/libgdk_pixbuf-2.0.so /usr/local/lib/libpangocairo-1.0.so
 >> /usr/local/lib/libgio-2.0.so /usr/local/lib/libXinerama.so
 >> /usr/local/lib/libXi.so /u
 >> sr/local/lib/libXrandr.so /usr/local/lib/libXcursor.so
 >> /usr/local/lib/libXcomposite.so /usr/local/lib/libXext.so
 >> /usr/local/lib/libXdamage.so /usr/local/li
 >> b/libpangoft2-1.0.so /usr/local/lib/libXfixes.so
 >> /usr/local/lib/libcairo.so /usr/local/lib/libpixman-1.so
 >> /usr/local/lib/libglitz.so -lpng /usr/local/lib/l
 >> ibxcb-render-util.so /usr/local/lib/libxcb-render.so
 >> /usr/local/lib/libXrender.so /usr/local/lib/libpango-1.0.so
 >> /usr/local/lib/libfontconfig.so /usr/local
 >> /lib/libfreetype.so /usr/local/lib/libexpat.so
 >> /usr/local/lib/libgconf-2.so /usr/local/lib/libORBit-2.so
 >> /usr/local/lib/libgthread-2.0.so /usr/local/lib/li
 >> bgmodule-2.0.so /usr/local/lib/libexslt.so /usr/local/lib/libxslt.so
 >> /usr/local/lib/libgcrypt.so /usr/local/lib/libgpg-error.so
 >> /usr/local/lib/libxml2.so -
 >> lm /usr/local/lib/libstartup-notification-1.so
 >> /usr/local/lib/libxcb-aux.so /usr/local/lib/libxcb-event.so
 >> /usr/local/lib/libxcb-atom.so /usr/local/lib/lib
 >> dbus-glib-1.so /usr/local/lib/libdbus-1.so -pthread
 >> /usr/local/lib/libgobject-2.0.so /usr/local/lib/libglib-2.0.so -licui18n
 >> /usr/local/lib/libintl.so /usr
 >> /local/lib/libiconv.so /usr/local/lib/libpcre.so
 >> /usr/local/lib/librarian.so -lz -lbz2 /usr/local/lib/libSM.so
 >> /usr/local/lib/libICE.so /usr/local/lib/libX
 >> 11.so /usr/local/lib/libxcb.so /usr/local/lib/libXau.so
 >> /usr/local/lib/libXdmcp.so -lrpcsvc -L/usr/local/lib/libxul/sdk/lib
 >> -L/usr/local/lib/libxul -lxpcom
 >> glue_s -lxpcom -lplds4 -lplc4 -lnspr4 -L/usr/local/lib/libxul/sdk/bin
 >> -lxul   -Wl,--rpath -Wl,/usr/local/lib -Wl,--rpath -Wl,/usr/local/lib
 >> -Wl,--rpath -Wl
 >> ,/usr/local/lib/libxul
 >> 
/usr/local/lib/libxul/sdk/lib/libxpcomglue_s.a(nsStringAPI.o)(.text+0xe89):
 >> In function `nsACString::AppendInt(int, int)':
 >> : undefined reference to `__stack_chk_fail_local'
 >> 
/usr/local/lib/libxul/sdk/lib/libxpcomglue_s.a(nsStringAPI.o)(.text+0x1422):
 >> In function `nsAString::AppendInt(int, int)':
 >> : undefined reference to `__stack_chk_fail_local'
 >> gmake[3]: *** [yelp] Error 1
 >> gmake[3]: Leaving directory `/usr/ports/x11/yelp/work/yelp-2.26.0/src'
 >> gmake[2]: *** [all] Error 2
 >> gmake[2]: Leaving directory `/usr/ports/x11/yelp/work/yelp-2.26.0/src'
 >> gmake[1]: *** [all-recursive] Error 1
 >> gmake[1]: Leaving directory `/usr/ports/x11/yelp/work/yelp-2.26.0'
 >> gmake: *** [all] Error 2
 >> *** Error code 1
 >>
 >>    4) It seems we can classify the broken builds as follows:
 >> 	4.1) Incorrect LDFLAGS.
 >> 		4.1.1) net-p2p/mldonkey
 >> 		4.1.2) Analysis: Human operator mistake. Problem solved.
 >> 	4.2) Vanilla CFLAGS, /usr/lib/libgcov.a linking problem
 >> 		4.2.1) mail/crm114
 >> 	4.3) Optimized CFLAGS, /usr/lib/libgcov.a linking problem
 >> 		4.3.1) multimedia/x264
 >> 	4.4) /usr/local/lib/libxul/sdk/lib/libxpcomglue_s.a linking problem
 >> 		4.4.1) x11/yelp
 >> 	4.5) Optimized CFLAGS.
 >> 		4.5.1) textproc/libtre
 >>
 >>    5) How do we procceed?
 >>

	Applying

http://svn.freebsd.org/changeset/base/198471

to my 8_RELENG fixed 4.2, 4.3 and 4.5.

	4.4 remains the only problem. x11/yelp build still complains about 
www/libxul linking problem. I even recompiled libxul (with the gcov fix) 
prior to building yelp. This requires further investigation.

	3 out of 4 is not a bad score.

	Can we run a full ports cluster build with that patch added to 
8_RELENG? Just to make sure it does not disturb anything. If it works, 
this should be MFCed ASAP before 8-RELEASE.

	I would even suggest a OSVERSION bump to track this down IF we plan to 
do something automatic on bsd.port.mk. However, I suggest we just tell 
people to update their systems and let this one slide. bsd.port.mk 
should not be used for small-time-frame-wise patches, specially for a 
non-RELEASEd branch.

	There is still an issue though of adding automated support for 
stack-protect but this gets blurred by the fact we are considering a 
migration from gcc to llvm. Does llvm support such flags? Or, are they 
gcc centric?

	Regards,
		Mario Ferreira
Comment 15 Mario Sergio Fujikawa Ferreira freebsd_committer 2009-11-24 23:25:40 UTC
b. f. wrote:
> I think that your 8.0-PRERELEASE includes:
> 
> http://svn.freebsd.org/changeset/base/198304
> 
> but not:
> 
> http://svn.freebsd.org/changeset/base/198471
> 
> which arose from similar problems:
> 
> http://lists.freebsd.org/pipermail/svn-src-all/2009-October/014724.html
> http://lists.freebsd.org/pipermail/svn-src-all/2009-October/014726.html
> 
> Right? This probably accounts for 4.2 and 4.3, and it is likely that
> there is a similar problem in the other cases.  I will look into it
> when I have a moment. kan@ would know more about the details of a
> r198471 MFC.
> 
> Regards,
>                 b.
> 
> On 11/24/09, Mario Sergio Fujikawa Ferreira <lioux@freebsd.org> wrote:
>> b. f. wrote:
>>  > ---------- Forwarded message ----------
>>  > From: "b. f." <bf1783@googlemail.com>
>>  > Date: Mon, 23 Nov 2009 04:27:00 +0000
>>  > Subject: Re: ports/140791: [PATCH] textproc/libtre: Fix build on
>>  > systems where GCC stack protection was enabled for userland
>>  > To: Alexander Kabaev <kabaev@gmail.com>
>>  >
>>  > On 11/23/09, Alexander Kabaev <kabaev@gmail.com> wrote:
>>  >> On Mon, 23 Nov 2009 01:14:49 +0000
>>  >> "b. f." <bf1783@googlemail.com> wrote:
>>  >>
>>  >>> On 11/22/09, Mario Sergio Fujikawa Ferreira <lioux@freebsd.org> wrote:
>>  >>>> b. f. wrote:
>>  >
>>  >> You do of course realize that copying anyone from the middle of
>>  >> conversation without providing any context is pretty much useless,
>>  >> right? What is that you wanted to ask me about exactly? Unfortunately,
>>  >> I cannot figure that about just from the text above.
>>  >
>>  > Sorry, I thought you might take a look at the full thread at:
>>  >
>>  > http://www.FreeBSD.org/cgi/query-pr.cgi?pr=ports/140791
>>  >
>>  > There are two questions:
>>  >
>>  > 1) what is the source of the problems described by lioux@ in the three
>>  > ports he has mentioned (we may need to wait for him to furnish more
>>  > information if others cannot reproduce the failures he reports);
>>  >
>>  > and
>>  >
>>  > 2) how can we best accommodate the use of the stack protector in other
>>  > ports -- making the minimal changes that are necessary to handle
>>  > linking in both the case when it is used, and when it is not?
>>
>>    I apologize for the delay but I was otherwise engaged with work. :(
>>
>>    You can fetch all files mentioned below on a single package:
>>
>> http://people.freebsd.org/~lioux/stack_protector/stack_protector.tbz
>>
>>    1) The list of affected ports so far (on my system that is, I haven't
>> verified this elsewhere yet):
>> 	1.1) mail/crm114
>> 	1.2) multimedia/x264
>> 	1.3) net-p2p/mldonkey
>> 	1.4) textproc/libtre
>> 	1.5) x11/yelp
>>
>>    2) I was able to build all ports that was previously broken after the
>> addition of LDFLAGS "fix".
>>
>>    3) I backtracked my steps to produce a better report. It follows:
>> 	3.1) mail/crm114
>> 		3.1.1) Diagnostic: I can't build it with vanilla CFLAGS. Built without
>> PGO.
>> 		3.1.2) Broken build log:
>> http://people.freebsd.org/~lioux/stack_protector/crm114-broken-log.txt
>> 		3.1.3) Broken build log snippet:
>>
>> cc -I/usr/local/include -L/usr/local/lib -fprofile-generate
>> -L/usr/local/lib -liconv -lintl crm_main.o crm_compiler.o
>> crm_errorhandlers.o  crm_math_exec.o
>> crm_var_hash_table.o crm_expandvar.o  crm_stmt_parser.o
>> crm_vector_tokenize.o  crm_expr_alter.o crm_expr_match.o
>> crm_css_maintenance.o  crm_markovian.o crm
>> _osb_bayes.o crm_osb_hyperspace.o  crm_correlate.o crm_osb_winnow.o
>> crm_winnow_maintenance.o  crm_osbf_bayes.o crm_osbf_maintenance.o
>> crm_bit_entropy.o  cr
>> m_neural_net.o crm_expr_clump.o  crm_expr_window.o crm_expr_isolate.o
>> crm_expr_file_io.o  crm_expr_syscall.o crm_expr_classify.o
>> crm_expr_translate.o  crm_
>> exec_engine.o crm_debugger.o crm_str_funcs.o  crm_preprocessor.o
>> crmregex_tre.c  crm_expr_sks.o crm_stats.o crm_expr_svm.o
>> crm_fast_substring_compression.
>> o  -ltre -lm -o crm114
>> /usr/lib/libgcov.a(_gcov.o)(.text+0x1459): In function `gcov_exit':
>> : undefined reference to `__stack_chk_fail_local'
>>
>> 	3.2) textproc/libtre
>> 		3.2.1) Diagnostic: it can be built with vanilla CFLAGS. However, it
>> breaks with CFLAGS optimizations. Built without PGO.
>> 		3.2.2) Build log:
>> http://people.freebsd.org/~lioux/stack_protector/libtre-works-log.txt
>> 		3.2.2) Broken build log:
>> http://people.freebsd.org/~lioux/stack_protector/libtre-broken-log.txt
>> 		3.2.3) When it breaks, it breaks during the configure phase. I a am
>> providing the work directory for evaluation.
>> http://people.freebsd.org/~lioux/stack_protector/libtre__broken__work.tar.bz2
>>
>> 	3.3) net-p2p/mldonkey
>> 		3.3.1) Diagnostic: my mistake. This port is not broken. It is just a
>> matter of properly setting LDFLAGS.
>> 		3.3.2) Build log:
>> http://people.freebsd.org/~lioux/stack_protector/mldonkey-works-log.txt
>> 		3.3.2) Broken build log:
>> http://people.freebsd.org/~lioux/stack_protector/mldonkey-broken-log.txt
>>
>> 	3.4) multimedia/x264
>> 		3.4.1) Diagnostic: it can be built with vanilla CFLAGS. However, it
>> breaks with CFLAGS optimizations. Built without PGO.
>> 		3.4.2) Build log:
>> http://people.freebsd.org/~lioux/stack_protector/x264-works-log.txt
>> 		3.4.2) Broken build log:
>> http://people.freebsd.org/~lioux/stack_protector/x264-broken-log.txt
>> 		3.4.3) Broken build log snippet:
>>
>> cc -o x264 x264.o matroska.o muxers.o libx264.a -L/usr/local/lib
>> -L/usr/local/lib -L/usr/X11R6/lib -lX11 -lm -pthread -lgpac -s
>> -fprofile-generate
>> /usr/bin/ld.orig: warning: libm.so.3, needed by
>> /usr/local/lib/libGL.so.1, may conflict with libm.so.5
>> /usr/bin/ld.orig: warning: libc.so.5, needed by
>> /usr/local/lib/libGLcore.so.1, may conflict with libc.so.7
>> /usr/local/lib/compat/libc.so.5: warning: WARNING!  setkey(3) not
>> present in the system!
>> /usr/local/lib/compat/libc.so.5: warning: warning: this program uses
>> gets(), which is unsafe.
>> /usr/local/lib/compat/libc.so.5: warning: warning: mktemp() possibly
>> used unsafely; consider using mkstemp()
>> /usr/local/lib/compat/libc.so.5: warning: WARNING!  des_setkey(3) not
>> present in the system!
>> /usr/local/lib/compat/libc.so.5: warning: WARNING!  encrypt(3) not
>> present in the system!
>> /usr/local/lib/compat/libc.so.5: warning: warning: tmpnam() possibly
>> used unsafely; consider using mkstemp()
>> /usr/local/lib/compat/libc.so.5: warning: warning: this program uses
>> f_prealloc(), which is not recommended.
>> /usr/local/lib/compat/libc.so.5: warning: WARNING!  des_cipher(3) not
>> present in the system!
>> /usr/local/lib/compat/libc.so.5: warning: warning: tempnam() possibly
>> used unsafely; consider using mkstemp()
>> /usr/lib/libgcov.a(_gcov.o)(.text+0x1459): In function `gcov_exit':
>> : undefined reference to `__stack_chk_fail_local'
>>
>> 	3.3) x11/yelp
>> 		3.3.1) Diagnostic: I can't build it with vanilla CFLAGS.
>> 		3.3.2) Broken build log:
>> http://people.freebsd.org/~lioux/stack_protector/yelp-broken-log.txt
>> 		3.3.3) Broken build log snippet:
>>
>> c++ -DORBIT2=1 -D_REENTRANT -D_THREAD_SAFE -I/usr/local/include/glib-2.0
>> -I/usr/local/lib/glib-2.0/include -I/usr/local/include/gconf/2
>> -I/usr/local/includ
>> e/orbit-2.0 -I/usr/local/include/dbus-1.0
>> -I/usr/local/include/dbus-1.0/include
>> -I/usr/local/include/gtk-unix-print-2.0 -I/usr/local/include/gtk-2.0 -I/usr
>> /local/include/atk-1.0 -I/usr/local/include/cairo
>> -I/usr/local/include/pango-1.0 -I/usr/local/lib/gtk-2.0/include
>> -I/usr/local/include -I/usr/local/include
>> /pixman-1 -I/usr/local/include/freetype2
>> -I/usr/local/include/libglade-2.0 -I/usr/local/include/libxml2
>> -I/usr/local/include/libgnome-2.0 -I/usr/local/incl
>> ude/gnome-vfs-2.0 -I/usr/local/lib/gnome-vfs-2.0/include
>> -I/usr/local/include/libbonobo-2.0
>> -I/usr/local/include/bonobo-activation-2.0 -I/usr/local/include
>> /libgnomeui-2.0 -I/usr/local/include/libart-2.0
>> -I/usr/local/include/gnome-keyring-1
>> -I/usr/local/include/libbonoboui-2.0 -I/usr/local/include/libgnomecanv
>> as-2.0 -I/usr/local/include/gail-1.0
>> -I/usr/local/include/startup-notification-1.0
>> -I/usr/local/include/rarian -fshort-wchar -I/usr/local/include/libxul/st
>> able -I/usr/local/include/nspr -fshort-wchar
>> -I/usr/local/include/libxul/stable -I/usr/local/include/nspr
>> -fshort-wchar -I/usr/local/include/libxul/unstabl
>> e -I/usr/local/include/nspr -fno-rtti -fshort-wchar -O2 -pipe
>> -march=athlon-mp -fno-strict-aliasing -Wall -Wno-unused
>> -Wno-ctor-dtor-privacy -Wno-non-virtu
>> al-dtor -O2 -pipe -march=athlon-mp -fno-strict-aliasing -o yelp
>> yelp-Yelper.o yelp-yelp-base.o yelp-yelp-bookmarks.o yelp-yelp-debug.o
>> yelp-yelp-error.o ye
>> lp-yelp-gecko-utils.o yelp-yelp-html.o yelp-yelp-io-channel.o
>> yelp-yelp-settings.o yelp-yelp-utils.o yelp-yelp-window.o
>> yelp-yelp-marshal.o yelp-yelp-main.
>> o yelp-yelp-print.o yelp-yelp-page.o yelp-yelp-transform.o
>> yelp-yelp-gecko-services.o yelp-yelp-document.o yelp-yelp-toc.o
>> yelp-yelp-docbook.o yelp-yelp-db
>> -print.o yelp-yelp-man-parser.o yelp-yelp-man.o yelp-yelp-info.o
>> yelp-yelp-info-parser.o yelp-gtkentryaction.o yelp-yelp-search.o
>> yelp-yelp-search-parser.o
>>   -pthread -Wl,-rpath -Wl,/usr/local/lib/libxul -pthread
>> -L/usr/local/lib /usr/local/lib/libglade-2.0.so
>> /usr/local/lib/libgnomeui-2.so /usr/local/lib/libg
>> nome-keyring.so /usr/local/lib/libbonoboui-2.so
>> /usr/local/lib/libgnomecanvas-2.so /usr/local/lib/libgailutil.so
>> /usr/local/lib/libgnome-2.so /usr/local/li
>> b/libgnomevfs-2.so -lssl -lcrypto /usr/local/lib/libavahi-glib.so
>> /usr/local/lib/libavahi-client.so /usr/local/lib/libavahi-common.so
>> -lssp -lutil /usr/loc
>> al/lib/libesd.so /usr/local/lib/libaudiofile.so
>> /usr/local/lib/libpopt.so /usr/local/lib/libbonobo-2.so
>> /usr/local/lib/libbonobo-activation.so /usr/local/l
>> ib/libORBitCosNaming-2.so /usr/local/lib/libart_lgpl_2.so
>> /usr/local/lib/libgtk-x11-2.0.so /usr/local/lib/libgdk-x11-2.0.so
>> /usr/local/lib/libatk-1.0.so /u
>> sr/local/lib/libgdk_pixbuf-2.0.so /usr/local/lib/libpangocairo-1.0.so
>> /usr/local/lib/libgio-2.0.so /usr/local/lib/libXinerama.so
>> /usr/local/lib/libXi.so /u
>> sr/local/lib/libXrandr.so /usr/local/lib/libXcursor.so
>> /usr/local/lib/libXcomposite.so /usr/local/lib/libXext.so
>> /usr/local/lib/libXdamage.so /usr/local/li
>> b/libpangoft2-1.0.so /usr/local/lib/libXfixes.so
>> /usr/local/lib/libcairo.so /usr/local/lib/libpixman-1.so
>> /usr/local/lib/libglitz.so -lpng /usr/local/lib/l
>> ibxcb-render-util.so /usr/local/lib/libxcb-render.so
>> /usr/local/lib/libXrender.so /usr/local/lib/libpango-1.0.so
>> /usr/local/lib/libfontconfig.so /usr/local
>> /lib/libfreetype.so /usr/local/lib/libexpat.so
>> /usr/local/lib/libgconf-2.so /usr/local/lib/libORBit-2.so
>> /usr/local/lib/libgthread-2.0.so /usr/local/lib/li
>> bgmodule-2.0.so /usr/local/lib/libexslt.so /usr/local/lib/libxslt.so
>> /usr/local/lib/libgcrypt.so /usr/local/lib/libgpg-error.so
>> /usr/local/lib/libxml2.so -
>> lm /usr/local/lib/libstartup-notification-1.so
>> /usr/local/lib/libxcb-aux.so /usr/local/lib/libxcb-event.so
>> /usr/local/lib/libxcb-atom.so /usr/local/lib/lib
>> dbus-glib-1.so /usr/local/lib/libdbus-1.so -pthread
>> /usr/local/lib/libgobject-2.0.so /usr/local/lib/libglib-2.0.so -licui18n
>> /usr/local/lib/libintl.so /usr
>> /local/lib/libiconv.so /usr/local/lib/libpcre.so
>> /usr/local/lib/librarian.so -lz -lbz2 /usr/local/lib/libSM.so
>> /usr/local/lib/libICE.so /usr/local/lib/libX
>> 11.so /usr/local/lib/libxcb.so /usr/local/lib/libXau.so
>> /usr/local/lib/libXdmcp.so -lrpcsvc -L/usr/local/lib/libxul/sdk/lib
>> -L/usr/local/lib/libxul -lxpcom
>> glue_s -lxpcom -lplds4 -lplc4 -lnspr4 -L/usr/local/lib/libxul/sdk/bin
>> -lxul   -Wl,--rpath -Wl,/usr/local/lib -Wl,--rpath -Wl,/usr/local/lib
>> -Wl,--rpath -Wl
>> ,/usr/local/lib/libxul
>> /usr/local/lib/libxul/sdk/lib/libxpcomglue_s.a(nsStringAPI.o)(.text+0xe89):
>> In function `nsACString::AppendInt(int, int)':
>> : undefined reference to `__stack_chk_fail_local'
>> /usr/local/lib/libxul/sdk/lib/libxpcomglue_s.a(nsStringAPI.o)(.text+0x1422):
>> In function `nsAString::AppendInt(int, int)':
>> : undefined reference to `__stack_chk_fail_local'
>> gmake[3]: *** [yelp] Error 1
>> gmake[3]: Leaving directory `/usr/ports/x11/yelp/work/yelp-2.26.0/src'
>> gmake[2]: *** [all] Error 2
>> gmake[2]: Leaving directory `/usr/ports/x11/yelp/work/yelp-2.26.0/src'
>> gmake[1]: *** [all-recursive] Error 1
>> gmake[1]: Leaving directory `/usr/ports/x11/yelp/work/yelp-2.26.0'
>> gmake: *** [all] Error 2
>> *** Error code 1
>>
>>    4) It seems we can classify the broken builds as follows:
>> 	4.1) Incorrect LDFLAGS.
>> 		4.1.1) net-p2p/mldonkey
>> 		4.1.2) Analysis: Human operator mistake. Problem solved.
>> 	4.2) Vanilla CFLAGS, /usr/lib/libgcov.a linking problem
>> 		4.2.1) mail/crm114
>> 	4.3) Optimized CFLAGS, /usr/lib/libgcov.a linking problem
>> 		4.3.1) multimedia/x264
>> 	4.4) /usr/local/lib/libxul/sdk/lib/libxpcomglue_s.a linking problem
>> 		4.4.1) x11/yelp
>> 	4.5) Optimized CFLAGS.
>> 		4.5.1) textproc/libtre
>>
>>    5) How do we procceed?

	Applying

http://svn.freebsd.org/changeset/base/198471

to my 8_RELENG fixed 4.2, 4.3 and 4.5.

	4.4 remains the only problem. x11/yelp build still complains about the 
www/libxul linking problem. I even recompiled libxul (with the gcov fix) 
prior to building yelp. This requires further investigation. I do a 
recursive reinstall of all libxul dependencies to see if it helps.

	Anyway, 3 out of 4 is not a bad score.

	Can we run a full ports cluster build with that patch added to 
8_RELENG? Just to make sure it does not disturb anything. If it works, 
this should be MFCed ASAP before 8-RELEASE.

	I would even suggest a OSVERSION bump to track this down IF we plan to 
do something automatic on bsd.port.mk. However, I suggest we just tell 
people to update their systems and let this one slide. bsd.port.mk 
should not be used for small-time-frame-wise patches, specially for a 
non-RELEASEd branch.

	There is still an issue though of adding automated support for 
stack-protect but this gets blurred by the fact we are considering a 
migration from gcc to llvm. Does llvm support such flags? Or, are they 
gcc centric?

	Regards,
		Mario Ferreira
Comment 16 b. f. 2009-11-24 23:53:11 UTC
On 11/24/09, Mario Sergio Fujikawa Ferreira <lioux@freebsd.org> wrote:
> b. f. wrote:

>
> 	Applying
>
> http://svn.freebsd.org/changeset/base/198471
>
> to my 8_RELENG fixed 4.2, 4.3 and 4.5.
>
> 	4.4 remains the only problem. x11/yelp build still complains about
> www/libxul linking problem. I even recompiled libxul (with the gcov fix)
> prior to building yelp. This requires further investigation.
>

Yes.

...

>
> 	Can we run a full ports cluster build with that patch added to
> 8_RELENG? Just to make sure it does not disturb anything. If it works,
> this should be MFCed ASAP before 8-RELEASE.
>

I just asked re@ about the possibility of including this in 8.0, and
kib@ told me that they were unwilling to accept further changes before
the release, which should be occurring within the next few days.  He
referred the question of if and when r198471 would be merged to the
stable branch of 8 to kan@.  So either someone must persuade them to
change their position (quickly), or we must implement a workaround in
Ports.

...

>
> 	There is still an issue though of adding automated support for
> stack-protect but this gets blurred by the fact we are considering a
> migration from gcc to llvm. Does llvm support such flags? Or, are they
> gcc centric?

Even if llvm becomes the default base system compiler, gcc will still
be used for many Ports, so the issue will still have to be resolved.
I think that we need to perform the {C,CPP,LD}FLAGS clean-up, and add
the automated support for stack protection in LDFLAGS.  This ought to
be done anyway because of recent and probable upcoming
gcc/Fortran-related changes.  If llvm is used later, and chokes on the
flags, we can make them conditional on the value of CC.
Comment 17 Mario Sergio Fujikawa Ferreira freebsd_committer 2009-11-25 01:43:26 UTC
	I am going to Bcc: portmgr@ on this reply. I apologize if this was not 
appropriate. The complete mail thread can be found at:

http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/140791

b. f. wrote:
 > On 11/24/09, Mario Sergio Fujikawa Ferreira <lioux@freebsd.org> wrote:
 >> b. f. wrote:
 >
 >> 	Applying
 >>
 >> http://svn.freebsd.org/changeset/base/198471
 >>
 >> to my 8_RELENG fixed 4.2, 4.3 and 4.5.
 >>
 >> 	4.4 remains the only problem. x11/yelp build still complains about
 >> www/libxul linking problem. I even recompiled libxul (with the gcov fix)
 >> prior to building yelp. This requires further investigation.
 >>
 >>
 >> 	Can we run a full ports cluster build with that patch added to
 >> 8_RELENG? Just to make sure it does not disturb anything. If it works,
 >> this should be MFCed ASAP before 8-RELEASE.
 >>
 >
 > I just asked re@ about the possibility of including this in 8.0, and
 > kib@ told me that they were unwilling to accept further changes before
 > the release, which should be occurring within the next few days.  He
 > referred the question of if and when r198471 would be merged to the
 > stable branch of 8 to kan@.  So either someone must persuade them to
 > change their position (quickly), or we must implement a workaround in
 > Ports.

	The reason for such a hard stand from re@ is simple: this is not a "src 
show stopper". They will only hold the release for "show stoppers" at 
this point.

	However, although not a "ports show stopper", this is indeed a ports' 
issue.

	The situation is as follows: /usr/lib/libgcov.a from our base system is 
being linked with ProPolice symbols. Therefore, any binary that links to 
gcov will have to link to ProPolice symbols as well.

	Since ports are usually built with our base system gnu compiler 
toolchain, this issue affects ports.

	Follows, at the very least, a few considerations:

	1) The issue has to be fixed on src (MFC will happen before or after 
the RELEASE) since it originated there.

	2) What do we do IF it is not fixed before RELEASE? What do we do even 
IF it is fixed before the RELEASE? Do we cater for installations that 
are not following -STABLE (in between the breakage and the fix)?

#if (${OSVERSION} >= 800040 && ${OSVERSION} < _FIXVERSION_) && 
(__HEAD_AFFECTED_RANGE_VERSION_CHECK__)
# if ___SOME_CHECK_TO_SEE_IF_WE_ARE_USING_GCC___
LDFLAGS+=      -fstack-protector
# endif
#endif
## do you see the mess and ugliness?

	3) What is the impact of this issue? How many ports are been affected?

It seems that mostly non-vanilla CFLAGS usage (optimizations) is 
triggering the problem. Although, I am still trying to figure why 
x11/yelp is being affected (no non-vanilla CFLAGS there). How many 
affected ports are there? What are the current report levels on the 
build cluster for "undefined reference to `__stack_chk_fail_local'" errors?

	We tracked down the technical issue. After this initial impact level 
assessment, a ports level forum should decide on how to procceed based 
on impact assessment/cost versus benefit. portmgr@ is the correct forum 
for such decisions on ports level:

	1) whether it wants to pursue a gcov src-pre-RELEASE fix (which will 
require both approval and regression tests on re@ part);
	2) whether it wants to add automated "fix" support on bsd.port.mk;
	3) whether it wants to issue an ERRATA post-RELEASE if no fix is applied;
	4) whether it wants to issue a global UPDATING notice;
	5) etc

 > ...
 >
 >> 	There is still an issue though of adding automated support for
 >> stack-protect but this gets blurred by the fact we are considering a
 >> migration from gcc to llvm. Does llvm support such flags? Or, are they
 >> gcc centric?
 >
 > Even if llvm becomes the default base system compiler, gcc will still
 > be used for many Ports, so the issue will still have to be resolved.
 > I think that we need to perform the {C,CPP,LD}FLAGS clean-up, and add
 > the automated support for stack protection in LDFLAGS.  This ought to
 > be done anyway because of recent and probable upcoming
 > gcc/Fortran-related changes.  If llvm is used later, and chokes on the
 > flags, we can make them conditional on the value of CC.
 >

	I think we should treat this as a separate issue for now. Our current 
step should be: how do we deal with the current breakage?

	Regards,
		Mario Ferreira
Comment 18 kabaev 2009-11-28 15:43:36 UTC
On Tue, 24 Nov 2009 23:43:26 -0200
Mario Sergio Fujikawa Ferreira <lioux@FreeBSD.org> wrote:

> The situation is as follows: /usr/lib/libgcov.a from our base system
> is being linked with ProPolice symbols. Therefore, any binary that
> links to gcov will have to link to ProPolice symbols as well.

Hi,

I apologize for taking too long to respond. Thee libgcov.a fix will be
MFCed to stable/8 today or tomorrow and that should take care of PGO
problem.

The yelp problem is more involved. Apparently it tries to link in
static library from xulrunner,which was compiled with -fpic and
-fstack-protector. This combination of flags makes compiler assume that
the object file it created is destined for shared library and
__stack_chk_fail_local symbol will be provided at linking stage. It
depends on -fstack-protector flag to invoke the corresponding magic at
shared library linking stage and this unfortunately means yep has to use
-fstack-protector if it wants to link with this library. Using
-fstack-protector just at linking stage will not involve any runtime
penalty. Alternatively, you can just add -lssp_nonshared as last
argument to the linker, it will have exactly the same effect.

-- 
Alexander Kabaev
Comment 19 Trix Farrar 2009-12-08 23:12:58 UTC
Please also refer to ports/141238 for additional ports/information.
Specifically, net-mgmt/net-snmp
Comment 20 liouxbsd 2009-12-12 09:36:37 UTC
On Sat, Nov 28, 2009 at 04:09:41PM +0000, Alexander Kabaev wrote:
> 
> The following reply was made to PR ports/140791; it has been noted by GNATS.
> 
> From: Alexander Kabaev <kabaev@gmail.com>
> To: Mario Sergio Fujikawa Ferreira <lioux@FreeBSD.org>
> Cc: "b. f." <bf1783@googlemail.com>, bug-followup@freebsd.org,
>  miwi@freebsd.org, gerald@freebsd.org, kan@freebsd.org, mezz@freebsd.org
> Subject: Re: ports/140791: [PATCH] textproc/libtre: Fix build on systems
>  where 	GCC stack protection was enabled for userland
> Date: Sat, 28 Nov 2009 10:43:36 -0500
> 
>  --Sig_/5eyE0l2qX+Dr43MiVDqCvWm
>  Content-Type: text/plain; charset=US-ASCII
>  Content-Transfer-Encoding: quoted-printable
>  
>  On Tue, 24 Nov 2009 23:43:26 -0200
>  Mario Sergio Fujikawa Ferreira <lioux@FreeBSD.org> wrote:
>  
>  > The situation is as follows: /usr/lib/libgcov.a from our base system
>  > is being linked with ProPolice symbols. Therefore, any binary that
>  > links to gcov will have to link to ProPolice symbols as well.
>  Hi,
>  
>  I apologize for taking too long to respond. Thee libgcov.a fix will be
>  MFCed to stable/8 today or tomorrow and that should take care of PGO
>  problem.

	Any news on the MFC? It's been 2 weeks now.

	I was holding the commits due to this MFC. However, there
is real breakage and I will no longer be able to hold them if the
MFC plans have been compromised.

>  The yelp problem is more involved. Apparently it tries to link in
>  static library from xulrunner,which was compiled with -fpic and
>  -fstack-protector. This combination of flags makes compiler assume that
>  the object file it created is destined for shared library and
>  __stack_chk_fail_local symbol will be provided at linking stage. It
>  depends on -fstack-protector flag to invoke the corresponding magic at
>  shared library linking stage and this unfortunately means yep has to use
>  -fstack-protector if it wants to link with this library. Using
>  -fstack-protector just at linking stage will not involve any runtime
>  penalty. Alternatively, you can just add -lssp_nonshared as last
>  argument to the linker, it will have exactly the same effect.

	The GNOME has dealt with it based on a previous PR of mine.
They are linking against ProPolice on the offending OSVERSION.

	Regards,

-- 
Mario S F Ferreira - DF - Brazil - "I guess this is a signature."
feature, n: a documented bug | bug, n: an undocumented feature
Comment 21 Diane Bruce 2010-04-13 15:39:40 UTC
Hi,

This bug also bites us in kdeutils-3.5.10_3, the configure script
fails on net-snmp because net-snmp was compiled with stack protection.

===>  Building package for kdeutils-3.5.10_3
tar: lib/kde3/ksim_snmp.a: Cannot stat: No such file or directory
tar: lib/kde3/ksim_snmp.la: Cannot stat: No such file or directory
tar: lib/kde3/ksim_snmp.so: Cannot stat: No such file or directory
tar: share/apps/ksim/monitors/Snmp.desktop: Cannot stat: No such file or directory
tar: Error exit delayed from previous errors.
pkg_create: make_dist: tar command failed with code 256

- Diane
-- 
- db@FreeBSD.org db@db.net http://www.db.net/~db
Comment 22 Mark Linimon freebsd_committer freebsd_triage 2010-07-14 01:23:40 UTC
Responsible Changed
From-To: lioux->bf

Maintainer is now committer.
Comment 23 b. f. 2010-08-06 00:40:25 UTC
It appears that this problem is fixed with default builds of libtre on
9-CURRENT, 8.1, and 8-STABLE after r198471 and r200748. (And there are
related fixes for other cases proposed in:

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=ports/138228
http://lists.freebsd.org/pipermail/freebsd-hackers/2010-August/032549.html

.)So, if there are no objections, I plan to close this PR soon.

Regards,
                  b.
Comment 24 b. f. 2010-08-06 00:40:25 UTC
It appears that this problem is fixed with default builds of libtre on
9-CURRENT, 8.1, and 8-STABLE after r198471 and r200748. (And there are
related fixes for other cases proposed in:

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=ports/138228
http://lists.freebsd.org/pipermail/freebsd-hackers/2010-August/032549.html

.)So, if there are no objections, I plan to close this PR soon.

Regards,
                  b.
Comment 25 b. f. 2010-08-06 00:40:25 UTC
It appears that this problem is fixed with default builds of libtre on
9-CURRENT, 8.1, and 8-STABLE after r198471 and r200748. (And there are
related fixes for other cases proposed in:

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=ports/138228
http://lists.freebsd.org/pipermail/freebsd-hackers/2010-August/032549.html

.)So, if there are no objections, I plan to close this PR soon.

Regards,
                  b.
Comment 26 Mario Sergio Fujikawa Ferreira freebsd_committer 2010-08-06 19:26:09 UTC
Quoting "b. f." <bf1783@googlemail.com>:

> It appears that this problem is fixed with default builds of libtre on
> 9-CURRENT, 8.1, and 8-STABLE after r198471 and r200748. (And there are
> related fixes for other cases proposed in:
>
> http://www.FreeBSD.org/cgi/query-pr.cgi?pr=ports/138228
> http://lists.freebsd.org/pipermail/freebsd-hackers/2010-August/032549.html
>
> .)So, if there are no objections, I plan to close this PR soon.

  You can close it. :) 

  Regards,

-- 
Mario S F Ferreira - DF - Brazil - "I guess this is a signature."
feature, n: a documented bug | bug, n: an undocumented feature
Comment 27 Brendan Fabeny freebsd_committer 2010-08-08 23:13:41 UTC
State Changed
From-To: feedback->closed

problem has been resolved by changes to the base system on FreeBSD 8,9; 
workarounds exist for other cases