Re: clang-3.8 crashes dsymutil with -gdwarf-4 on 10.9

2017-02-28 Thread Mihai Moldovan
On 01.03.2017 04:19 AM, Jeremy Huddleston Sequoia wrote:
> What's the output of this on your system:
> 
>/usr/bin/dsymutil --version

@(#)PROGRAM:dsymutil  PROJECT:dwarfutils-119

(Incidentally matches the path in the program's assertion, I just noticed.)


> I don't see the issue using current versions (llvm-3.8+, Xcode 8.x) of 
> llvm-dsymutil.  I suspect the issue here is that we should be updating the 
> driver to use its llvm-dsymutil instead of /usr/bin/dsymutil.

Well, yes. Your dsymutil is newer - mine's from Xcode 6.2.


You're right - llvm-dysmutil-mp-3.* works fine on binaries compiled with our
clang versions, although I haven't tested all combinations, just
llvm-dsymutil-mp-3.x with clang-mp-3.x with x being the same number.

However, I have noticed that LLVM's dsymutil does not behave like Apple's
dsymutil based upon its version. For instance, the LLVM 3.7-based dsymutil
creates a dSYM file, while 3.8 and newer create a dSYM directory, like Apple's
dsymutil.


> Please file a ticket.

Okay, but where exactly? MacPorts or LLVM upstream? It's probably best to always
make the driver use the LLVM-based dsymutil version, so uptream?



Mihai



signature.asc
Description: OpenPGP digital signature


Re: [146082] trunk/dports/audio

2017-02-28 Thread Ryan Schmidt

> On Feb 26, 2016, at 08:42, mo...@macports.org wrote:
> 
> Revision
> 146082
> Author
> mo...@macports.org
> Date
> 2016-02-26 06:42:27 -0800 (Fri, 26 Feb 2016)
> Log Message
> 
> audacity: new port (maintainer, closes #47189)
> Added Paths
> 
>   • trunk/dports/audio/audacity/
>   • trunk/dports/audio/audacity/Portfile
>   • trunk/dports/audio/audacity/files/
>   • trunk/dports/audio/audacity/files/FFmpeg_build_against_ffmpeg.diff
>   • trunk/dports/audio/audacity/files/add_enGB_translation.diff
>   • trunk/dports/audio/audacity/files/add_missing_newline.diff
>   • trunk/dports/audio/audacity/files/buildinfo-clarify-no-gstreamer.diff
>   • trunk/dports/audio/audacity/files/debian/
>   • trunk/dports/audio/audacity/files/debian/patches/
>   • 
> trunk/dports/audio/audacity/files/debian/patches/fix-minsrc-autoreconf.patch
>   • 
> trunk/dports/audio/audacity/files/debian/patches/workaround-wxwidgets-fit-recovery.patch
>   • trunk/dports/audio/audacity/files/libvamp-Makefile-for-osx.diff
>   • 
> trunk/dports/audio/audacity/files/patch-avoid-clang-choke-on-confbase.diff
>   • trunk/dports/audio/audacity/files/patch-fix-audiounits.diff
>   • 
> trunk/dports/audio/audacity/files/patch-libnyquist-symbol-visibility.diff
>   • trunk/dports/audio/audacity/files/patch-more-decent-font-sizes.diff
>   • trunk/dports/audio/audacity/files/patch-no-rtld_deepbind.diff
>   • trunk/dports/audio/audacity/files/patch-python.diff
>   • trunk/dports/audio/audacity/files/patch-vstcontrolosx.diff
>   • trunk/dports/audio/audacity/files/portaudio-no-universal-build.diff
>   • trunk/dports/audio/audacity/files/src-Makefile-for-osx.diff
> Diff
> 
> Added: trunk/dports/audio/audacity/Portfile (0 => 146082)
> 
> --- trunk/dports/audio/audacity/Portfile  (rev 0)
> +++ trunk/dports/audio/audacity/Portfile  2016-02-26 14:42:27 UTC (rev 
> 146082)
> 
> @@ -0,0 +1,193 @@
> 
> +# -*- coding: utf-8; mode: tcl; tab-width: 4; truncate-lines: t; 
> indent-tabs-mode: nil; c-basic-offset: 4 -*- vim:fenc=utf-8:et:sw=4:ts=4:sts=4
> +# kate: backspace-indents true; indent-pasted-text true; indent-width 4; 
> keep-extra-spaces true; remove-trailing-spaces modified; replace-tabs true; 
> replace-tabs-save true; syntax Tcl/Tk; tab-indents true; tab-width 4;
> +
> +PortSystem  1.0
> +PortGroup   wxWidgets 1.0
> +
> +nameaudacity
> +version 2.1.2
> +
> +# use the release tarball from github because it contains all required 
> external libs
> +# incl. those not in MacPorts.
> +PortGroup   github 1.0
> +github.setupaudacity audacity ${version} Audacity-
> +github.tarball_from releases
> +master_siteshttps://github.com/audacity/audacity/archive/
> 
> +distnameAudacity-${version}
> +checksums   rmd160  4e0c508b8edd24935a235c0b1a636c4ef1ae59a9 \
> +sha256  
> 90007b50cdc3885607b1afef2f158777a61c1658e869a88ec4d98c59c133f9bd
> +
> +post-extract {
> +file rename ${workpath}/audacity-Audacity-${version} 
> ${workpath}/${distname}
> +}

But you're not using a release tarball. You're telling MacPorts to use a 
release tarball ("github.tarball_from releases"), then on the next line telling 
MacPorts not to do that by overriding the master_sites. You shouldn't need to 
do that, nor should you need to rename a directory in post-extract. Consult the 
documentation in the comments at the top of the github portgroup for proper 
usage of this portgroup.




Re: [macports-ports] branch master updated: smlr: new port

2017-02-28 Thread Ryan Schmidt

> On Feb 28, 2017, at 07:56, Kurt Hindenburg  wrote:
> 
> Kurt Hindenburg (kurthindenburg) pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/6262d02ad4539a02372e9959b8a653ba2d03b043
> 
> The following commit(s) were added to refs/heads/master by this push:
> 
>  new 6262d02  smlr: new port
> 
>  new c8ad1a4  Merge branch 'master' of github.com:macports/macports-ports
> 
> 6262d02 is described below
> 
> 
> commit 6262d02ad4539a02372e9959b8a653ba2d03b043
> 
> Author: Kurt Hindenburg 
> AuthorDate: Tue Feb 28 08:54:46 2017 -0500
> 
> 
> smlr: new port
> 
> 
> 
> closes https://trac.macports.org/ticket/53478
> 
> ---
>  sysutils/smlr/Portfile  | 32 
>  sysutils/smlr/files/patch-Makefile.diff | 53 
> +
>  2 files changed, 85 insertions(+)
> 
> 
> diff --git a/sysutils/smlr/Portfile b/sysutils/smlr/Portfile
> 
> new file mode 100644
> 
> index 000..7362a3f
> 
> --- /dev/null
> 
> +++ b/sysutils/smlr/Portfile
> 
> @@ -0,0 +1,32 @@
> 
> +# -*- coding: utf-8; mode: tcl; tab-width: 2; indent-tabs-mode: nil; 
> c-basic-offset: 2 -*- vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4
> 
> +
> 
> +PortSystem  1.0
> 
> +PortGroup   github 1.0
> 
> +
> 
> +github.setupthenatefisher smlr 0.0.6
> 
> +categories  sysutils
> 
> +platforms   darwin
> 
> +license MIT
> 
> +maintainers @thenatefisher openmaintainer
> 
> +
> 
> +homepagehttps://github.com/thenatefisher/smlr
> 
> +
> 
> +description Text truncation utility
> 
> +long_descriptionsmlr reduces the size of a text input based on \
> 
> +specified parameters. It makes your string smaller, if it's too big.
> 
> +
> 
> +checksums   sha256  
> 4641de211cd5d7ab7df5508568cf885920dce0046900c73656f5a5d6a81e7982 \
> 
> +rmd160  95a6d0a71604993b31bbb4c468299e176ad028d2
> 
> +
> 
> +patchfiles  patch-Makefile.diff
> 
> +
> 
> +variant universal {}
> 
> +
> 
> +use_configure   no
> 
> +
> 
> +build.env   CC="${configure.cc}" \
> 
> +CFLAGS="${configure.cflags} [get_canonical_archflags 
> cc]" \
> 
> +LDFLAGS="${configure.ldflags} [get_canonical_archflags 
> ld]" \
> 
> +PREFIX=${prefix}
> 
> +
> 
> +destroot.envPREFIX=${destroot}${prefix}
> 
> diff --git a/sysutils/smlr/files/patch-Makefile.diff 
> b/sysutils/smlr/files/patch-Makefile.diff
> 
> new file mode 100644
> 
> index 000..85fcadb
> 
> --- /dev/null
> 
> +++ b/sysutils/smlr/files/patch-Makefile.diff
> 
> @@ -0,0 +1,53 @@
> 
> +--- Makefile 2017-02-03 03:41:09.0 -0500
> 
>  Makefile 2017-02-28 08:52:27.0 -0500
> 
> +@@ -1,47 +1,19 @@
> 
> + SRC_DIR =src
> 
> + BUILD_DIR   =build
> 
> +-TESTS_DIR   =tests
> 
> +-GTEST_DIR   =googletest/googletest
> 
> +-GTEST_INC   =-I$(GTEST_DIR)/include -I$(GTEST_DIR)/include/gtest 
> -I$(GTEST_DIR)/include/gtest/internal
> 
> +-INSTALL_DIR =opt/local/bin
> 
> + 
> 
> + all : $(BUILD_DIR)/rel/smlr
> 
> + 
> 
> +-test : $(BUILD_DIR)/rel/smlr_ut
> 
> +-@git submodule  update --init
> 
> +-@$(BUILD_DIR)/rel/smlr_ut
> 
> +-
> 
> + install : $(BUILD_DIR)/rel/smlr
> 
> +-cp $^ $(DESTDIR)/$(INSTALL_DIR)
> 
> ++cp $^ $(PREFIX)/bin/
> 

I'd rather not see a patch that removes DESTDIR support from a Makefile. We 
prefer DESTDIR support. I agree the way in which the Makefile was supporting 
changing the prefix (using the INSTALL_DIR variable) was sub-optimal, but I'd 
rather see a patch that fixes that while retaining the DESTDIR support.





Re: clang-3.8 crashes dsymutil with -gdwarf-4 on 10.9

2017-02-28 Thread Jeremy Huddleston Sequoia
What's the output of this on your system:

   /usr/bin/dsymutil --version

I don't see the issue using current versions (llvm-3.8+, Xcode 8.x) of 
llvm-dsymutil.  I suspect the issue here is that we should be updating the 
driver to use its llvm-dsymutil instead of /usr/bin/dsymutil.

Please file a ticket.

--Jeremy

> On Feb 26, 2017, at 02:51, Mihai Moldovan  wrote:
> 
> Actually, this is enough to trigger an assertion failure (albeit a different 
> one):
> 
> <-snip->
> #include 
> #include 
> 
> int main (int argc, char **argv) {
> std::cerr << std::endl;
> 
> return (EXIT_SUCCESS);
> }
> <-snip->
> 
> Assertion failed: (linked_addr_pos != line_table_map.end()), function 
> FixReferences, file 
> /SourceCache/dwarf_utilities/dwarf_utilities-119/source/DWARFdSYM.cpp, line 
> 3749.
> 
> Tested and reproduced with both clang 3.7 and 3.8.
> 
> Unreproducible with Xcode clang.
> 
> When compiled with clang 3.9, dsymutil spews out warnings, but *doesn't* trip 
> on an assertion:
> 
> warning: {0x4026} TAG_formal_parameter:  AT_location( 0x001fdc11 ) didn't 
> have valid function low pc, the location list will be incorrect.
> warning: {0x4054} TAG_formal_parameter:  AT_location( 0x2f91 ) didn't 
> have valid function low pc, the location list will be incorrect.
> 
> 
> 
> Mihai
> 



Re: Warning: reinplace ... didn't change anything in ...

2017-02-28 Thread Brandon Allbery
On Tue, Feb 28, 2017 at 2:30 PM, Ryan Schmidt 
wrote:

>
> On Feb 28, 2017, at 06:34, Brandon Allbery wrote:
>
> > Is there a convenient way to silence it? For example, I can imagine a
> reinplace intended to allow replacement of /opt/local with an alternate
> prefix, which will in most cases trigger the warning.
>
> Continue reading the rest of my first message. I explain how to do that.
>

Yes, sorry. After sending that I realized I wasn't quite right and
collapsed back into bed for another couple hours of fitful sleep. :/

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net


Re: Warning: reinplace ... didn't change anything in ...

2017-02-28 Thread Ryan Schmidt

On Feb 28, 2017, at 06:34, Brandon Allbery wrote:

> Is there a convenient way to silence it? For example, I can imagine a 
> reinplace intended to allow replacement of /opt/local with an alternate 
> prefix, which will in most cases trigger the warning.

Continue reading the rest of my first message. I explain how to do that.



Testing

2017-02-28 Thread Craig Treleaven
Mary had a little lamb…that was delicious with red wine!

Try the old and new -dev list addresses.

Craig

Re: Warning: reinplace ... didn't change anything in ...

2017-02-28 Thread Brandon Allbery
On Mon, Feb 27, 2017 at 1:10 PM, Ryan Schmidt 
wrote:

> MacPorts 2.4.1 shows a new warning when a reinplace command doesn't change
> anything. The purpose of reinplace is to change something in a file, so
> when that doesn't happen, it may be a developer error that we want to alert
> the developer about. Portfile developers should remove these warnings in
> the appropriate way, which may be to fix the reinplace or use a patchfile
> instead; remove the reinplace; or silence the warning.


Is there a convenient way to silence it? For example, I can imagine a
reinplace intended to allow replacement of /opt/local with an alternate
prefix, which will in most cases trigger the warning.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net


Re: Warning: reinplace ... didn't change anything in ...

2017-02-28 Thread Mojca Miklavec
On 28 February 2017 at 01:02, Jeremy Lavergne wrote:
> On 02/27/2017 01:10 PM, Ryan Schmidt wrote:
>>
>> MacPorts 2.4.1 shows a new warning when a reinplace command doesn't change 
>> anything. The purpose of reinplace is to change something in a file, so when 
>> that doesn't happen, it may be a developer error that we want to alert the 
>> developer about.
>
> Can buildbot report on this at warning levels?

We can put some regex to make buildbot recognise those lines as
warnings in the same way as build warnings generated by the compiler.

(But realistically unless developers will get an email, nobody will
look at those anyway.)

Mojca