Re: Getting the entire configure.cflags variable
On 2014-10-4 11:09 , Ryan Schmidt wrote: On Oct 3, 2014, at 4:47 PM, Joshua Root wrote: On 2014-10-4 07:04 , Ryan Schmidt wrote: -arch flags may or may not be doable. Joshua previously thought this was not fixable. Depends what you mean by this and fixable. Certainly it's impossible for any variable that can be read at any point to always reflect the existence of a variant that may not have been defined yet. Right, precisely that is the difficult bit. But what about this: we already have the variable universal_variant. Ports can set universal_variant no to disable the standard universal variant, or set universal_variant yes to have it added. We could trace that variable to change the -arch flags in the various *flags variables. That doesn't really buy us much, does it? The flags still wouldn't necessarily contain their final values before universal_variant is set. Getting back to the original question of the thread, there would be no problem providing a way to see what it looks like the eventual CFLAGS would contain, given the information that is currently known. What we can't do is know how the input variables are going to change later in the portfile. - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Getting the entire configure.cflags variable
On Oct 4, 2014, at 3:47 AM, Joshua Root wrote:
On 2014-10-4 11:09 , Ryan Schmidt wrote:
On Oct 3, 2014, at 4:47 PM, Joshua Root wrote:
On 2014-10-4 07:04 , Ryan Schmidt wrote:
-arch flags may or may not be doable. Joshua previously thought this was
not fixable.
Depends what you mean by this and fixable. Certainly it's impossible
for any variable that can be read at any point to always reflect the
existence of a variant that may not have been defined yet.
Right, precisely that is the difficult bit. But what about this: we already
have the variable universal_variant. Ports can set universal_variant no
to disable the standard universal variant, or set universal_variant yes to
have it added. We could trace that variable to change the -arch flags in the
various *flags variables.
That doesn't really buy us much, does it? The flags still wouldn't
necessarily contain their final values before universal_variant is set.
In a portfile I can always use if {[variant_isset universal]} to determine if
the universal variant is set. I was assuming the code I'm proposing adding to
base to add the -arch flags to configure.cflags et al would do the same.
Getting back to the original question of the thread, there would be no
problem providing a way to see what it looks like the eventual CFLAGS
would contain, given the information that is currently known. What we
can't do is know how the input variables are going to change later in
the portfile.
The original question was about being able to write:
configure.args-append CFLAGS=${configure.cflags}
I think even today we already understand that when we reference a variable like
that, we're evaluating the variable at that point, and not getting any change
that might be made to the variable later.
In fact in the petsc port this is already being done in a pre-configure block
so any changes to the variable later in the portfile will be observed.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Include file clobbering / Reinplace strange behavior
Guys,
I’m writing an updating port for the new version of gis/gdal.
However, the port does not compile because a .h file installed by the old
version into ${prefix}/include masks a new version of the same .h bundled with
the newest source.
So question 1: is there a standard workaround to address this problem?
I know the cleanest way is to switch the -I flags order so that the local
include repertory is placed before ${prefix}/include on the compiler line
invocation. However, that’s a pain to implement.
So, I decided to copy the culprit .h file, giving the copy a slightly different
name, then change all #include to this new name. Finally, I use find(1) to
locate every relevant file like this:
post-extract {
file copy ${worksrcpath}/port/cpl_port.h ${worksrcpath}/port/Cpl_port.h
set files_to_patch [exec find ${worksrcpath} -type f -exec grep -l
cpl_port.h \{\} \;]
foreach file ${files_to_patch} {
# DEBUG
puts ${file}
reinplace s|cpl_port.h|Cpl_port.h| ${file}
}
}
However, the procedure fails at a certain point for an unknown reason:
/opt/…/frmts/grib/degrib18/degrib/grib2api.c
/opt/…/frmts/grib/degrib18/degrib/inventory.cpp
/opt/…/frmts/grib/degrib18/degrib/memendian.h
/opt/…/frmts/grib/degrib18/degrib/metaname.cpp
sed: RE error: illegal byte sequence
So it works fine (I peeked inside the printed files and the substitution has
correctly been made) with ten or twenty files, then it suddenly breaks on a
mundane file.
Question 2: Does anyone have a clue why?
Thanks!
Vincent
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Include file clobbering / Reinplace strange behavior
Hi,
- On 4 Oct, 2014, at 16:25, Joshua Root j...@macports.org wrote:
I’m writing an updating port for the new version of gis/gdal.
However, the port does not compile because a .h file installed by the old
version into ${prefix}/include masks a new version of the same .h bundled
with
the newest source.
So question 1: is there a standard workaround to address this problem?
You can often use -isystem instead of -I.
Other workarounds to avoid the same problem are:
(1) using the deactivate hack for the old version
(2) using the conflicts-build portgroup (even though that will only print a
message)
(3) building in trace mode
Of course the canonical best solution would be upstream changing their
project in a way that makes all local -I directives appear before those
from $CPPFLAGS in the environment.
--
Clemens Lang
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
libxml2 issue on 10.10 beta
Yes, I know that 10.10 is not yet final. I'm also not 100% clear on what
the 10.10 beta license agreement I agreed to when installing it limits
me in saying. So, I'm going ahead anyway. :)
I do not experience this issue with libxml2 when running on 10.8 or
10.9; 10.10 is just special, somehow. Here's the reduced info from the
crash log, in the order it appears:
{{{
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libicucore.A.dylib 0x7fff9b5d05e3
0x7fff9b55b000 + 480739
1 libicucore.A.dylib 0x7fff9b5d19b7
ucnv_convertEx + 641
2 libxml2.2.dylib 0x7fff8f70eaf5
xmlUconvWrapper + 276
3 libxml2.2.dylib 0x7fff8f70f455
xmlCharEncOutput + 430
4 libxml2.2.dylib 0x00010fff6b9c
xmlOutputBufferFlush + 63
5 etree.so0x00010fe0dc15
__pyx_f_4lxml_5etree__tostring + 725
6 etree.so0x00010fe11321
__pyx_pw_4lxml_5etree_31tostring + 4721
...
0x10fda2000 -0x10feb6fff +etree.so (0)
28B36EFA-8496-32EF-B9F4-B5C9292EFD73
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/lxml/etree.so
...
0x10ffc5000 -0x1100bdff7 +libxml2.2.dylib (0)
D7C7F992-B9CC-3638-A430-E044E384C51A
/opt/local/lib/libxml2.2.dylib
...
0x7fff8f6fd000 - 0x7fff8f7e libxml2.2.dylib (26)
B834E7C8-EC3E-3382-BC5A-DA38DC4D720C /usr/lib/libxml2.2.dylib
...
0x7fff9b55b000 - 0x7fff9b740ff3 libicucore.A.dylib (531.30)
EF0E7544-E317-3550-A962-6AE65E78AF17 /usr/lib/libicucore.A.dylib
}}}
So ... I think what the above tells me is that MacPorts' libxml2.2.dylib
(#4) is calling Apple's libxml2.2.dylib (#3). That's a recipe for
disaster, and it shows since this application (running in Python)
crashes in a way that I'd expect when runtime ABIs are mixed -- for
example when using the MacPorts Python executable with a Python module
linked to Apple's Python library.
Thus far, it's been pretty simple to correct this issue by recompiling
using corrected LDFLAGS or using the correct executable matching the
ABI, or the like.
In this case, it's happening -within- the library, which makes no sense
to me. The otool -L for both libxml2.2.dylib's is as expected. Also,
both libraries provide symbols _xmlCharEncOutput and
_xmlOutputBufferFlush ... so, there does not seem to be a need for one
library to call the other.
What am I missing? Anybody have thoughts on other tests to determine
what's up, and/or how to correct this issue? Thanks in advance ... -
MLD
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: libxml2 issue on 10.10 beta
On Oct 4, 2014, at 2:47 PM, Michael Dickens michae...@macports.org wrote: In this case, it's happening -within- the library, which makes no sense to me. The otool -L for both libxml2.2.dylib's is as expected. Also, both libraries provide symbols _xmlCharEncOutput and _xmlOutputBufferFlush ... so, there does not seem to be a need for one library to call the other. What am I missing? Anybody have thoughts on other tests to determine what's up, and/or how to correct this issue? What does the linkage on etree.so look like? vq ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: libxml2 issue on 10.10 beta
On Sat, Oct 4, 2014, at 03:28 PM, Lawrence Velázquez wrote:
On Oct 4, 2014, at 2:47 PM, Michael Dickens michae...@macports.org
wrote:
In this case, it's happening -within- the library, which makes no sense
to me. The otool -L for both libxml2.2.dylib's is as expected. Also,
both libraries provide symbols _xmlCharEncOutput and
_xmlOutputBufferFlush ... so, there does not seem to be a need for one
library to call the other.
What am I missing? Anybody have thoughts on other tests to determine
what's up, and/or how to correct this issue?
What does the linkage on etree.so look like?
{{{
% otool -L
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/lxml/etree.so
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/lxml/etree.so:
/opt/local/lib/libxslt.1.dylib (compatibility version 3.0.0,
current version 3.28.0)
/opt/local/lib/libexslt.0.dylib (compatibility version 9.0.0,
current version 9.17.0)
/opt/local/lib/libxml2.2.dylib (compatibility version 12.0.0,
current version 12.1.0)
/opt/local/lib/libz.1.dylib (compatibility version 1.0.0,
current version 1.2.8)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 1213.0.0)
}}}
I also did, roughly:
{{{
(sudo find /opt/local -name *.dylib or *.so -print0 | xargs -0 otool
-L) | grep libxml2
}}}
and also included the library name when the linkage was found. I then
parsed that output all of it looks clean. This clearly does not
include executables, .apps, or other linked binaries.
I will admit that I did not yet parse -all- of the files in the crash
log yet to verify their linkage. I just did the most obvious suspects
plus the hammer method above. - MLD
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: libxml2 issue on 10.10 beta
I will admit that I did not yet parse -all- of the files in the crash
log yet to verify their linkage
I created a new file with just the binaries from the crash log, then:
{{{
% for tf in `cat crash_binaries_2.txt`; do fff=`otool -L $tf | grep
libxml2`; if [ ${fff} ]; then echo ${tf} : ${fff}; fi; done
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/lxml/etree.so
: /opt/local/lib/libxml2.2.dylib (compatibility version 12.0.0,
current version 12.1.0)
/opt/local/lib/libxslt.1.dylib :/opt/local/lib/libxml2.2.dylib
(compatibility version 12.0.0, current version 12.1.0)
/opt/local/lib/libexslt.0.dylib : /opt/local/lib/libxml2.2.dylib
(compatibility version 12.0.0, current version 12.1.0)
/opt/local/lib/libxml2.2.dylib : /opt/local/lib/libxml2.2.dylib:
/opt/local/lib/libxml2.2.dylib (compatibility version 12.0.0,
current version 12.1.0)
/System/Library/PrivateFrameworks/DataDetectorsCore.framework/Versions/A/DataDetectorsCore
:/usr/lib/libxml2.2.dylib (compatibility version 10.0.0, current
version 10.9.0)
/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/OpenScripting.framework/Versions/A/OpenScripting
:/usr/lib/libxml2.2.dylib (compatibility version 10.0.0, current
version 10.9.0)
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/ATS
: /usr/lib/libxml2.2.dylib (compatibility version 10.0.0, current
version 10.9.0)
/usr/lib/libxar.1.dylib : /usr/lib/libxml2.2.dylib (compatibility
version 10.0.0, current version 10.9.0)
/System/Library/Frameworks/CFNetwork.framework/Versions/A/CFNetwork :
/usr/lib/libxml2.2.dylib (compatibility version 10.0.0, current version
10.9.0)
/System/Library/PrivateFrameworks/UIFoundation.framework/Versions/A/UIFoundation
: /usr/lib/libxml2.2.dylib (compatibility version 10.0.0, current
version 10.9.0)
/System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore :
/usr/lib/libxml2.2.dylib (compatibility version 10.0.0, current
version 10.9.0)
/usr/lib/libxml2.2.dylib : /usr/lib/libxml2.2.dylib:
/usr/lib/libxml2.2.dylib (compatibility version 10.0.0, current
version 10.9.0)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation :
/usr/lib/libxml2.2.dylib (compatibility version 10.0.0, current
version 10.9.0)
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontParser.dylib
: /usr/lib/libxml2.2.dylib (compatibility version 10.0.0,
current version 10.9.0)
/usr/lib/libarchive.2.dylib : /usr/lib/libxml2.2.dylib (compatibility
version 10.0.0, current version 10.9.0)
/System/Library/Frameworks/WebKit.framework/Versions/A/Frameworks/WebCore.framework/Versions/A/WebCore
:/usr/lib/libxml2.2.dylib (compatibility version 10.0.0, current
version 10.9.0)
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit :
/usr/lib/libxml2.2.dylib (compatibility version 10.0.0, current version
10.9.0)
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/DictionaryServices.framework/Versions/A/DictionaryServices
:/usr/lib/libxml2.2.dylib (compatibility version 10.0.0, current
version 10.9.0)
/usr/lib/libxslt.1.dylib : /usr/lib/libxml2.2.dylib (compatibility
version 10.0.0, current version 10.9.0)
}}}
So ... it could be an indirect linkage between some MacPorts-provided
file, an Apple-provided system framework, and then Apple's
libxml2.2.dylib ... - MLD
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [126152] trunk/dports/gnome/evince/Portfile
On Oct 4, 2014, at 11:21 AM, dev...@macports.org wrote:
Revision
126152
Author
dev...@macports.org
Date
2014-10-04 09:21:18 -0700 (Sat, 04 Oct 2014)
Log Message
evince: disable browser-plugin on darwin 12 and earlier due to C++11 libc++
requirement.
Modified Paths
• trunk/dports/gnome/evince/Portfile
Diff
Modified: trunk/dports/gnome/evince/Portfile (126151 = 126152)
--- trunk/dports/gnome/evince/Portfile2014-10-04 15:32:35 UTC (rev
126151)
+++ trunk/dports/gnome/evince/Portfile2014-10-04 16:21:18 UTC (rev
126152)
@@ -72,6 +72,13 @@
--enable-comics \
--enable-t1lib
+# disable browser plugin on darwin 12 and earlier
+# due to requirement for -std=c++11 -stdlib=libc++
+
+if {${os.major} 13} {
+configure.args-append --disable-browser-plugin
+}
It is possible to configure MacPorts to use stdlib=libc++ on 10.8 and 10.7, and
possibly 10.6 with some extra work. So perhaps you should base this condition
on whether ${configure.cxx_stdlib} eq libstdc++, rather than on the OS
version.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
