Re: libc++ vs. libstdc++ usage in the ports tree
Please commit (Approved by: portmgr(bapt)) if needed
regards,
Bapt
On Sun, Dec 01, 2013 at 03:06:40PM +0100, Tijl Coosemans wrote:
On Wed, 27 Nov 2013 20:45:56 +0100 Tijl Coosemans wrote:
On Wed, 27 Nov 2013 19:31:44 +0100 Jan Henrik Sylvester wrote:
Trying to migrate to 10, I would like to keep octave. Have you found
anything new? Having build the port and all dependencies with standard
options, octave is segfaulting for me, too. Anyhow, I can run octave with:
env LD_PRELOAD=/usr/lib/libc++.so.1 octave
Some very light testing indicates that it is working. Of course, this is
not ideal.
Maybe this gives a clue how to fix the octave port properly.
I have a preliminary patch for math/octave that I wanted to test on
redports first, but it is down at the moment so here it is.
The tests were successful:
https://redports.org/buildarchive/20131201105316-94935/ (octave)
https://redports.org/buildarchive/20131201115701-22333/ (octave-forge-base)
The octave logs also contain the results of running the regression-test
target. The output is the same on all FreeBSD versions.
The problem is that USE_FORTRAN=yes implies USE_GCC=yes. This means
the C++ code in math/octave is compiled with gcc46/libstdc++ which
does not work if dependencies have been built with clang/libc++.
The patch copies the USE_FORTRAN=yes logic from Mk/bsd.gcc.mk into a
new file Mk/Uses/fortran.mk. It allows ports to use a Fortran compiler
together with the base system C/C++ compiler.
Index: math/octave/Makefile
===
--- math/octave/Makefile (revision 335379)
+++ math/octave/Makefile (working copy)
@@ -3,7 +3,7 @@
PORTNAME=octave
PORTVERSION= 3.6.4
-PORTREVISION=6
+PORTREVISION=7
CATEGORIES= math
MASTER_SITES=ftp://ftp.gnu.org/gnu/octave/ \
ftp://ftp.u-aizu.ac.jp/pub/SciEng/numanal/Octave/bleeding-edge/
@@ -32,7 +32,7 @@ LIB_DEPENDS=GraphicsMagick:${PORTSDIR}/
umfpack.1:${PORTSDIR}/math/suitesparse \
glpk:${PORTSDIR}/math/glpk
-USES=charsetfix gmake perl5 pkgconfig
+USES=charsetfix fortran gmake perl5 pkgconfig
USE_BZIP2= yes
USE_PERL5= build
USE_TEX= dvipsk:build
@@ -74,8 +74,6 @@ BLAS= -lptf77blas
LAPACK= -lalapack -lptcblas
.endif
-USE_FORTRAN= yes
-
OCTAVE_VERSION= ${PORTVERSION}
GNU_HOST=${ARCH}-portbld-freebsd${OSREL}
PLIST_SUB= OCTAVE_VERSION=${OCTAVE_VERSION} GNU_HOST=${GNU_HOST}
@@ -140,7 +138,8 @@ post-install:
${ECHO_CMD} @dirrm share/octave ${WRKDIR}/PLIST
cd ${WRKDIR} ; ${SED} -i -e /PLIST/ r PLIST ${TMPPLIST}
-check:
+check: regression-test
+regression-test: build
(cd ${WRKSRC}; ${SETENV} ${MAKE_ENV} ${GMAKE} ${MAKE_ARGS} check)
.include bsd.port.post.mk
Index: math/octave/files/patch-configure
===
--- math/octave/files/patch-configure (revision 0)
+++ math/octave/files/patch-configure (working copy)
@@ -0,0 +1,11 @@
+--- configure.orig 2013-02-21 21:21:49.0 +0100
configure2013-11-22 20:34:49.0 +0100
+@@ -58248,7 +58248,7 @@
+ main ()
+ {
+
+- std::unordered_map m;
++ std::unordered_mapint, int m;
+
+ ;
+ return 0;
Property changes on: math/octave/files/patch-configure
___
Added: fbsd:nokeywords
## -0,0 +1 ##
+yes
\ No newline at end of property
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No newline at end of property
Added: svn:mime-type
## -0,0 +1 ##
+text/plain
\ No newline at end of property
Index: math/octave/files/patch-libgnu-math.in.h
===
--- math/octave/files/patch-libgnu-math.in.h (revision 0)
+++ math/octave/files/patch-libgnu-math.in.h (working copy)
@@ -0,0 +1,11 @@
+--- libgnu/math.in.h.orig2013-02-21 21:21:17.0 +0100
libgnu/math.in.h 2013-11-22 12:35:47.0 +0100
+@@ -17,7 +17,7 @@
+You should have received a copy of the GNU General Public License
+along with this program. If not, see http://www.gnu.org/licenses/. */
+
+-#ifndef _@GUARD_PREFIX@_MATH_H
++#if 1
+
+ #if __GNUC__ = 3
+ @PRAGMA_SYSTEM_HEADER@
Property changes on: math/octave/files/patch-libgnu-math.in.h
___
Added: svn:mime-type
## -0,0 +1 ##
+text/plain
\ No newline at end of property
Added: fbsd:nokeywords
## -0,0 +1 ##
+yes
\ No newline at end of property
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No newline at end of property
Index: math/octave/files/patch-liboctave-eigs-base.cc
===
---
Re: libc++ vs. libstdc++ usage in the ports tree
Hi all Does anybody please commit the patch? My FreeBSD machine is down due to power outage for next week. Also I'll be very busy in the next week. Best, Nakata Maho From: Steve Kargl s...@troutmask.apl.washington.edu Subject: Re: libc++ vs. libstdc++ usage in the ports tree Date: Thu, 12 Dec 2013 17:12:04 -0800 On Sun, Dec 01, 2013 at 03:06:40PM +0100, Tijl Coosemans wrote: On Wed, 27 Nov 2013 20:45:56 +0100 Tijl Coosemans wrote: On Wed, 27 Nov 2013 19:31:44 +0100 Jan Henrik Sylvester wrote: Trying to migrate to 10, I would like to keep octave. Have you found anything new? Having build the port and all dependencies with standard options, octave is segfaulting for me, too. Anyhow, I can run octave with: env LD_PRELOAD=/usr/lib/libc++.so.1 octave Some very light testing indicates that it is working. Of course, this is not ideal. Maybe this gives a clue how to fix the octave port properly. I have a preliminary patch for math/octave that I wanted to test on redports first, but it is down at the moment so here it is. The tests were successful: https://redports.org/buildarchive/20131201105316-94935/ (octave) https://redports.org/buildarchive/20131201115701-22333/ (octave-forge-base) The octave logs also contain the results of running the regression-test target. The output is the same on all FreeBSD versions. The problem is that USE_FORTRAN=yes implies USE_GCC=yes. This means the C++ code in math/octave is compiled with gcc46/libstdc++ which does not work if dependencies have been built with clang/libc++. The patch copies the USE_FORTRAN=yes logic from Mk/bsd.gcc.mk into a new file Mk/Uses/fortran.mk. It allows ports to use a Fortran compiler together with the base system C/C++ compiler. I see the octave port is still broken. After a clean install on my self, removing all installed ports, reverting my local chnages in /usr/pors, and rebuilding all ports, I'm see the original problem. % octave Segmentation fault (core dumped) PLEASE, commit your patch ASAP. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: libc++ vs. libstdc++ usage in the ports tree
On Thu, 12 Dec 2013 17:12:04 -0800 Steve Kargl wrote: I see the octave port is still broken. After a clean install on my self, removing all installed ports, reverting my local chnages in /usr/pors, and rebuilding all ports, I'm see the original problem. % octave Segmentation fault (core dumped) PLEASE, commit your patch ASAP. Committed in r336344. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: libc++ vs. libstdc++ usage in the ports tree
On 12/13/2013 14:47, Tijl Coosemans wrote: On Thu, 12 Dec 2013 17:12:04 -0800 Steve Kargl wrote: I see the octave port is still broken. After a clean install on my self, removing all installed ports, reverting my local chnages in /usr/pors, and rebuilding all ports, I'm see the original problem. % octave Segmentation fault (core dumped) PLEASE, commit your patch ASAP. Committed in r336344. Thank you! Is it exactly the same as you attached here: http://lists.freebsd.org/pipermail/freebsd-current/2013-December/046986.html Or should I rebuild on my machines? Cheers, Jan Henrik ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: libc++ vs. libstdc++ usage in the ports tree
On Fri, 13 Dec 2013 15:49:19 +0100 Jan Henrik Sylvester wrote: On 12/13/2013 14:47, Tijl Coosemans wrote: On Thu, 12 Dec 2013 17:12:04 -0800 Steve Kargl wrote: I see the octave port is still broken. After a clean install on my self, removing all installed ports, reverting my local chnages in /usr/pors, and rebuilding all ports, I'm see the original problem. % octave Segmentation fault (core dumped) PLEASE, commit your patch ASAP. Committed in r336344. Thank you! Is it exactly the same as you attached here: http://lists.freebsd.org/pipermail/freebsd-current/2013-December/046986.html Or should I rebuild on my machines? If you applied the patch to a subversion checkout you may get a conflict on Mk/Uses/fortran.mk and math/octave/Makefile when updating which you can resolve using the 'tf' option (theirs-full). Besides that the patches are functionally the same so you don't have to rebuild anything. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: libc++ vs. libstdc++ usage in the ports tree
On Fri, Dec 13, 2013 at 02:47:23PM +0100, Tijl Coosemans wrote: On Thu, 12 Dec 2013 17:12:04 -0800 Steve Kargl wrote: I see the octave port is still broken. After a clean install on my self, removing all installed ports, reverting my local chnages in /usr/pors, and rebuilding all ports, I'm see the original problem. % octave Segmentation fault (core dumped) PLEASE, commit your patch ASAP. Committed in r336344. Thank you!!! Doing a 'pkg delete -fR' on all installed ports except pkg, pkg, and portmaster, of course, removed everything but those 3 ports. % portmaster math/octave causes 208 ports to be built and installed. The resulting octave now functions. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: libc++ vs. libstdc++ usage in the ports tree
Many thanks! From: Tijl Coosemans t...@freebsd.org Subject: Re: libc++ vs. libstdc++ usage in the ports tree Date: Fri, 13 Dec 2013 14:47:23 +0100 On Thu, 12 Dec 2013 17:12:04 -0800 Steve Kargl wrote: I see the octave port is still broken. After a clean install on my self, removing all installed ports, reverting my local chnages in /usr/pors, and rebuilding all ports, I'm see the original problem. % octave Segmentation fault (core dumped) PLEASE, commit your patch ASAP. Committed in r336344. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: libc++ vs. libstdc++ usage in the ports tree
On Sun, Dec 01, 2013 at 03:06:40PM +0100, Tijl Coosemans wrote: On Wed, 27 Nov 2013 20:45:56 +0100 Tijl Coosemans wrote: On Wed, 27 Nov 2013 19:31:44 +0100 Jan Henrik Sylvester wrote: Trying to migrate to 10, I would like to keep octave. Have you found anything new? Having build the port and all dependencies with standard options, octave is segfaulting for me, too. Anyhow, I can run octave with: env LD_PRELOAD=/usr/lib/libc++.so.1 octave Some very light testing indicates that it is working. Of course, this is not ideal. Maybe this gives a clue how to fix the octave port properly. I have a preliminary patch for math/octave that I wanted to test on redports first, but it is down at the moment so here it is. The tests were successful: https://redports.org/buildarchive/20131201105316-94935/ (octave) https://redports.org/buildarchive/20131201115701-22333/ (octave-forge-base) The octave logs also contain the results of running the regression-test target. The output is the same on all FreeBSD versions. The problem is that USE_FORTRAN=yes implies USE_GCC=yes. This means the C++ code in math/octave is compiled with gcc46/libstdc++ which does not work if dependencies have been built with clang/libc++. The patch copies the USE_FORTRAN=yes logic from Mk/bsd.gcc.mk into a new file Mk/Uses/fortran.mk. It allows ports to use a Fortran compiler together with the base system C/C++ compiler. I see the octave port is still broken. After a clean install on my self, removing all installed ports, reverting my local chnages in /usr/pors, and rebuilding all ports, I'm see the original problem. % octave Segmentation fault (core dumped) PLEASE, commit your patch ASAP. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: libc++ vs. libstdc++ usage in the ports tree
On Sun, Dec 1, 2013 at 3:06 PM, Tijl Coosemans t...@freebsd.org wrote: On Wed, 27 Nov 2013 20:45:56 +0100 Tijl Coosemans wrote: On Wed, 27 Nov 2013 19:31:44 +0100 Jan Henrik Sylvester wrote: Trying to migrate to 10, I would like to keep octave. Have you found anything new? Having build the port and all dependencies with standard options, octave is segfaulting for me, too. Anyhow, I can run octave with: env LD_PRELOAD=/usr/lib/libc++.so.1 octave Some very light testing indicates that it is working. Of course, this is not ideal. Maybe this gives a clue how to fix the octave port properly. I have a preliminary patch for math/octave that I wanted to test on redports first, but it is down at the moment so here it is. The tests were successful: https://redports.org/buildarchive/20131201105316-94935/ (octave) https://redports.org/buildarchive/20131201115701-22333/ (octave-forge-base) The octave logs also contain the results of running the regression-test target. The output is the same on all FreeBSD versions. The problem is that USE_FORTRAN=yes implies USE_GCC=yes. This means the C++ code in math/octave is compiled with gcc46/libstdc++ which does not work if dependencies have been built with clang/libc++. The patch copies the USE_FORTRAN=yes logic from Mk/bsd.gcc.mk into a new file Mk/Uses/fortran.mk. It allows ports to use a Fortran compiler together with the base system C/C++ compiler. This is nice! Cheers, Antoine ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: libc++ vs. libstdc++ usage in the ports tree
On 12/01/2013 15:06, Tijl Coosemans wrote: On Wed, 27 Nov 2013 20:45:56 +0100 Tijl Coosemans wrote: On Wed, 27 Nov 2013 19:31:44 +0100 Jan Henrik Sylvester wrote: Trying to migrate to 10, I would like to keep octave. Have you found anything new? Having build the port and all dependencies with standard options, octave is segfaulting for me, too. Anyhow, I can run octave with: env LD_PRELOAD=/usr/lib/libc++.so.1 octave Some very light testing indicates that it is working. Of course, this is not ideal. Maybe this gives a clue how to fix the octave port properly. I have a preliminary patch for math/octave that I wanted to test on redports first, but it is down at the moment so here it is. The tests were successful: https://redports.org/buildarchive/20131201105316-94935/ (octave) https://redports.org/buildarchive/20131201115701-22333/ (octave-forge-base) The octave logs also contain the results of running the regression-test target. The output is the same on all FreeBSD versions. The problem is that USE_FORTRAN=yes implies USE_GCC=yes. This means the C++ code in math/octave is compiled with gcc46/libstdc++ which does not work if dependencies have been built with clang/libc++. The patch copies the USE_FORTRAN=yes logic from Mk/bsd.gcc.mk into a new file Mk/Uses/fortran.mk. It allows ports to use a Fortran compiler together with the base system C/C++ compiler. With the patch, math/octave fails for me on 9.2-RELEASE/amd64 and 10.0-BETA4/amd64 with: checking for amd64-portbld-freebsd(9.2|10.0)-gfortran... f77 checking whether we are using the GNU Fortran 77 compiler... no checking whether f77 accepts -g... no checking how to get verbose linking output from f77... configure: WARNING: compilation failed checking for Fortran 77 libraries of f77... checking for dummy main to link with Fortran 77 libraries... none checking for Fortran 77 name-mangling scheme... configure: error: in `/usr/ports/math/octave/work/octave-3.6.4': configure: error: cannot compile a simple Fortran program Full logs attached (each with and without your patch). In both cases, it tries to use f77, while the original port uses gfortran46. Any idea what is wrong on my system? Cheers, Jan Henrik octave-3.6.4_7-fortran_patch-9.2-RELEASE-amd64.log.xz Description: Binary data octave-3.6.4_7-fortran_patch-10.0-BETA4-amd64.log.xz Description: Binary data octave-3.6.4_6-orig-9.2-RELEASE-amd64.log.xz Description: Binary data octave-3.6.4_6-orig-10.0-BETA4-amd64.log.xz Description: Binary data ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: libc++ vs. libstdc++ usage in the ports tree
On Tue, 03 Dec 2013 21:26:18 +0100 Jan Henrik Sylvester wrote: On 12/01/2013 15:06, Tijl Coosemans wrote: On Wed, 27 Nov 2013 20:45:56 +0100 Tijl Coosemans wrote: On Wed, 27 Nov 2013 19:31:44 +0100 Jan Henrik Sylvester wrote: Trying to migrate to 10, I would like to keep octave. Have you found anything new? Having build the port and all dependencies with standard options, octave is segfaulting for me, too. Anyhow, I can run octave with: env LD_PRELOAD=/usr/lib/libc++.so.1 octave Some very light testing indicates that it is working. Of course, this is not ideal. Maybe this gives a clue how to fix the octave port properly. I have a preliminary patch for math/octave that I wanted to test on redports first, but it is down at the moment so here it is. The tests were successful: https://redports.org/buildarchive/20131201105316-94935/ (octave) https://redports.org/buildarchive/20131201115701-22333/ (octave-forge-base) The octave logs also contain the results of running the regression-test target. The output is the same on all FreeBSD versions. The problem is that USE_FORTRAN=yes implies USE_GCC=yes. This means the C++ code in math/octave is compiled with gcc46/libstdc++ which does not work if dependencies have been built with clang/libc++. The patch copies the USE_FORTRAN=yes logic from Mk/bsd.gcc.mk into a new file Mk/Uses/fortran.mk. It allows ports to use a Fortran compiler together with the base system C/C++ compiler. With the patch, math/octave fails for me on 9.2-RELEASE/amd64 and 10.0-BETA4/amd64 with: checking for amd64-portbld-freebsd(9.2|10.0)-gfortran... f77 checking whether we are using the GNU Fortran 77 compiler... no checking whether f77 accepts -g... no checking how to get verbose linking output from f77... configure: WARNING: compilation failed checking for Fortran 77 libraries of f77... checking for dummy main to link with Fortran 77 libraries... none checking for Fortran 77 name-mangling scheme... configure: error: in `/usr/ports/math/octave/work/octave-3.6.4': configure: error: cannot compile a simple Fortran program Full logs attached (each with and without your patch). In both cases, it tries to use f77, while the original port uses gfortran46. Any idea what is wrong on my system? Do you define FC in make.conf maybe? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: libc++ vs. libstdc++ usage in the ports tree
On 12/03/2013 21:54, Tijl Coosemans wrote: On Tue, 03 Dec 2013 21:26:18 +0100 Jan Henrik Sylvester wrote: On 12/01/2013 15:06, Tijl Coosemans wrote: On Wed, 27 Nov 2013 20:45:56 +0100 Tijl Coosemans wrote: On Wed, 27 Nov 2013 19:31:44 +0100 Jan Henrik Sylvester wrote: Trying to migrate to 10, I would like to keep octave. Have you found anything new? Having build the port and all dependencies with standard options, octave is segfaulting for me, too. Anyhow, I can run octave with: env LD_PRELOAD=/usr/lib/libc++.so.1 octave Some very light testing indicates that it is working. Of course, this is not ideal. Maybe this gives a clue how to fix the octave port properly. I have a preliminary patch for math/octave that I wanted to test on redports first, but it is down at the moment so here it is. The tests were successful: https://redports.org/buildarchive/20131201105316-94935/ (octave) https://redports.org/buildarchive/20131201115701-22333/ (octave-forge-base) The octave logs also contain the results of running the regression-test target. The output is the same on all FreeBSD versions. The problem is that USE_FORTRAN=yes implies USE_GCC=yes. This means the C++ code in math/octave is compiled with gcc46/libstdc++ which does not work if dependencies have been built with clang/libc++. The patch copies the USE_FORTRAN=yes logic from Mk/bsd.gcc.mk into a new file Mk/Uses/fortran.mk. It allows ports to use a Fortran compiler together with the base system C/C++ compiler. With the patch, math/octave fails for me on 9.2-RELEASE/amd64 and 10.0-BETA4/amd64 with: checking for amd64-portbld-freebsd(9.2|10.0)-gfortran... f77 checking whether we are using the GNU Fortran 77 compiler... no checking whether f77 accepts -g... no checking how to get verbose linking output from f77... configure: WARNING: compilation failed checking for Fortran 77 libraries of f77... checking for dummy main to link with Fortran 77 libraries... none checking for Fortran 77 name-mangling scheme... configure: error: in `/usr/ports/math/octave/work/octave-3.6.4': configure: error: cannot compile a simple Fortran program Full logs attached (each with and without your patch). In both cases, it tries to use f77, while the original port uses gfortran46. Any idea what is wrong on my system? Do you define FC in make.conf maybe? No, besides some options (*_SET / *_UNSET) for some unrelated ports, I only have got this in make.conf: WITH_PKGNG=yes WITH_NEW_XORG=yes TEX_DEFAULT=texlive Cheers, Jan Henrik ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: libc++ vs. libstdc++ usage in the ports tree
On Tue, 03 Dec 2013 22:37:34 +0100 Jan Henrik Sylvester wrote:
On 12/03/2013 21:54, Tijl Coosemans wrote:
On Tue, 03 Dec 2013 21:26:18 +0100 Jan Henrik Sylvester wrote:
On 12/01/2013 15:06, Tijl Coosemans wrote:
The tests were successful:
https://redports.org/buildarchive/20131201105316-94935/ (octave)
https://redports.org/buildarchive/20131201115701-22333/ (octave-forge-base)
The octave logs also contain the results of running the regression-test
target. The output is the same on all FreeBSD versions.
The problem is that USE_FORTRAN=yes implies USE_GCC=yes. This means
the C++ code in math/octave is compiled with gcc46/libstdc++ which
does not work if dependencies have been built with clang/libc++.
The patch copies the USE_FORTRAN=yes logic from Mk/bsd.gcc.mk into a
new file Mk/Uses/fortran.mk. It allows ports to use a Fortran compiler
together with the base system C/C++ compiler.
With the patch, math/octave fails for me on 9.2-RELEASE/amd64 and
10.0-BETA4/amd64 with:
checking for amd64-portbld-freebsd(9.2|10.0)-gfortran... f77
checking whether we are using the GNU Fortran 77 compiler... no
checking whether f77 accepts -g... no
checking how to get verbose linking output from f77... configure:
WARNING: compilation failed
checking for Fortran 77 libraries of f77...
checking for dummy main to link with Fortran 77 libraries... none
checking for Fortran 77 name-mangling scheme... configure: error: in
`/usr/ports/math/octave/work/octave-3.6.4':
configure: error: cannot compile a simple Fortran program
Full logs attached (each with and without your patch).
In both cases, it tries to use f77, while the original port uses gfortran46.
Any idea what is wrong on my system?
Do you define FC in make.conf maybe?
No, besides some options (*_SET / *_UNSET) for some unrelated ports, I
only have got this in make.conf:
Hmm, apparently FC is defined by sys.mk. I've attached a new patch.Index: math/octave/Makefile
===
--- math/octave/Makefile (revision 335568)
+++ math/octave/Makefile (working copy)
@@ -3,7 +3,7 @@
PORTNAME= octave
PORTVERSION= 3.6.4
-PORTREVISION= 6
+PORTREVISION= 7
CATEGORIES= math
MASTER_SITES= ftp://ftp.gnu.org/gnu/octave/ \
ftp://ftp.u-aizu.ac.jp/pub/SciEng/numanal/Octave/bleeding-edge/
@@ -32,7 +32,7 @@ LIB_DEPENDS= GraphicsMagick:${PORTSDIR}/
umfpack.1:${PORTSDIR}/math/suitesparse \
glpk:${PORTSDIR}/math/glpk
-USES= charsetfix gmake perl5 pkgconfig
+USES= charsetfix fortran gmake perl5 pkgconfig
USE_BZIP2= yes
USE_PERL5= build
USE_TEX= dvipsk:build
@@ -74,8 +74,6 @@ BLAS= -lptf77blas
LAPACK= -lalapack -lptcblas
.endif
-USE_FORTRAN= yes
-
OCTAVE_VERSION= ${PORTVERSION}
GNU_HOST= ${ARCH}-portbld-freebsd${OSREL}
PLIST_SUB= OCTAVE_VERSION=${OCTAVE_VERSION} GNU_HOST=${GNU_HOST}
@@ -140,7 +138,8 @@ post-install:
${ECHO_CMD} @dirrm share/octave ${WRKDIR}/PLIST
cd ${WRKDIR} ; ${SED} -i -e /PLIST/ r PLIST ${TMPPLIST}
-check:
+check: regression-test
+regression-test: build
(cd ${WRKSRC}; ${SETENV} ${MAKE_ENV} ${GMAKE} ${MAKE_ARGS} check)
.include bsd.port.post.mk
Index: math/octave/files/patch-configure
===
--- math/octave/files/patch-configure (revision 0)
+++ math/octave/files/patch-configure (working copy)
@@ -0,0 +1,11 @@
+--- configure.orig 2013-02-21 21:21:49.0 +0100
configure 2013-11-22 20:34:49.0 +0100
+@@ -58248,7 +58248,7 @@
+ main ()
+ {
+
+- std::unordered_map m;
++ std::unordered_mapint, int m;
+
+ ;
+ return 0;
Property changes on: math/octave/files/patch-configure
___
Added: fbsd:nokeywords
## -0,0 +1 ##
+yes
\ No newline at end of property
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No newline at end of property
Added: svn:mime-type
## -0,0 +1 ##
+text/plain
\ No newline at end of property
Index: math/octave/files/patch-libgnu-math.in.h
===
--- math/octave/files/patch-libgnu-math.in.h (revision 0)
+++ math/octave/files/patch-libgnu-math.in.h (working copy)
@@ -0,0 +1,11 @@
+--- libgnu/math.in.h.orig 2013-02-21 21:21:17.0 +0100
libgnu/math.in.h 2013-11-22 12:35:47.0 +0100
+@@ -17,7 +17,7 @@
+You should have received a copy of the GNU General Public License
+along with this program. If not, see http://www.gnu.org/licenses/. */
+
+-#ifndef _@GUARD_PREFIX@_MATH_H
++#if 1
+
+ #if __GNUC__ = 3
+ @PRAGMA_SYSTEM_HEADER@
Property changes on: math/octave/files/patch-libgnu-math.in.h
___
Added: svn:mime-type
## -0,0 +1 ##
+text/plain
\ No newline at end of property
Added: fbsd:nokeywords
## -0,0 +1 ##
+yes
\ No newline at end of property
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No newline at end of property
Index:
Re: libc++ vs. libstdc++ usage in the ports tree
On 12/04/2013 00:23, Tijl Coosemans wrote: On Tue, 03 Dec 2013 22:37:34 +0100 Jan Henrik Sylvester wrote: On 12/03/2013 21:54, Tijl Coosemans wrote: On Tue, 03 Dec 2013 21:26:18 +0100 Jan Henrik Sylvester wrote: On 12/01/2013 15:06, Tijl Coosemans wrote: The tests were successful: https://redports.org/buildarchive/20131201105316-94935/ (octave) https://redports.org/buildarchive/20131201115701-22333/ (octave-forge-base) The octave logs also contain the results of running the regression-test target. The output is the same on all FreeBSD versions. The problem is that USE_FORTRAN=yes implies USE_GCC=yes. This means the C++ code in math/octave is compiled with gcc46/libstdc++ which does not work if dependencies have been built with clang/libc++. The patch copies the USE_FORTRAN=yes logic from Mk/bsd.gcc.mk into a new file Mk/Uses/fortran.mk. It allows ports to use a Fortran compiler together with the base system C/C++ compiler. With the patch, math/octave fails for me on 9.2-RELEASE/amd64 and 10.0-BETA4/amd64 with: checking for amd64-portbld-freebsd(9.2|10.0)-gfortran... f77 checking whether we are using the GNU Fortran 77 compiler... no checking whether f77 accepts -g... no checking how to get verbose linking output from f77... configure: WARNING: compilation failed checking for Fortran 77 libraries of f77... checking for dummy main to link with Fortran 77 libraries... none checking for Fortran 77 name-mangling scheme... configure: error: in `/usr/ports/math/octave/work/octave-3.6.4': configure: error: cannot compile a simple Fortran program Full logs attached (each with and without your patch). In both cases, it tries to use f77, while the original port uses gfortran46. Any idea what is wrong on my system? Do you define FC in make.conf maybe? No, besides some options (*_SET / *_UNSET) for some unrelated ports, I only have got this in make.conf: Hmm, apparently FC is defined by sys.mk. I've attached a new patch. Ok, with the new patch, it compiles and packages on 9.2-RELEASE/amd64 and 10.0-BETA4/amd64. From the new packages, the octave binaries were able to do some simple math. Thanks, Jan Henrik ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: libc++ vs. libstdc++ usage in the ports tree
On Wed, 27 Nov 2013 20:45:56 +0100 Tijl Coosemans wrote:
On Wed, 27 Nov 2013 19:31:44 +0100 Jan Henrik Sylvester wrote:
Trying to migrate to 10, I would like to keep octave. Have you found
anything new? Having build the port and all dependencies with standard
options, octave is segfaulting for me, too. Anyhow, I can run octave with:
env LD_PRELOAD=/usr/lib/libc++.so.1 octave
Some very light testing indicates that it is working. Of course, this is
not ideal.
Maybe this gives a clue how to fix the octave port properly.
I have a preliminary patch for math/octave that I wanted to test on
redports first, but it is down at the moment so here it is.
The tests were successful:
https://redports.org/buildarchive/20131201105316-94935/ (octave)
https://redports.org/buildarchive/20131201115701-22333/ (octave-forge-base)
The octave logs also contain the results of running the regression-test
target. The output is the same on all FreeBSD versions.
The problem is that USE_FORTRAN=yes implies USE_GCC=yes. This means
the C++ code in math/octave is compiled with gcc46/libstdc++ which
does not work if dependencies have been built with clang/libc++.
The patch copies the USE_FORTRAN=yes logic from Mk/bsd.gcc.mk into a
new file Mk/Uses/fortran.mk. It allows ports to use a Fortran compiler
together with the base system C/C++ compiler.Index: math/octave/Makefile
===
--- math/octave/Makefile (revision 335379)
+++ math/octave/Makefile (working copy)
@@ -3,7 +3,7 @@
PORTNAME= octave
PORTVERSION= 3.6.4
-PORTREVISION= 6
+PORTREVISION= 7
CATEGORIES= math
MASTER_SITES= ftp://ftp.gnu.org/gnu/octave/ \
ftp://ftp.u-aizu.ac.jp/pub/SciEng/numanal/Octave/bleeding-edge/
@@ -32,7 +32,7 @@ LIB_DEPENDS= GraphicsMagick:${PORTSDIR}/
umfpack.1:${PORTSDIR}/math/suitesparse \
glpk:${PORTSDIR}/math/glpk
-USES= charsetfix gmake perl5 pkgconfig
+USES= charsetfix fortran gmake perl5 pkgconfig
USE_BZIP2= yes
USE_PERL5= build
USE_TEX= dvipsk:build
@@ -74,8 +74,6 @@ BLAS= -lptf77blas
LAPACK= -lalapack -lptcblas
.endif
-USE_FORTRAN= yes
-
OCTAVE_VERSION= ${PORTVERSION}
GNU_HOST= ${ARCH}-portbld-freebsd${OSREL}
PLIST_SUB= OCTAVE_VERSION=${OCTAVE_VERSION} GNU_HOST=${GNU_HOST}
@@ -140,7 +138,8 @@ post-install:
${ECHO_CMD} @dirrm share/octave ${WRKDIR}/PLIST
cd ${WRKDIR} ; ${SED} -i -e /PLIST/ r PLIST ${TMPPLIST}
-check:
+check: regression-test
+regression-test: build
(cd ${WRKSRC}; ${SETENV} ${MAKE_ENV} ${GMAKE} ${MAKE_ARGS} check)
.include bsd.port.post.mk
Index: math/octave/files/patch-configure
===
--- math/octave/files/patch-configure (revision 0)
+++ math/octave/files/patch-configure (working copy)
@@ -0,0 +1,11 @@
+--- configure.orig 2013-02-21 21:21:49.0 +0100
configure 2013-11-22 20:34:49.0 +0100
+@@ -58248,7 +58248,7 @@
+ main ()
+ {
+
+- std::unordered_map m;
++ std::unordered_mapint, int m;
+
+ ;
+ return 0;
Property changes on: math/octave/files/patch-configure
___
Added: fbsd:nokeywords
## -0,0 +1 ##
+yes
\ No newline at end of property
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No newline at end of property
Added: svn:mime-type
## -0,0 +1 ##
+text/plain
\ No newline at end of property
Index: math/octave/files/patch-libgnu-math.in.h
===
--- math/octave/files/patch-libgnu-math.in.h (revision 0)
+++ math/octave/files/patch-libgnu-math.in.h (working copy)
@@ -0,0 +1,11 @@
+--- libgnu/math.in.h.orig 2013-02-21 21:21:17.0 +0100
libgnu/math.in.h 2013-11-22 12:35:47.0 +0100
+@@ -17,7 +17,7 @@
+You should have received a copy of the GNU General Public License
+along with this program. If not, see http://www.gnu.org/licenses/. */
+
+-#ifndef _@GUARD_PREFIX@_MATH_H
++#if 1
+
+ #if __GNUC__ = 3
+ @PRAGMA_SYSTEM_HEADER@
Property changes on: math/octave/files/patch-libgnu-math.in.h
___
Added: svn:mime-type
## -0,0 +1 ##
+text/plain
\ No newline at end of property
Added: fbsd:nokeywords
## -0,0 +1 ##
+yes
\ No newline at end of property
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No newline at end of property
Index: math/octave/files/patch-liboctave-eigs-base.cc
===
--- math/octave/files/patch-liboctave-eigs-base.cc (revision 0)
+++ math/octave/files/patch-liboctave-eigs-base.cc (working copy)
@@ -0,0 +1,11 @@
+--- liboctave/eigs-base.cc.orig 2013-02-21 21:19:24.0 +0100
liboctave/eigs-base.cc 2013-11-22 20:19:19.0 +0100
+@@ -3832,7 +3832,7 @@
+ bool cholB = 0, int disp = 0, int maxit = 300);
+ #endif
+
+-#ifndef _MSC_VER
++#if !defined(_MSC_VER) !defined(__clang__)
+ template static
Re: Re: libc++ vs. libstdc++ usage in the ports tree
On Wed, Nov 27, 2013 at 07:31:44PM +0100, Jan Henrik Sylvester wrote: On 11/14/2013 15:45, Steve Kargl wrote: And in practice, it is broken. http://lists.freebsd.org/pipermail/freebsd-current/2013-November/046565.html QED Trying to migrate to 10, I would like to keep octave. Have you found anything new? Having build the port and all dependencies with standard options, octave is segfaulting for me, too. Anyhow, I can run octave with: env LD_PRELOAD=/usr/lib/libc++.so.1 octave Unfortunately, you need to add USE_GCC=any to math/octave/Makefile, and rebuild it. You theni need to run ldd -a | more and search for shared libraries that are linked against both libc++ and libstdc++. Then, add USE_GCC=any to those ports' Makefile and recompile. I recall at least 4 that needed to be rebuilt, but only remember fltk and libgraphite2. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Re: libc++ vs. libstdc++ usage in the ports tree
On 11/14/2013 15:45, Steve Kargl wrote: On Thu, Nov 14, 2013 at 09:54:52AM +, David Chisnall wrote: On 13 Nov 2013, at 19:40, Dimitry Andric d...@freebsd.org wrote: On the other hand, different C++ standard libraries simply cannot be mixed. The internal implementations are usually completely different. This is not really news at all, certainly not to the ports people. :-) That said, it should still be possible to mix them in different libraries. The constraint from the wiki still applies: if you don't use STL types at library boundaries, then it should still work. If you do, then the libc++ and libstdc++ symbols will be mangled differently and so you will get link-time errors. In theory, if it links it should run... And in practice, it is broken. http://lists.freebsd.org/pipermail/freebsd-current/2013-November/046565.html QED Trying to migrate to 10, I would like to keep octave. Have you found anything new? Having build the port and all dependencies with standard options, octave is segfaulting for me, too. Anyhow, I can run octave with: env LD_PRELOAD=/usr/lib/libc++.so.1 octave Some very light testing indicates that it is working. Of course, this is not ideal. Maybe this gives a clue how to fix the octave port properly. Cheers, Jan Henrik ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: libc++ vs. libstdc++ usage in the ports tree
On Wed, 27 Nov 2013 19:31:44 +0100 Jan Henrik Sylvester wrote:
Trying to migrate to 10, I would like to keep octave. Have you found
anything new? Having build the port and all dependencies with standard
options, octave is segfaulting for me, too. Anyhow, I can run octave with:
env LD_PRELOAD=/usr/lib/libc++.so.1 octave
Some very light testing indicates that it is working. Of course, this is
not ideal.
Maybe this gives a clue how to fix the octave port properly.
I have a preliminary patch for math/octave that I wanted to test on
redports first, but it is down at the moment so here it is.Index: math/octave/Makefile
===
--- math/octave/Makefile (revision 335025)
+++ math/octave/Makefile (working copy)
@@ -32,7 +32,7 @@ LIB_DEPENDS= GraphicsMagick:${PORTSDIR}/
umfpack.1:${PORTSDIR}/math/suitesparse \
glpk:${PORTSDIR}/math/glpk
-USES= charsetfix gmake perl5 pkgconfig
+USES= charsetfix fortran gmake perl5 pkgconfig
USE_BZIP2= yes
USE_PERL5= build
USE_TEX= dvipsk:build
@@ -74,8 +74,6 @@ BLAS= -lptf77blas
LAPACK= -lalapack -lptcblas
.endif
-USE_FORTRAN= yes
-
OCTAVE_VERSION= ${PORTVERSION}
GNU_HOST= ${ARCH}-portbld-freebsd${OSREL}
PLIST_SUB= OCTAVE_VERSION=${OCTAVE_VERSION} GNU_HOST=${GNU_HOST}
@@ -140,7 +138,8 @@ post-install:
${ECHO_CMD} @dirrm share/octave ${WRKDIR}/PLIST
cd ${WRKDIR} ; ${SED} -i -e /PLIST/ r PLIST ${TMPPLIST}
-check:
+check: regression-test
+regression-test: build
(cd ${WRKSRC}; ${SETENV} ${MAKE_ENV} ${GMAKE} ${MAKE_ARGS} check)
.include bsd.port.post.mk
Index: math/octave/files/patch-configure
===
--- math/octave/files/patch-configure (revision 0)
+++ math/octave/files/patch-configure (working copy)
@@ -0,0 +1,11 @@
+--- configure.orig 2013-02-21 21:21:49.0 +0100
configure 2013-11-22 20:34:49.0 +0100
+@@ -58248,7 +58248,7 @@
+ main ()
+ {
+
+- std::unordered_map m;
++ std::unordered_mapint, int m;
+
+ ;
+ return 0;
Property changes on: math/octave/files/patch-configure
___
Added: fbsd:nokeywords
## -0,0 +1 ##
+yes
\ No newline at end of property
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No newline at end of property
Added: svn:mime-type
## -0,0 +1 ##
+text/plain
\ No newline at end of property
Index: math/octave/files/patch-libgnu-math.in.h
===
--- math/octave/files/patch-libgnu-math.in.h (revision 0)
+++ math/octave/files/patch-libgnu-math.in.h (working copy)
@@ -0,0 +1,11 @@
+--- libgnu/math.in.h.orig 2013-02-21 21:21:17.0 +0100
libgnu/math.in.h 2013-11-22 12:35:47.0 +0100
+@@ -17,7 +17,7 @@
+You should have received a copy of the GNU General Public License
+along with this program. If not, see http://www.gnu.org/licenses/. */
+
+-#ifndef _@GUARD_PREFIX@_MATH_H
++#if 1
+
+ #if __GNUC__ = 3
+ @PRAGMA_SYSTEM_HEADER@
Property changes on: math/octave/files/patch-libgnu-math.in.h
___
Added: fbsd:nokeywords
## -0,0 +1 ##
+yes
\ No newline at end of property
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No newline at end of property
Added: svn:mime-type
## -0,0 +1 ##
+text/plain
\ No newline at end of property
Index: math/octave/files/patch-liboctave-eigs-base.cc
===
--- math/octave/files/patch-liboctave-eigs-base.cc (revision 0)
+++ math/octave/files/patch-liboctave-eigs-base.cc (working copy)
@@ -0,0 +1,11 @@
+--- liboctave/eigs-base.cc.orig 2013-02-21 21:19:24.0 +0100
liboctave/eigs-base.cc 2013-11-22 20:19:19.0 +0100
+@@ -3832,7 +3832,7 @@
+ bool cholB = 0, int disp = 0, int maxit = 300);
+ #endif
+
+-#ifndef _MSC_VER
++#if !defined(_MSC_VER) !defined(__clang__)
+ template static octave_idx_type
+ lusolve (const SparseMatrix, const SparseMatrix, Matrix);
+
Property changes on: math/octave/files/patch-liboctave-eigs-base.cc
___
Added: svn:mime-type
## -0,0 +1 ##
+text/plain
\ No newline at end of property
Added: fbsd:nokeywords
## -0,0 +1 ##
+yes
\ No newline at end of property
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No newline at end of property
Index: Mk/Uses/fortran.mk
===
--- Mk/Uses/fortran.mk (revision 0)
+++ Mk/Uses/fortran.mk (working copy)
@@ -0,0 +1,32 @@
+# $FreeBSD$
+#
+# Establish Fortran-capable compiler as a build dependency
+#
+# MAINTAINER: po...@freebsd.org
+#
+# Feature: fortran
+# Usage: USES=fortran
+# Valid ARGS: does not require args
+
+.if !defined(_INCLUDE_USES_FORTRAN_MK)
+_INCLUDE_USES_FORTRAN_MK= yes
+
+.if defined(fortran_ARGS)
+IGNORE= USES=fortran does not require args
+.endif
+
Re: libc++ vs. libstdc++ usage in the ports tree
Hmm thanks for discussion. I'll install and test FBSD 10 in this weekend. thanks Nakata Maho From: Steve Kargl s...@troutmask.apl.washington.edu Subject: Re: Re: libc++ vs. libstdc++ usage in the ports tree Date: Wed, 27 Nov 2013 10:43:02 -0800 On Wed, Nov 27, 2013 at 07:31:44PM +0100, Jan Henrik Sylvester wrote: On 11/14/2013 15:45, Steve Kargl wrote: And in practice, it is broken. http://lists.freebsd.org/pipermail/freebsd-current/2013-November/046565.html QED Trying to migrate to 10, I would like to keep octave. Have you found anything new? Having build the port and all dependencies with standard options, octave is segfaulting for me, too. Anyhow, I can run octave with: env LD_PRELOAD=/usr/lib/libc++.so.1 octave Unfortunately, you need to add USE_GCC=any to math/octave/Makefile, and rebuild it. You theni need to run ldd -a | more and search for shared libraries that are linked against both libc++ and libstdc++. Then, add USE_GCC=any to those ports' Makefile and recompile. I recall at least 4 that needed to be rebuilt, but only remember fltk and libgraphite2. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: libc++ vs. libstdc++ usage in the ports tree
On 13 Nov 2013, at 19:40, Dimitry Andric d...@freebsd.org wrote: On the other hand, different C++ standard libraries simply cannot be mixed. The internal implementations are usually completely different. This is not really news at all, certainly not to the ports people. :-) That said, it should still be possible to mix them in different libraries. The constraint from the wiki still applies: if you don't use STL types at library boundaries, then it should still work. If you do, then the libc++ and libstdc++ symbols will be mangled differently and so you will get link-time errors. In theory, if it links it should run... David ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: libc++ vs. libstdc++ usage in the ports tree
Am 14.11.2013 10:54 (UTC+1) schrieb David Chisnall: On 13 Nov 2013, at 19:40, Dimitry Andric d...@freebsd.org wrote: On the other hand, different C++ standard libraries simply cannot be mixed. The internal implementations are usually completely different. This is not really news at all, certainly not to the ports people. :-) That said, it should still be possible to mix them in different libraries. The constraint from the wiki still applies: if you don't use STL types at library boundaries, then it should still work. If you do, then the libc++ and libstdc++ symbols will be mangled differently and so you will get link-time errors. In theory, if it links it should run... David With the in this thread described change of the behaviour in 10.x and HEAD, I have massive problems with building my port math/saga. Before the changes, all built and worked fine. Now, even when I add USES= compiler:openmp CXXFLAGS+= -std=gnu++0x and commenting out USE_GCC=any in the Makefile of math/saga, the build breaks with problems between x11-toolkits/wxgtk29 (build with clang) and math/saga (try to build with gcc46), see below, please. I am clueless, what to do here. Building x11-toolkits/wxgtk29 with gcc46+ is not an option. Any help is really appreciated, Rainer Hurling make -D MAKE_JOBS_UNSAFE=yes === Building for saga-2.1.0_2 --- all --- /usr/bin/make all-recursive --- all-recursive --- Making all in . Making all in src --- all-recursive --- Making all in saga_core --- all-recursive --- Making all in saga_api Making all in saga_odbc Making all in saga_gdi Making all in saga_cmd --- all-recursive --- Making all in man Making all in saga_gui --- all-recursive --- Making all in man --- saga_gui --- /bin/sh ../../../libtool --tag=CXX--mode=link g++46 -fPIC -D_SAGA_LINUX -D_TYPEDEF_BYTE -D_TYPEDEF_WORD -D_SAGA_DONOTUSE_HARU -DMODULE_LIBRARY_PATH=\/usr/local/lib/saga\ -DSHARE_PATH=\/usr/local/share/saga\ -I.. -I. `/usr/local/bin/wxgtk2u-2.9-config --unicode=yes --cxxflags` -D_SAGA_UNICODE -fopenmp -O2 -pipe -I/usr/local/include -Wl,-rpath=/usr/local/lib/gcc46 -fno-strict-aliasing -std=gnu++0x -Wl,-rpath=/usr/local/lib/gcc46 -fPIC `/usr/local/bin/wxgtk2u-2.9-config --unicode=yes --libs adv,aui,base,core,html,net,propgrid,xml` -L/usr/local/lib -lopencv_core -pthread -Wl,-rpath=/usr/local/lib/gcc46 -o saga_gui active.o active_attributes.o active_description.o active_history.o active_HTMLExtraInfo.o active_legend.o active_parameters.o callback.o data_source.o data_source_files.o data_source_odbc.o dc_helper.o dlg_about.o dlg_about_logo.o dlg_base.o dlg_colors.o dlg_colors_control.o dlg_list_base.o dlg_list_grid.o dlg_list_pointcloud.o dlg_list_shapes.o dlg_list_table.o dlg_list_tin.o dlg_parameters.o dlg_table.o dlg_text.o helper.o info.o info_messages.o parameters_control.o parameters_properties.o project.o res_commands.o res_controls.o res_dialogs.o res_images.o saga.o saga_frame.o saga_frame_droptarget.o view_base.o view_histogram.o view_layout.o view_layout_control.o view_layout_info.o view_layout_printout.o view_map.o view_map_3d.o view_map_3d_image.o view_map_control.o view_ruler.o view_scatterplot.o view_table.o view_table_control.o view_table_diagram.o wksp.o wksp_base_control.o wksp_base_item.o wksp_base_manager.o wksp_data_control.o wksp_data_item.o wksp_data_layers.o wksp_data_manager.o wksp_data_menu_file.o wksp_data_menu_files.o wksp_grid.o wksp_grid_manager.o wksp_grid_system.o wksp_layer.o wksp_layer_classify.o wksp_layer_legend.o wksp_map.o wksp_map_buttons.o wksp_map_control.o wksp_map_dc.o wksp_map_layer.o wksp_map_manager.o wksp_module.o wksp_module_control.o wksp_module_library.o wksp_module_manager.o wksp_module_menu.o wksp_pointcloud.o wksp_pointcloud_manager.o wksp_shapes.o wksp_shapes_edit.o wksp_shapes_line.o wksp_shapes_manager.o wksp_shapes_point.o wksp_shapes_points.o wksp_shapes_polygon.o wksp_shapes_type.o wksp_table.o wksp_table_manager.o wksp_tin.o wksp_tin_manager.o ../saga_api/libsaga_api.la ../saga_odbc/libsaga_odbc.la libtool: link: g++46 -fPIC -D_SAGA_LINUX -D_TYPEDEF_BYTE -D_TYPEDEF_WORD -D_SAGA_DONOTUSE_HARU -DMODULE_LIBRARY_PATH=\/usr/local/lib/saga\ -DSHARE_PATH=\/usr/local/share/saga\ -I.. -I. -I/usr/local/lib/wx/include/gtk2-unicode-2.9 -I/usr/local/include/wx-2.9 -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXGTK__ -pthread -D_THREAD_SAFE -D_SAGA_UNICODE -fopenmp -O2 -pipe -I/usr/local/include -Wl,-rpath=/usr/local/lib/gcc46 -fno-strict-aliasing -std=gnu++0x -Wl,-rpath=/usr/local/lib/gcc46 -fPIC -pthread -pthread -Wl,-rpath=/usr/local/lib/gcc46 -o .libs/saga_gui active.o active_attributes.o active_description.o active_history.o active_HTMLExtraInfo.o active_legend.o active_parameters.o callback.o data_source.o data_source_files.o data_source_odbc.o dc_helper.o dlg_about.o dlg_about_logo.o dlg_base.o dlg_colors.o dlg_colors_control.o dlg_list_base.o dlg_list_grid.o dlg_list_pointcloud.o dlg_list_shapes.o
Re: libc++ vs. libstdc++ usage in the ports tree
On Thu, Nov 14, 2013 at 09:54:52AM +, David Chisnall wrote: On 13 Nov 2013, at 19:40, Dimitry Andric d...@freebsd.org wrote: On the other hand, different C++ standard libraries simply cannot be mixed. The internal implementations are usually completely different. This is not really news at all, certainly not to the ports people. :-) That said, it should still be possible to mix them in different libraries. The constraint from the wiki still applies: if you don't use STL types at library boundaries, then it should still work. If you do, then the libc++ and libstdc++ symbols will be mangled differently and so you will get link-time errors. In theory, if it links it should run... And in practice, it is broken. http://lists.freebsd.org/pipermail/freebsd-current/2013-November/046565.html QED -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: libc++ vs. libstdc++ usage in the ports tree (was: Re: Are clang++ and libc++ compatible?)
https://wiki.freebsd.org/NewC++Stack says things about linking against both libc++ and libstdc++ , do they still apply? Best regards Andreas ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: libc++ vs. libstdc++ usage in the ports tree (was: Re: Are clang++ and libc++ compatible?)
On Wed, Nov 13, 2013 at 11:31 AM, Marcus von Appen m...@freebsd.org wrote: This brings up another point into which I am running with the previously discussed blender issue. Let's assume port A_defcompiler does not specify a compiler and c++ lib, it will default to libc++ and clang++ on 10.x or newer, correct? If now a port B_gnuish depends on port A_defcompiler, but at the same defines GCC + libstdc++, the resulting binary might link against libc++ and libstdc++ at the same time. This in turn makes the port unusable. The same applies to the other way around. Right now we do not have mechanism to detect and handle those flaws. Maintainers might be even less aware of those issues. Does anyone know a proper way to deal with this at the moment on 10.x+ or is this something that was missed until now? How different is this from the previous situation? As I understand it previously A_defcompiler would be linked against the system libstdc++ and B_gnuish would be linked against the gccXX port libstdc++. In my experience libstdc++ does not have good ABI stability between versions so shouldn't you have the same potential for problems? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: libc++ vs. libstdc++ usage in the ports tree (was: Re: Are clang++ and libc++ compatible?)
On Wed, Nov 13, 2013 at 12:52:16PM -0500, Ryan Stone wrote: On Wed, Nov 13, 2013 at 11:31 AM, Marcus von Appen m...@freebsd.org wrote: This brings up another point into which I am running with the previously discussed blender issue. Let's assume port A_defcompiler does not specify a compiler and c++ lib, it will default to libc++ and clang++ on 10.x or newer, correct? If now a port B_gnuish depends on port A_defcompiler, but at the same defines GCC + libstdc++, the resulting binary might link against libc++ and libstdc++ at the same time. This in turn makes the port unusable. The same applies to the other way around. Right now we do not have mechanism to detect and handle those flaws. Maintainers might be even less aware of those issues. Does anyone know a proper way to deal with this at the moment on 10.x+ or is this something that was missed until now? How different is this from the previous situation? As I understand it previously A_defcompiler would be linked against the system libstdc++ and B_gnuish would be linked against the gccXX port libstdc++. In my experience libstdc++ does not have good ABI stability between versions so shouldn't you have the same potential for problems? I haven't seen a problem with mixing the system's libstdc++ with a version from lang/gcc46. I can assure you that the problem is very really with libc++ vs libstdc++ within the ports collection. To getting working news/pan and math/octave, I had to recompile graphics/graphite2, graphics/libGL, graphics/libGLU, and x11-toolkits/fltk with USE_GCC=any to avoid the conflict. Fortunately, I have only another 360 installed ports to check for the conflict. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: libc++ vs. libstdc++ usage in the ports tree
on 13/11/2013 19:52 Ryan Stone said the following: In my experience libstdc++ does not have good ABI stability between versions In my experience it does. In either case compatibility between different versions of relatively modern libstdc++ version is no doubt much better than between libstdc++ and libc++. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: libc++ vs. libstdc++ usage in the ports tree
On 13 Nov 2013, at 19:51, Andriy Gapon a...@freebsd.org wrote: on 13/11/2013 19:52 Ryan Stone said the following: In my experience libstdc++ does not have good ABI stability between versions In my experience it does. In either case compatibility between different versions of relatively modern libstdc++ version is no doubt much better than between libstdc++ and libc++. Well, GNU libstdc++ is backwards compatible, so you can run programs originally linked against our 4.2.1 version of libstdc++.so, using the latest ports version of libstdc++.so, and they should work. (Not vice versa, but that is not a supported use case.) On the other hand, different C++ standard libraries simply cannot be mixed. The internal implementations are usually completely different. This is not really news at all, certainly not to the ports people. :-) -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail
