Re: Is any clang version known to work in PPC/Tiger?

[Mojca Miklavec]

On 4 April 2016 at 00:44, César wrote:
> On 3 de April 2016, Mojca Miklavec wrote:
>> On 3 April 2016 at 22:13, César wrote:
>> > I've read that clang/llvm have been improving their PPC support over the
>> > years. But, is any version known to build?
>>
>> I have clang-3.4 installed on 10.5 PPC. Installing the latest versions
>> requires quite a bit of bootstrapping headaches:
>> https://trac.macports.org/wiki/LibcxxOnOlderSystems
>
> I tried several clang versions and port rejected to do so, telling that
> Intel was required. I don't remember if it was 3.4 or 3.3 the most recent
> version that didn't stop with that error (I think it was 3.3 but I'm not
> sure now).

I don't see anything obvious that would prevent one from compiling 3.3
on PPC, but I made just a short glimpse. In any case I would go for
3.4 rather than 3.3.

> BTW, reading that wiki link, makes me feel it's quite scary to use clang for
> distributable apps in anything older than Mountain Lion.

That should be "anything older that Lion". Lion comes with libc++
preinstalled. Only 10.6 and earlier lack that library. And even then
it's not about clang per se, but about using the latest versions of
clang which support C++11 and also require libc++. Version 3.4 works
with the default stdlibc++ installed on the system.

> Does that article
> mean that the users machines must install a working libc++ if the app has
> C++ code?

If the app has C++11 code, you won't even be able to compile it
without libc++ (or without libstdc++ version 3 & a recent GCC, but in
that case you would be facing exactly the same problem: you would have
to install a separate libstdc++).

But yes, if the app has C++ code and if you use clang > 3.4 (or maybe
> 3.5, I'm not sure), the binaries will link against libc++ that you
would have to ship with the binary.

> Can't executables be built statically without such requirement?

I never tested that, but it might work.

I know that TeX Live (http://tug.org/svn/texlive/trunk/Build/source/)
uses some hack to build against libstdc++ statically, so that the
binaries can be "universally" distributed.

And google finds a number of recipes. I have zero experience with
doing that on 10.5/PPC with the latest clang though.

> I'd prefer to move to clang in all my Macs because I like it more than gcc,
> but I'm beginning to feel it's wiser to keep using gcc in <10.8 Macs.

When you say "clang" you need to specify which version and whether or
not C++11 support is needed. 10.7 comes with libc++ and fully
functional clang/clang++ 3.2svn (with certain bugs every now and then
and cases when one needs to switch to a newer compiler). Even 10.6
comes with clang (but without clang++ and without libc++). And only
10.9 implemented support for C++11 by default.

You should be able to use version 3.4 on all systems, but using newer
versions might require a bit of extra effort.

Mojca
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: About mozjs24 being built

[Eneko Gotzon]

On Sun, Apr 3, 2016 at 4:53 PM, Brandon Allbery  wrote:

> xorg-server and xinit ports


If I recall correctly xinit is already included inside the xorg-server port.
-- 
Eneko Gotzon Ares
enekogot...@gmail.com
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Is any clang version known to work in PPC/Tiger?

[César]

On 3 de April 2016, Mojca Miklavec  wrote:

> On 3 April 2016 at 22:13, César wrote:
> > I've read that clang/llvm have been improving their PPC support over the
> > years. But, is any version known to build?
>
> I have clang-3.4 installed on 10.5 PPC. Installing the latest versions
> requires quite a bit of bootstrapping headaches:
> https://trac.macports.org/wiki/LibcxxOnOlderSystems
>

I tried several clang versions and port rejected to do so, telling that
Intel was required. I don't remember if it was 3.4 or 3.3 the most recent
version that didn't stop with that error (I think it was 3.3 but I'm not
sure now).

BTW, reading that wiki link, makes me feel it's quite scary to use clang
for distributable apps in anything older than Mountain Lion. Does that
article mean that the users machines must install a working libc++ if the
app has C++ code? Can't executables be built statically without such
requirement?

I'd prefer to move to clang in all my Macs because I like it more than gcc,
but I'm beginning to feel it's wiser to keep using gcc in <10.8 Macs.

Thanks!

César
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Is any clang version known to work in PPC/Tiger?

[Mojca Miklavec]

On 3 April 2016 at 22:13, César wrote:
> I've read that clang/llvm have been improving their PPC support over the
> years. But, is any version known to build?

I have clang-3.4 installed on 10.5 PPC. Installing the latest versions
requires quite a bit of bootstrapping headaches:
https://trac.macports.org/wiki/LibcxxOnOlderSystems
but it should build. (I tried to bootstrap with the help of 10.6, but
I ran into too many problems.)

See also:
http://www.csl.cornell.edu/~fang/sw/llvm/
and the link to GitHub.

> And, can it be used in
> production, or there's the risk of getting corrupted/nonworking binaries?

Please don't take my word for granted ...

It depends on what you mean with "production". Generally you should
get working binaries, but you should also be ready to deal with
problems way more often than on other platforms. (There are many
compiler-related problems even on x86_64.)

I would imagine that you would more often run into compile-time
problems than runtime problems. All that is pure speculation though.

Mojca
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Is any clang version known to work in PPC/Tiger?

[César]

I've read that clang/llvm have been improving their PPC support over the
years. But, is any version known to build? And, can it be used in
production, or there's the risk of getting corrupted/nonworking binaries?

Thanks!

César
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: About mozjs24 being built

[Joshua Root]

On 2016-4-4 01:46 , Clemens Lang wrote:

Hi Josh,

On Mon, Apr 04, 2016 at 01:06:50AM +1000, Joshua Root wrote:

MPL 2.0 is GPL compatible only by way of an optional clause that
allows relicensing under the GPL. Some software is under MPL-2 but has
an "Incompatible With Secondary Licenses" notice. If a port uses the
version of MPL-2 that does allow the relicensing then its license
should be listed as {MPL-2 LGPL-2.1+}. (You could list GPL-2+ and
AGPL-3+ in there too but it makes no practical difference.)


I'm aware of that. Still, it's probably the most common case that this
optional clause applies, and I'd argue it should be the default for this
reason -- especially because there is no documentation (that I could
find) that explains that you have to explicitly list (L)GPL.


Well, documentation can be written. :)


I think we should add an additional MPL-2-NoRelicensing (or "MPL-2
GPLConflict") license to denote the few ports that explicitly do not
have the exception.


Making the dual licensing explicit seems less confusing to me than 
calling the same license two different names.


- Josh
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: About mozjs24 being built

[Clemens Lang]

Hi Josh,

On Mon, Apr 04, 2016 at 01:06:50AM +1000, Joshua Root wrote:
> MPL 2.0 is GPL compatible only by way of an optional clause that
> allows relicensing under the GPL. Some software is under MPL-2 but has
> an "Incompatible With Secondary Licenses" notice. If a port uses the
> version of MPL-2 that does allow the relicensing then its license
> should be listed as {MPL-2 LGPL-2.1+}. (You could list GPL-2+ and
> AGPL-3+ in there too but it makes no practical difference.)

I'm aware of that. Still, it's probably the most common case that this
optional clause applies, and I'd argue it should be the default for this
reason -- especially because there is no documentation (that I could
find) that explains that you have to explicitly list (L)GPL.

I think we should add an additional MPL-2-NoRelicensing (or "MPL-2
GPLConflict") license to denote the few ports that explicitly do not
have the exception.


> Older MPL versions were also GPL incompatible, although software using
> them was often explicitly dual-licensed.

Yes, we should keep MPL-1 and MPL-1.1 as GPL-conflicting.

-- 
Clemens
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: About mozjs24 being built

[Andrea Giammarchi]

It looks like installing `xorg-server` and `xinit` won't solve the problem;
I had to install XQuartz a part.

Since that's the default backend for macports Gtk3, wouldn't make sense to
have it installed as Gtk3 dependency? Or, at least, as `gjs` one.

Anyway, thanks for the hint.

Best Regards

On Sun, Apr 3, 2016 at 3:53 PM, Brandon Allbery  wrote:

> On Sun, Apr 3, 2016 at 10:49 AM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> I've also noticed, after successfully installing `gjs`, that it doesn't
>> work anyway.
>>
>> ```
>> gjs -c 'imports.gi.Gtk.init(null);'
>>
>> (gjs 999): Gtk-WARNING **: cannot open display:
>> ```
>>
>
> Install XQuartz, either via the xquartz.macosforge.org installer or via
> MacPorts (xorg-server and xinit ports).
>
> --
> brandon s allbery kf8nh   sine nomine
> associates
> allber...@gmail.com
> ballb...@sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: About mozjs24 being built

[Joshua Root]

On 2016-4-4 00:45 , Clemens Lang wrote:

Hi,

On Sun, Apr 03, 2016 at 04:05:02PM +0200, Clemens Lang wrote:

Doesn't seem like it will:

$ port_binary_distributable.tcl -v mozjs24
"mozjs24" is not distributable because its license "mpl" conflicts with license "GPL-3+" 
of dependency "gdbm"


Actually, mozjs24's license is MPL-2.0, which is -- according to the
FSF's interpretation of things [1] -- compatible with GPL-3. Our license
check tooling, however, explicitly marks all MPL licenses as
incompatible with all GPL licenses [2]. I think that's a bug.

The GPL <-> MPL conflict was already there in the inital script
committed 5 years ago by Josh [3]. Josh, do you agree this is a bug?

[1] http://www.gnu.org/licenses/license-list.en.html#MPL-2.0
[2] 
https://trac.macports.org/browser/trunk/base/portmgr/jobs/port_binary_distributable.tcl?marks=91#L85
[3] https://trac.macports.org/changeset/75780


MPL 2.0 is GPL compatible only by way of an optional clause that allows 
relicensing under the GPL. Some software is under MPL-2 but has an 
"Incompatible With Secondary Licenses" notice. If a port uses the 
version of MPL-2 that does allow the relicensing then its license should 
be listed as {MPL-2 LGPL-2.1+}. (You could list GPL-2+ and AGPL-3+ in 
there too but it makes no practical difference.)


Older MPL versions were also GPL incompatible, although software using 
them was often explicitly dual-licensed.


- Josh
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: About mozjs24 being built

[Brandon Allbery]

On Sun, Apr 3, 2016 at 10:53 AM, Brandon Allbery 
wrote:

> Install XQuartz


I should mention that MacPorts defaults to building gtk with +x11 because
many gtk-using programs either do not build or do not work properly with
gtk +quartz. If you want to try it anyway, you would remove the gtk ports
and all dependents, install gtk2 and/or gtk3 with the +quartz variant, then
reinstall the dependents you need.

Some of those may fail to install (usual symptom is failure to find
gtk/x11.h). xchat/hexchat will build but won't scroll properly. Other
things may also behave strangely.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: About mozjs24 being built

[Clemens Lang]

Hi,

On Sun, Apr 03, 2016 at 03:49:01PM +0100, Andrea Giammarchi wrote:
> ```
> gjs -c 'imports.gi.Gtk.init(null);'
> 
> (gjs 999): Gtk-WARNING **: cannot open display:
> ```

That looks like you don't have XQuartz installed. MacPorts' copy of Gtk
uses an X11 backend, which requires that you have X installed.
Unfortunately the native Quartz backend of Gtk still had a couple of
issues when I last checked. Homebrew's default may be to use the Quartz
backend, which would explain why this works out of the box.

-- 
Clemens
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: About mozjs24 being built

[Brandon Allbery]

On Sun, Apr 3, 2016 at 10:49 AM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:

> I've also noticed, after successfully installing `gjs`, that it doesn't
> work anyway.
>
> ```
> gjs -c 'imports.gi.Gtk.init(null);'
>
> (gjs 999): Gtk-WARNING **: cannot open display:
> ```
>

Install XQuartz, either via the xquartz.macosforge.org installer or via
MacPorts (xorg-server and xinit ports).

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: About mozjs24 being built

[Andrea Giammarchi]

Thanks!

I've also noticed, after successfully installing `gjs`, that it doesn't
work anyway.

```
gjs -c 'imports.gi.Gtk.init(null);'

(gjs 999): Gtk-WARNING **: cannot open display:
```

This one also works on homebrew (I'm trying to test Gtk+ configuration
through both installers)

Any idea how to test gjs via macports? Am I missing something?

Thanks!





On Sun, Apr 3, 2016 at 3:05 PM, Clemens Lang  wrote:

> Hi,
>
> On Sun, Apr 03, 2016 at 02:24:28PM +0100, Andrea Giammarchi wrote:
> > Installing `gjs` brings in a lot of modules and `mozjs24` is one of
> > these.
> >
> > There are pre-built binaries via homebrew and `mozjs24` has been
> > around for very long time so it surprises me it needs to be built via
> > macports.
> >
> > It's also actually the only one that needs this step, everything else
> > is downloaded and directly installed.
> >
> > Not a big deal, just a matter of curiosity and a question: will it be
> > available as already built in the future?
>
> Doesn't seem like it will:
>
> $ port_binary_distributable.tcl -v mozjs24
> "mozjs24" is not distributable because its license "mpl" conflicts with
> license "GPL-3+" of dependency "gdbm"
>
> --
> Clemens
>
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: About mozjs24 being built

[Clemens Lang]

Hi,

On Sun, Apr 03, 2016 at 04:05:02PM +0200, Clemens Lang wrote:
> Doesn't seem like it will:
> 
> $ port_binary_distributable.tcl -v mozjs24
> "mozjs24" is not distributable because its license "mpl" conflicts with 
> license "GPL-3+" of dependency "gdbm"

Actually, mozjs24's license is MPL-2.0, which is -- according to the
FSF's interpretation of things [1] -- compatible with GPL-3. Our license
check tooling, however, explicitly marks all MPL licenses as
incompatible with all GPL licenses [2]. I think that's a bug.

The GPL <-> MPL conflict was already there in the inital script
committed 5 years ago by Josh [3]. Josh, do you agree this is a bug?

[1] http://www.gnu.org/licenses/license-list.en.html#MPL-2.0
[2] 
https://trac.macports.org/browser/trunk/base/portmgr/jobs/port_binary_distributable.tcl?marks=91#L85
[3] https://trac.macports.org/changeset/75780

-- 
Clemens
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: About mozjs24 being built

[Clemens Lang]

Hi,

On Sun, Apr 03, 2016 at 02:24:28PM +0100, Andrea Giammarchi wrote:
> Installing `gjs` brings in a lot of modules and `mozjs24` is one of
> these.
> 
> There are pre-built binaries via homebrew and `mozjs24` has been
> around for very long time so it surprises me it needs to be built via
> macports.
> 
> It's also actually the only one that needs this step, everything else
> is downloaded and directly installed.
> 
> Not a big deal, just a matter of curiosity and a question: will it be
> available as already built in the future?

Doesn't seem like it will:

$ port_binary_distributable.tcl -v mozjs24
"mozjs24" is not distributable because its license "mpl" conflicts with license 
"GPL-3+" of dependency "gdbm"

-- 
Clemens
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

About mozjs24 being built

[Andrea Giammarchi]

Hi everyone!

Installing `gjs` brings in a lot of modules and `mozjs24` is one of these.

There are pre-built binaries via homebrew and `mozjs24` has been around for
very long time so it surprises me it needs to be built via macports.

It's also actually the only one that needs this step, everything else is
downloaded and directly installed.

Not a big deal, just a matter of curiosity and a question: will it be
available as already built in the future?

Thanks for any outcome and Best Regards
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Unable to read CDs

[Paul Rands]

Thanks to everyone who has helped so far.

A fix for this does sound way over my head at the moment. Might just 
have to stick with a VM and use flow thru settings to access the drive.


Paul Rands
paul00...@gmail.com

On 3/04/2016 03:21 , Brandon Allbery wrote:
On Sat, Apr 2, 2016 at 12:52 PM, Michael > wrote:


On 2016-04-02, at 6:15 AM, Brandon Allbery > wrote:
> On Sat, Apr 2, 2016 at 3:55 AM, Paul Rands > wrote:
> > It is a music cataloging program called Tellico, and is a KDE
app. Apart from not being > able to open up a CD / DVD drive, it
works flawlessly.
>
> The Finder "owns" the CD/DVD drive; you would have to disable
Finder support for the drive to be able to use it directly instead
of via OS X services.

How do you disable Finder's ownership of the DVD drive?


You can;t turn it off completely without disabling all automounting, 
as I understand it.
You can do it as a one-shot by using "diskutil list" to see what 
device (diskN) the DVD is (this is dynamic and will depend on what 
other fixed and removable media is mounted) and then "diskutil unmint 
diskN" to unmount it; the automount stuff will then ignore the drive 
until you are done with it and either "diskutil mount" or "diskutil 
eject" it.


Why does Finder own it?
What service/benefit does Finder provide by owning it?


Automounting, primarily. Opening Finder windows when you insert a CD 
or DVD.


And how then does Disk Utility do it's stuff?


Uses OS X services to release the drive, as I mentioned earlier.

--
brandon s allbery kf8nh sine nomine associates
allber...@gmail.com  
ballb...@sinenomine.net 

unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net


___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Checksum fail for ghostscript update

[Kurt Pfeifle]

On Sun, Apr 3, 2016 at 3:17 AM, Clemens Lang  wrote:

>
> On Sat, Apr 02, 2016 at 10:59:11PM +0200, Kurt Pfeifle wrote:
> > Maybe I can convince MacPorts developers to change where they fetch
> > their own sources?
> > I'm not sure if it indeed is so -- but the last sentence seems to
> > suggest to me that MacPorts still fetches GS source tarball from
> > SourceForge.
>
> That may seem like that at a first glance, but is not correct. The
> ghostscript port downloads from multiple sources:
>
>  - ghostscript-9.19.tar.gz from the github source you mentioned.
>  - ghostscript-fonts-other-6.0.tar.gz from the gs-fonts project at
>sourceforge
>  - ghostscript-fonts-std-8.11.tar.gz from the gs-fonts project at
>sourceforge
>

http://downloads.ghostscript.com/public/fonts/
http://git.ghostscript.com/?p=ghostpdl.git;a=blob_plain;f=doc/Fonts.htm;hb=HEAD


>  - A snapshot of github.com/adobe-type-tools/mapping-resources-pdf from
>github.
>
> The fonts don't seem to be available from any place other than
> SourceForge, unfortunately.
>

Please check if above URL fits the bill.

Cheers, Kurt
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users