Re: library not found for -lgfortran
On Jul 7, 2014, at 11:28 PM, Mark Brethen wrote:
I was told that until a patch is submitted, I can just add
-L/opt/local/lib/gcc48 to the LDFLAGS environment variable. So I put this in
the portfile:
configure.ldflags-append -L${prefix}/lib/gcc48
I'm thinking that gcc48 should be replaced by a variable, but what do I use?
MacPorts doesn't provide a variable suitable for that. If you have gcc
variants, you could append to configure.ldflags in each variant, adjusting the
path as needed for each gcc version.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: jmol update haspatch maintainer
On Mon, Jul 7, 2014 at 11:55 AM, Peter Brommer wrote: Hiya, could one of the committers please take a peek at https://trac.macports.org/ticket/44128 ? I submitted an update ticket to jmol (of which I am the maintainer) a couple of days ago, and would now like to see it committed. Done. Thank you for the upload, Mojca ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [121795] trunk/dports/x11/xcircuit/Portfile
On 7/7/14, 11:51 PM, Ryan Schmidt wrote: On Jul 7, 2014, at 10:28 PM, khindenb...@macports.org wrote: Revision 121795 Author khindenb...@macports.org Date 2014-07-07 20:28:51 -0700 (Mon, 07 Jul 2014) Log Message xcircuit: update to 3.8.70 Modified Paths • trunk/dports/x11/xcircuit/Portfile Diff Modified: trunk/dports/x11/xcircuit/Portfile (121794 = 121795) --- trunk/dports/x11/xcircuit/Portfile 2014-07-08 02:49:46 UTC (rev 121794) +++ trunk/dports/x11/xcircuit/Portfile 2014-07-08 03:28:51 UTC (rev 121795) @@ -6,7 +6,7 @@ namexcircuit conflicts xcircuit-devel -version 3.8.68 +version 3.8.70 This conflict should also be removed. Thanks, done in r121803 Kurt ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: library not found for -lgfortran
On Jul 8, 2014, at 3:05 AM, Ryan Schmidt ryandes...@macports.org wrote:
On Jul 7, 2014, at 11:28 PM, Mark Brethen wrote:
I was told that until a patch is submitted, I can just add
-L/opt/local/lib/gcc48 to the LDFLAGS environment variable. So I put this in
the portfile:
configure.ldflags-append -L${prefix}/lib/gcc48
I'm thinking that gcc48 should be replaced by a variable, but what do I
use?
MacPorts doesn't provide a variable suitable for that. If you have gcc
variants, you could append to configure.ldflags in each variant, adjusting
the path as needed for each gcc version.
I have:
compilers.choosefc
compilers.setup -dragonegg -g95 require_fortran
if {![fortran_variant_isset]} {
default_variants-append +gcc48
}
configure.ldflags-append -L${prefix}/lib/gcc48 -lgfortran
If the user has set a different version of gcc this won't work.
Mark
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [121692] trunk/dports/sysutils
Thanks Ryan,
I fixed issues you suggested at r121804.
On Mon, 07 Jul 2014 14:51:49 -0500, Ryan Schmidt wrote:
On Jul 4, 2014, at 9:14 AM, kimu...@macports.org wrote:
Added: trunk/dports/sysutils/peco/Portfile (0 = 121692)
--- trunk/dports/sysutils/peco/Portfile (rev 0)
+++ trunk/dports/sysutils/peco/Portfile 2014-07-04 14:14:30 UTC (rev
121692)
@@ -0,0 +1,82 @@
+# $Id$
The modeline is missing, and there should be a blank line after the
$Id$ line.
+master_siteshttps://github.com/peco/peco/tarball/v${version}:peco
Since this project is hosted at github, consider using the github 1.0
portgroup. The multiple distfiles might however be a complication.
+destroot {
+xinstall ${worksrcpath}/peco ${destroot}/${prefix}/bin
+}
There's no need for quotes around those variables; this isn't a shell
script.
There should be no / before ${prefix} because ${prefix} already
begins with a slash.
--
kimura wataru
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: library not found for -lgfortran
On Jul 8, 2014, at 7:34 AM, Mark Brethen wrote:
On Jul 8, 2014, at 3:05 AM, Ryan Schmidt wrote:
On Jul 7, 2014, at 11:28 PM, Mark Brethen wrote:
I was told that until a patch is submitted, I can just add
-L/opt/local/lib/gcc48 to the LDFLAGS environment variable. So I put this
in the portfile:
configure.ldflags-append -L${prefix}/lib/gcc48
I'm thinking that gcc48 should be replaced by a variable, but what do I
use?
MacPorts doesn't provide a variable suitable for that. If you have gcc
variants, you could append to configure.ldflags in each variant, adjusting
the path as needed for each gcc version.
I have:
compilers.choosefc
compilers.setup -dragonegg -g95 require_fortran
if {![fortran_variant_isset]} {
default_variants-append +gcc48
}
configure.ldflags-append -L${prefix}/lib/gcc48 -lgfortran
If the user has set a different version of gcc this won't work.
Oh, you don't create the compiler variants manually; you have the compilers
portgroup do it for you. I'm not sure how the author of that portgroup intended
for this situation to be handled. Maybe it does provide a variable for the
currently–selected variant. Sean?
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: library not found for -lgfortran
Ryan Schmidt writes:
On Jul 8, 2014, at 7:34 AM, Mark Brethen wrote:
On Jul 8, 2014, at 3:05 AM, Ryan Schmidt wrote:
On Jul 7, 2014, at 11:28 PM, Mark Brethen wrote:
I was told that until a patch is submitted, I can just add
-L/opt/local/lib/gcc48 to the LDFLAGS environment variable. So I put this
in the portfile:
configure.ldflags-append -L${prefix}/lib/gcc48
I'm thinking that gcc48 should be replaced by a variable, but what do I
use?
MacPorts doesn't provide a variable suitable for that. If you have gcc
variants, you could append to configure.ldflags in each variant, adjusting
the path as needed for each gcc version.
I have:
compilers.choosefc
compilers.setup -dragonegg -g95 require_fortran
if {![fortran_variant_isset]} {
default_variants-append +gcc48
}
configure.ldflags-append -L${prefix}/lib/gcc48 -lgfortran
This kind of information can only be reliably found out at configure
time. In other words, why isn't the FreeCAD project figuring this out
based on the fortran compiler with a configure test?
If the user has set a different version of gcc this won't work.
Oh, you don't create the compiler variants manually; you have the compilers
portgroup do it for you. I'm not sure how the author of that portgroup
intended for this situation to be handled. Maybe it does provide a variable
for the currently–selected variant. Sean?
This situation smells awfully like something else is going on here. This
might mean that the linker should be FC instead of CC or CXX but that's
just a thought.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: library not found for -lgfortran
Sent from my iPhone
On Jul 8, 2014, at 10:47 AM, Sean Farley s...@macports.org wrote:
Ryan Schmidt writes:
On Jul 8, 2014, at 7:34 AM, Mark Brethen wrote:
On Jul 8, 2014, at 3:05 AM, Ryan Schmidt wrote:
On Jul 7, 2014, at 11:28 PM, Mark Brethen wrote:
I was told that until a patch is submitted, I can just add
-L/opt/local/lib/gcc48 to the LDFLAGS environment variable. So I put this
in the portfile:
configure.ldflags-append -L${prefix}/lib/gcc48
I'm thinking that gcc48 should be replaced by a variable, but what do I
use?
MacPorts doesn't provide a variable suitable for that. If you have gcc
variants, you could append to configure.ldflags in each variant, adjusting
the path as needed for each gcc version.
I have:
compilers.choosefc
compilers.setup -dragonegg -g95 require_fortran
if {![fortran_variant_isset]} {
default_variants-append +gcc48
}
configure.ldflags-append -L${prefix}/lib/gcc48 -lgfortran
This kind of information can only be reliably found out at configure
time. In other words, why isn't the FreeCAD project figuring this out
based on the fortran compiler with a configure test?
They are aware that this needs to be patched. In the meantime they suggested
setting it.
If the user has set a different version of gcc this won't work.
Oh, you don't create the compiler variants manually; you have the compilers
portgroup do it for you. I'm not sure how the author of that portgroup
intended for this situation to be handled. Maybe it does provide a variable
for the currently–selected variant. Sean?
This situation smells awfully like something else is going on here. This
might mean that the linker should be FC instead of CC or CXX but that's
just a thought.
I don't know. For now, maybe I should restrict it to gcc48 like so
compilers.setup -dragonegg -g95 -gcc +gcc48 require_fortran
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [121692] trunk/dports/sysutils
On Mon, Jul 7, 2014 at 4:12 PM, Aljaž Srebrnič g...@macports.org wrote: Should we start thinking about a golang PortGroup? Yeah, the amount of golang-using software has been slowly increasing lately, but not much of it has made it to MacPorts yet. Having a golang PortGroup would definitely make it easier to create the ports needed to bring some of these things to MacPorts. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: library not found for -lgfortran
Mark Brethen writes:
Sent from my iPhone
On Jul 8, 2014, at 10:47 AM, Sean Farley s...@macports.org wrote:
Ryan Schmidt writes:
On Jul 8, 2014, at 7:34 AM, Mark Brethen wrote:
On Jul 8, 2014, at 3:05 AM, Ryan Schmidt wrote:
On Jul 7, 2014, at 11:28 PM, Mark Brethen wrote:
I was told that until a patch is submitted, I can just add
-L/opt/local/lib/gcc48 to the LDFLAGS environment variable. So I put
this in the portfile:
configure.ldflags-append -L${prefix}/lib/gcc48
I'm thinking that gcc48 should be replaced by a variable, but what do
I use?
MacPorts doesn't provide a variable suitable for that. If you have gcc
variants, you could append to configure.ldflags in each variant,
adjusting the path as needed for each gcc version.
I have:
compilers.choosefc
compilers.setup -dragonegg -g95 require_fortran
if {![fortran_variant_isset]} {
default_variants-append +gcc48
}
configure.ldflags-append -L${prefix}/lib/gcc48 -lgfortran
This kind of information can only be reliably found out at configure
time. In other words, why isn't the FreeCAD project figuring this out
based on the fortran compiler with a configure test?
They are aware that this needs to be patched. In the meantime they suggested
setting it.
This is a big deal.
If the user has set a different version of gcc this won't work.
Oh, you don't create the compiler variants manually; you have the compilers
portgroup do it for you. I'm not sure how the author of that portgroup
intended for this situation to be handled. Maybe it does provide a variable
for the currently–selected variant. Sean?
This situation smells awfully like something else is going on here. This
might mean that the linker should be FC instead of CC or CXX but that's
just a thought.
I don't know. For now, maybe I should restrict it to gcc48 like so
compilers.setup -dragonegg -g95 -gcc +gcc48 require_fortran
You probably want just +gfortran (which points to the latest one in macports)
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: library not found for -lgfortran
Sent from my iPhone
On Jul 8, 2014, at 11:56 AM, Sean Farley s...@macports.org wrote:
Mark Brethen writes:
Sent from my iPhone
On Jul 8, 2014, at 10:47 AM, Sean Farley s...@macports.org wrote:
Ryan Schmidt writes:
On Jul 8, 2014, at 7:34 AM, Mark Brethen wrote:
On Jul 8, 2014, at 3:05 AM, Ryan Schmidt wrote:
On Jul 7, 2014, at 11:28 PM, Mark Brethen wrote:
I was told that until a patch is submitted, I can just add
-L/opt/local/lib/gcc48 to the LDFLAGS environment variable. So I put
this in the portfile:
configure.ldflags-append -L${prefix}/lib/gcc48
I'm thinking that gcc48 should be replaced by a variable, but what do
I use?
MacPorts doesn't provide a variable suitable for that. If you have gcc
variants, you could append to configure.ldflags in each variant,
adjusting the path as needed for each gcc version.
I have:
compilers.choosefc
compilers.setup -dragonegg -g95 require_fortran
if {![fortran_variant_isset]} {
default_variants-append +gcc48
}
configure.ldflags-append -L${prefix}/lib/gcc48 -lgfortran
This kind of information can only be reliably found out at configure
time. In other words, why isn't the FreeCAD project figuring this out
based on the fortran compiler with a configure test?
They are aware that this needs to be patched. In the meantime they suggested
setting it.
This is a big deal.
If the user has set a different version of gcc this won't work.
Oh, you don't create the compiler variants manually; you have the
compilers portgroup do it for you. I'm not sure how the author of that
portgroup intended for this situation to be handled. Maybe it does provide
a variable for the currently–selected variant. Sean?
This situation smells awfully like something else is going on here. This
might mean that the linker should be FC instead of CC or CXX but that's
just a thought.
I don't know. For now, maybe I should restrict it to gcc48 like so
compilers.setup -dragonegg -g95 -gcc +gcc48 require_fortran
You probably want just +gfortran (which points to the latest one in macports)
Is the lib path the same (L${prefix}/lib/gcc48 -lgfortran)?
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: library not found for -lgfortran
Mark Brethen writes:
Sent from my iPhone
On Jul 8, 2014, at 11:56 AM, Sean Farley s...@macports.org wrote:
Mark Brethen writes:
Sent from my iPhone
On Jul 8, 2014, at 10:47 AM, Sean Farley s...@macports.org wrote:
Ryan Schmidt writes:
On Jul 8, 2014, at 7:34 AM, Mark Brethen wrote:
On Jul 8, 2014, at 3:05 AM, Ryan Schmidt wrote:
On Jul 7, 2014, at 11:28 PM, Mark Brethen wrote:
I was told that until a patch is submitted, I can just add
-L/opt/local/lib/gcc48 to the LDFLAGS environment variable. So I put
this in the portfile:
configure.ldflags-append -L${prefix}/lib/gcc48
I'm thinking that gcc48 should be replaced by a variable, but what
do I use?
MacPorts doesn't provide a variable suitable for that. If you have gcc
variants, you could append to configure.ldflags in each variant,
adjusting the path as needed for each gcc version.
I have:
compilers.choosefc
compilers.setup -dragonegg -g95 require_fortran
if {![fortran_variant_isset]} {
default_variants-append +gcc48
}
configure.ldflags-append -L${prefix}/lib/gcc48 -lgfortran
This kind of information can only be reliably found out at configure
time. In other words, why isn't the FreeCAD project figuring this out
based on the fortran compiler with a configure test?
They are aware that this needs to be patched. In the meantime they
suggested setting it.
This is a big deal.
If the user has set a different version of gcc this won't work.
Oh, you don't create the compiler variants manually; you have the
compilers portgroup do it for you. I'm not sure how the author of that
portgroup intended for this situation to be handled. Maybe it does
provide a variable for the currently–selected variant. Sean?
This situation smells awfully like something else is going on here. This
might mean that the linker should be FC instead of CC or CXX but that's
just a thought.
I don't know. For now, maybe I should restrict it to gcc48 like so
compilers.setup -dragonegg -g95 -gcc +gcc48 require_fortran
You probably want just +gfortran (which points to the latest one in macports)
Is the lib path the same (L${prefix}/lib/gcc48 -lgfortran)?
Yes. It depends on the gcc48 port. The reason it exists is to
distinguish between variants that change the C/C++ compilers.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: gnupg12, gnupg users, please reply.
On 7/7/14 1:30 PM, Mihai Moldovan wrote: * On 07.07.2014 04:09 pm, David Evans wrote: The two ports that I am most interested in are GNOME gcr and gpgme (a dependency of seahorse). gcr will build with either gnupg or gnupg2 but it checks gnupg first so if both are installed it will select gnupg. A simple patch will fix this. gpgme is currently at version 1.4.2 which only uses gnupg but is outdated but 1.4.3+ can use gnupg2 and prefers it over gnupg. Both systems are non-deterministic. Trace mode enforces determinism in this case, but it's still a good idea to force the GPG version explicitly (even more so, as trace mode is not the default.) As the maintainer, what do you prefer? There are three options: - stick with gnupg - switch to gnupg2 - select gnupg or gnupg2 via variants (can be coupled with some glue TCL code to set default variant to either prefer gnupg or gnupg2 if both are installed, the currently installed port if only one is installed, automatically select gnupg or gnupg2 based on your preference if none is installed or having the user override any automatic detection by explicitly selecting a variant) My preference is to try and be guided by the spirit of the upstream developers and how they configure their project. So, I vote to leave gcr depending on gnupg for now, since it doesn't use the extra capabilities of gnupg2, the configure file only falls back to gnupg2 if gnupg is not installed and there is no configure option to specify which one you want. Depending on gnupg, therefore, is the only way to ensure deterministic configuration in the case where both versions of gnupg are installed (without a patch). In the case of gpgme 1.5.0, it works the other way round. The package only falls back to gnupg if gnupg2 is not detected and again there is no way to specify which one you want. So depending on gnupg2 is the only way in this case to ensure you have a deterministic build. By the way, this package now does this version check logic at run time, not configure time, so changing its behavior is more challenging. I've gone ahead and updated gpgme to 1.5.0 using gnupg2 in r121819. I've kept gnupg2 as a lib dependency rather than a run dependency since it's needed for confidence checks that are run as part of the build and test phases. I think that applying similar logic to the rest of the gnupg dependents would yield a reasonable solution as to which version to use. If the package allows one to specify explicitly which version to use, I would go with gnupg2. Otherwise, I would use whichever version it favors and will provide a deterministic configuration. Dave ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: library not found for -lgfortran
On Jul 8, 2014, at 11:56 AM, Sean Farley s...@macports.org wrote: +gfortran I get this error: Error: Unable to open port: no such compiler: +gfortran Mark ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: library not found for -lgfortran
On Jul 8, 2014, at 6:31 PM, Mark Brethen mark.bret...@gmail.com wrote:
On Jul 8, 2014, at 11:56 AM, Sean Farley s...@macports.org wrote:
+gfortran
I get this error:
Error: Unable to open port: no such compiler: +gfortran
Mark
Nevermind, can't use '+'. I now have in the portfile
compilers.choosegfortran
compilers.setup require_fortran
if {![fortran_variant_isset]} {
default_variants-append +gcc48
}
configure.ldflags-append -L${prefix}/lib/gcc48 -lgfortran
I did some digging in the freecad source and found this in 'CMakeLists';
# Check Fortran#
INCLUDE(CMakeDetermineFortranCompiler)
This module can be found in /opt/local/share/cmake-3.0/Modules
Not sure why it doesn't work.
The c++ compiler is used for linking.
Mark
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: library not found for -lgfortran
Mark Brethen writes:
On Jul 8, 2014, at 6:31 PM, Mark Brethen mark.bret...@gmail.com wrote:
On Jul 8, 2014, at 11:56 AM, Sean Farley s...@macports.org wrote:
+gfortran
I get this error:
Error: Unable to open port: no such compiler: +gfortran
Mark
Nevermind, can't use '+'. I now have in the portfile
compilers.choosegfortran
gfortran is not a compiler type (e.g. cc, cxx, fc)
compilers.setup require_fortran
if {![fortran_variant_isset]} {
default_variants-append +gcc48
}
configure.ldflags-append -L${prefix}/lib/gcc48 -lgfortran
The reason this is bad is because the compiler itself might link with
other libraries (e.g. -lm). This is why testing for this in the
configure stage is *required*.
I did some digging in the freecad source and found this in 'CMakeLists';
# Check Fortran#
INCLUDE(CMakeDetermineFortranCompiler)
This module can be found in /opt/local/share/cmake-3.0/Modules
Not sure why it doesn't work.
Just set gcc48 as before. The port group itself will take care of what
to call the variant (I forgot about that; sorry).
The c++ compiler is used for linking.
Try setting 'configure.ld ${configure.fc}' in the pre-configure stage
and see if that works. It might not but is worth a shot.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: library not found for -lgfortran
On Jul 8, 2014, at 7:46 PM, Sean Farley s...@macports.org wrote:
Try setting 'configure.ld ${configure.fc}' in the pre-configure stage
and see if that works. It might not but is worth a shot.
:debug:configure Backtrace: invalid command name configure.ld
while executing
proc-pre-org.macports.configure-configure-2 org.macports.configure
(eval body line 1)
invoked from within
eval $pre $targetname
:info:configure Warning: targets not executed for freecad: org.macports.build
org.macports.configure
:notice:configure Please see the log file for port freecad for details:
/opt/local/var/macports/logs/_Users_marbre_ports_cad_freecad/freecad/main.log
This workaround was mentioned in the freecad forum (homebrew):
# Enable Fortran
libgfortran = `$FC --print-file-name libgfortran.a`.chomp
ENV.append 'LDFLAGS', -L#{File.dirname libgfortran} -lgfortran
inreplace CMakeLists.txt,
if(CMAKE_COMPILER_IS_GNUCXX)\nENABLE_LANGUAGE(Fortran)\nendif(CMAKE_COMPILER_IS_GNUCXX),
'ENABLE_LANGUAGE(Fortran)'
Mark
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: library not found for -lgfortran
On Jul 8, 2014, at 8:21 PM, Mark Brethen mark.bret...@gmail.com wrote:
On Jul 8, 2014, at 7:46 PM, Sean Farley s...@macports.org wrote:
Try setting 'configure.ld ${configure.fc}' in the pre-configure stage
and see if that works. It might not but is worth a shot.
:debug:configure Backtrace: invalid command name configure.ld
while executing
proc-pre-org.macports.configure-configure-2 org.macports.configure
(eval body line 1)
invoked from within
eval $pre $targetname
:info:configure Warning: targets not executed for freecad: org.macports.build
org.macports.configure
:notice:configure Please see the log file for port freecad for details:
/opt/local/var/macports/logs/_Users_marbre_ports_cad_freecad/freecad/main.log
This workaround was mentioned in the freecad forum (homebrew):
# Enable Fortran
libgfortran = `$FC --print-file-name libgfortran.a`.chomp
ENV.append 'LDFLAGS', -L#{File.dirname libgfortran} -lgfortran
inreplace CMakeLists.txt,
if(CMAKE_COMPILER_IS_GNUCXX)\nENABLE_LANGUAGE(Fortran)\nendif(CMAKE_COMPILER_IS_GNUCXX),
'ENABLE_LANGUAGE(Fortran)'
Mark
The patch applies to this block in 'CMakeLists':
if (${CMAKE_CXX_COMPILER_ID} MATCHES Clang)
set(CMAKE_COMPILER_IS_CLANGXX TRUE)
endif (${CMAKE_CXX_COMPILER_ID} MATCHES Clang)
if(CMAKE_COMPILER_IS_GNUCXX OR CMAKE_COMPILER_IS_CLANGXX)
# Needed for salomesmesh
ENABLE_LANGUAGE(Fortran)
include(cMake/ConfigureChecks.cmake)
configure_file(config.h.cmake ${CMAKE_CURRENT_BINARY_DIR}/config.h)
add_definitions(-DHAVE_CONFIG_H)
set(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} -Wno-deprecated -Wno-write-strings)
INCLUDE_DIRECTORIES(${CMAKE_CURRENT_BINARY_DIR})
# get linker errors as soon as possible and not at runtime e.g. for modules
if(UNIX)
#SET(CMAKE_SHARED_LINKER_FLAGS -Wl,--no-undefined)
endif(UNIX)
endif(CMAKE_COMPILER_IS_GNUCXX OR CMAKE_COMPILER_IS_CLANGXX)
Mark
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
gnubg: proposal of portfile update
Dear all, I would like to update the gnubg port to the current version. Could you please check a proposing portfile and a patch that are attached on this mail? Thank you very much. Regards, Daisuke Takahashi canberra-condition_playSoundFile_sound-c.diff Description: Binary data Portfile Description: Binary data ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: gnubg: proposal of portfile update
On Tue, Jul 8, 2014 at 11:24 PM, Daisuke Takahashi dtakaha...@macports.org wrote: I would like to update the gnubg port to the current version. Could you please check a proposing portfile and a patch that are attached on this mail? You might want to subscribe to macports-dev for this kind of thing. https://lists.macosforge.org/mailman/listinfo/macports-dev/ -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
pyport.h FreeBSD/Mac OS X fix causes errors in C++ compilation
During build of freecad I'm seeing errors of this type: :info:build /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/__locale:436:15: error: C++ requires a type specifier for all declarations :info:build char_type toupper(char_type __c) const :info:build ^~ :info:build /opt/local/Library/Frameworks/Python.framework/Versions/2.7/Headers/pyport.h:731:29: note: expanded from macro 'toupper' I was directed to the python bug report tracker at http://bugs.python.org/issue10910 There is a patch available, which I don't believe has been implemented. I'll submit a ticket. Mark ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
