Re: clang 3.4 can't be configured (part of a selfupdate)

[Ken Cunningham]

Hi,

I had what appears to be the identical problem a week ago, reported with 
tickets at Macports and LLVM.org.
Solved as described in the macports ticket.

Thanks,,
Ken



Please see:



and




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

question about OpenSCAD 2015.03 on Snow Leopard, and a home-built libc++ package installer

[Ken Cunningham]

Hello,

Although the developers of OpenSCAD had to leave Snow Leopard behind a couple 
of version ago, using Macports and the extended abilities that Jeremy has 
enabled for older systems, I have been able to compile a version of the latest 
release of OpenSCAD 2015.03 that runs well on 10.6.8, with some modest surgery 
on the build process along the way to get over humps.

I think this is a great tribute to the work put into this effort by Jeremy and 
others.

To make it a simple thing to install, I made a package installer for libc++ and 
libc++abi to use on SL, and bundled all the macports-compiled dylibs into the 
app bundle.

You can have a look at it here if you like; the libc++ package installer is 
included:

OpenSCAD 2015.03 for MacOSX 10.6.8
https://drive.google.com/open?id=0B4PhjGt59mV1RFN0OEZSbHZPTU0

==
Questions -- 

1. Are there any issues with releasing this to the OpenSCAD community?

2. Any issues/ concerns / suggestions with the libc++ / libc++ABI package 
installer that anyone doesn't like? Right now, the package installer is 
supposed to only run on SL, and will overwrite an existing libc++ and libc++ABI 
library if there is one (but there's only one version, at the moment, so that 
would not seem to be a big issue).

Best,

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

Re: question about OpenSCAD 2015.03 on Snow Leopard, and a home-built libc++ package installer

[Ken Cunningham]

I would indeed have preferred to put libc++ and libc++abi into the app bundle 
-- but all the other dylibs linked against them were hard-coded to look for 
these two libraries in the /usr/lib directory. 

So I tried "install_name_tool'ing" all these libraries to redirect them to a 
bundled copy of libc++ -- but that didn't work out either after one aliquot of 
patience trying to make it work.

I'd fix all I could find, but there'd always be more called in somehow that 
looked in /usr/lib. Perhaps I ultimately might have succeeded with that 
approach with enough recursion and time - but I ultimately went the route to 
install into /usr/lib instead as it just "wanted it that way" it seemed. And 
those libraries on SL are maybe good to have anyway, I rationalized...

dylibbundler seemed like it might be an idea -- but would not include any 
libraries in /usr/lib (reasonably enough, I guess) even if you want them too -- 
and it also doesn't know how to include frameworks like qt.

Only thing I'm worried about is a new version of libc++ comes out later for SL, 
and my package overwrites it with an old version... would prefer if that 
wouldn't happen. Couldn't see that option in packagemaker, tho. Perhaps there's 
a trick to that.

License, permission to distribute, all that seem OK? The macports-quoted 
license seemed quite inclusive.

K


> 
> The app on the disk image already contains a number of libraries, like boost, 
> in the Contents/Frameworks directory. Could you put libc++ and libc++abi in 
> there too, thus making an installer that modifies the OS unnecessary?
> 

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

Re: clang 3.4 can't be configured (part of a selfupdate)

[Ken Cunningham]

Hi,

There are many here smarter than me, but it would see your error is here:

/opt/local/bin/clang++-mp-3.3   -pipe -Os -stdlib=libc++   -arch i386 
-mmacosx-version-min=10.6 -Wl,-search_paths_first 
-Wl,-headerpad_max_install_names  -L/opt/local/lib 
-Wl,-headerpad_max_install_names  
CMakeFiles/cmTC_70577.dir/testCXXCompiler.cxx.o  -o cmTC_70577  
ld: warning: ignoring file /usr/lib/libc++.dylib, file was built for 
unsupported file format ( 0xcf 0xfa 0xed 0xfe 0x 7 0x 0 0x 0 0x 1 0x 3 0x 0 0x 
0 0x 0 0x 6 0x 0 0x 0 0x 0 ) which is not the architecture being linked (i386): 
/usr/lib/libc++.dylib


You're building for -arch i386, but your libc++.dylib does not have that 
architecture (it's likely going to be x64_86) -- So somewhere ( probably in 
your macports.conf file, I would think) your architecture is not set correctly.

Also - I built everything using clang-3.4 as per the instructions:

sudo port -v -f deactivate active
sudo port -v install clang-3.4 ld64 cctools libcxx
but somehow you seem to be using clang-3.3  so something is not quite right 
there.

Best,

Ken





On 2016-07-28, at 10:19 PM, [ftp83plus] wrote:

> Thanks Ken, 
> 
> I am currently attempting the Install Libcxx on Older Systems procedure as it 
> was how you solved it. 
> 
> However, it fails at step 4 after hours trying to compile:
>> -- Configuring incomplete, errors occurred!
>> See also 
>> "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_libomp/libomp/work/build-i386/CMakeFiles/CMakeOutput.log".
>> Command failed:  cd 
>> "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_libomp/libomp/work/build-i386"
>>  && /opt/local/bin/cmake -DCMAKE_INSTALL_PREFIX=/opt/local/tmp 
>> -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_COLOR_MAKEFILE=ON 
>> -DCMAKE_BUILD_TYPE=Release -DCMAKE_BUILD_WITH_INSTALL_RPATH=ON 
>> -DCMAKE_SYSTEM_PREFIX_PATH="/opt/local;/usr" 
>> -DCMAKE_MODULE_PATH=/opt/local/share/cmake/Modules 
>> -DCMAKE_FIND_FRAMEWORK=LAST -Wno-dev 
>> -DCMAKE_INSTALL_RPATH=/opt/local/lib/libomp 
>> -DCMAKE_INSTALL_NAME_DIR=/opt/local/lib/libomp 
>> -DCMAKE_C_FLAGS_RELEASE="-DNDEBUG" -DCMAKE_CXX_FLAGS_RELEASE="-DNDEBUG" 
>> -DCMAKE_OSX_DEPLOYMENT_TARGET="10.6" -DCMAKE_OSX_SYSROOT="/" 
>> -DCMAKE_OSX_ARCHITECTURES=i386 
>> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_libomp/libomp/work/openmp-381/rc1/runtime
>>  
>> Exit code: 1
>> Error: org.macports.configure for port libomp returned: configure failure: 
>> command execution failed
>> Warning: targets not executed for libomp: org.macports.activate 
>> org.macports.configure org.macports.build org.macports.destroot 
>> org.macports.install
>> Error: Failed to install libomp
>> Please see the log file for port libomp for details:
>> 
>> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_libomp/libomp/main.log
>> Error: The following dependencies were not installed: libomp llvm-3.8
>> To report a bug, follow the instructions in the guide:
>> http://guide.macports.org/#project.tickets
>> Error: Processing of port clang-3.8 failed
> 
> 
> Should I open a new topic for this particular error?
> CMakeOutput.log: http://pastebin.com/f1XYZXcF
> main.log: http://pastebin.com/5ZPVKug4
> 
> Pat
> 
> 
> El 2016-07-28, a las 13:57, Ken Cunningham escribió:
> 
>> Hi,
>> 
>> I had what appears to be the identical problem a week ago, reported with 
>> tickets at Macports and LLVM.org.
>> Solved as described in the macports ticket.
>> 
>> Thanks,,
>> Ken
>> 
>> 
>> 
>> Please see:
>> 
>> <https://trac.macports.org/ticket/51864>
>> 
>> and
>> 
>> <https://llvm.org/bugs/show_bug.cgi?id=28592>
>> 
>> 
>> ___
>> macports-users mailing list
>> macports-users@lists.macosforge.org
>> https://lists.macosforge.org/mailman/listinfo/macports-users
> 

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

Re: clang 3.4 can't be configured (part of a selfupdate)

[Ken Cunningham]

Oh - it's arch x86_64, by the way... late night brain fart.]

More I look at the different issues you have going on here, more I think what I 
would do is just start over. It's time consuming, but 100% reliable.


I'd delete these three files:

-rwxr-xr-x  1 root  wheel  1186580 12 Jan  2016 libc++.1.dylib
lrwxr-xr-x  1 root  wheel   14 28 Jul 20:36 libc++.dylib -> libc++.1.dylib
-rwxr-xr-x  1 root  wheel   431040 24 Nov  2015 libc++abi.dylib

Move your opt folder out of the way

sudo mv  /opt /opt-junked

reinstall macports from the package

do a sudo port selfupdate (I think it happens anyway when you install).

And then go straight to the libcxxOnOlderSystems page and follow the 
instructions line by line before you do anything else.


=

if that's just not acceptable, I'd uninstall all traces of clang, llvm, ld64, 
and cctools until there is nothing left when you search for these ports, reset 
your macports.conf and variants.conf to the default settings, delete the 
/usr/lib files listed above, and follow the instructions carefully. 

Hope this helps.

K









On 2016-07-28, at 10:35 PM, Ken Cunningham wrote:

> Hi,
> 
> There are many here smarter than me, but it would see your error is here:
> 
> /opt/local/bin/clang++-mp-3.3   -pipe -Os -stdlib=libc++   -arch i386 
> -mmacosx-version-min=10.6 -Wl,-search_paths_first 
> -Wl,-headerpad_max_install_names  -L/opt/local/lib 
> -Wl,-headerpad_max_install_names  
> CMakeFiles/cmTC_70577.dir/testCXXCompiler.cxx.o  -o cmTC_70577  
> ld: warning: ignoring file /usr/lib/libc++.dylib, file was built for 
> unsupported file format ( 0xcf 0xfa 0xed 0xfe 0x 7 0x 0 0x 0 0x 1 0x 3 0x 0 
> 0x 0 0x 0 0x 6 0x 0 0x 0 0x 0 ) which is not the architecture being linked 
> (i386): /usr/lib/libc++.dylib
> 
> 
> You're building for -arch i386, but your libc++.dylib does not have that 
> architecture (it's likely going to be x64_86) -- So somewhere ( probably in 
> your macports.conf file, I would think) your architecture is not set 
> correctly.
> 
> Also - I built everything using clang-3.4 as per the instructions:
> 
> sudo port -v -f deactivate active
> sudo port -v install clang-3.4 ld64 cctools libcxx
> but somehow you seem to be using clang-3.3  so something is not quite 
> right there.
> 
> Best,
> 
> Ken
> 
> 
> 
> 
> 
> On 2016-07-28, at 10:19 PM, [ftp83plus] wrote:
> 
>> Thanks Ken, 
>> 
>> I am currently attempting the Install Libcxx on Older Systems procedure as 
>> it was how you solved it. 
>> 
>> However, it fails at step 4 after hours trying to compile:
>>> -- Configuring incomplete, errors occurred!
>>> See also 
>>> "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_libomp/libomp/work/build-i386/CMakeFiles/CMakeOutput.log".
>>> Command failed:  cd 
>>> "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_libomp/libomp/work/build-i386"
>>>  && /opt/local/bin/cmake -DCMAKE_INSTALL_PREFIX=/opt/local/tmp 
>>> -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_COLOR_MAKEFILE=ON 
>>> -DCMAKE_BUILD_TYPE=Release -DCMAKE_BUILD_WITH_INSTALL_RPATH=ON 
>>> -DCMAKE_SYSTEM_PREFIX_PATH="/opt/local;/usr" 
>>> -DCMAKE_MODULE_PATH=/opt/local/share/cmake/Modules 
>>> -DCMAKE_FIND_FRAMEWORK=LAST -Wno-dev 
>>> -DCMAKE_INSTALL_RPATH=/opt/local/lib/libomp 
>>> -DCMAKE_INSTALL_NAME_DIR=/opt/local/lib/libomp 
>>> -DCMAKE_C_FLAGS_RELEASE="-DNDEBUG" -DCMAKE_CXX_FLAGS_RELEASE="-DNDEBUG" 
>>> -DCMAKE_OSX_DEPLOYMENT_TARGET="10.6" -DCMAKE_OSX_SYSROOT="/" 
>>> -DCMAKE_OSX_ARCHITECTURES=i386 
>>> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_libomp/libomp/work/openmp-381/rc1/runtime
>>>  
>>> Exit code: 1
>>> Error: org.macports.configure for port libomp returned: configure failure: 
>>> command execution failed
>>> Warning: targets not executed for libomp: org.macports.activate 
>>> org.macports.configure org.macports.build org.macports.destroot 
>>> org.macports.install
>>> Error: Failed to install libomp
>>> Please see the log file for port libomp for details:
>>> 
>>> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_libomp/libomp/main.log
>>> Error: The following dependencies were not installed: libomp llvm-3.8
>>> To report a bug, follow the instructions in the guide:
>>> http://guide.macports.org/#proj

Re: clang 3.4 can't be configured (part of a selfupdate)

[Ken Cunningham]

On 2016-07-29, at 7:57 AM, [ftp83plus] wrote:

> SoI would have to 0- remove said files 1- reinstall MacPorts,

Yes

> 2- correct the macports.conf to replace x86 by x86_64 architecture

No, don't think so. My macports.conf has 

build_arch x86_64

near the top -- I installed macports two years ago. I can't recall at the 
moment if I added that at some point in the past, or if macports did that on 
the install. I think macports did it...

> 
> But how would I know if the macports.conf contains the correct data?

Leave it as macports installed it.


> What should be the default for variants.conf?

/opt/local/etc/macports/variants.conf.default


> And why would it use clang-3.3 when it's explicitly told to use clang 3.4?


Most likely because clang-3.3 was still around somehow, and clang-3.4 was not.

This should not be the case when you do a clean install.



Hope this is helpful and not confusing.

Ken


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

Re: clang 3.4 can't be configured (part of a selfupdate)

[Ken Cunningham]

> 
> Move your opt folder out of the way
> 
> sudo mv  /opt /opt-junked
> 

Oh dear - this step is not quite right - I'm very sorry about that. There could 
be (and probably are) other things in your /opt folder that you don't want to 
move.

If you did that, please move it back ( sudo mv /opt-junked /opt ) and do the 
following.

I should have said

sudo mv /opt/local /opt/local-junked

as the macports directory is /opt/local and there should be nothing else inside 
that directory beyond macports

I apologize for any confusion that might have caused.

K


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

Re: clang 3.4 can't be configured (part of a selfupdate)

[Ken Cunningham]

> 
> I followed the instructions for full uninstall: 
> https://guide.macports.org/chunked/installing.macports.uninstalling.html

That is infinitely better, and gets all the other bits and pieces that might 
cause trouble.

> 
> this is the only occurence of "build_arch" in macports.conf, and is commented 
> out, so shouldn't be taken into account:
> #build_arch i386
> 
> Comes from the most recent install of MacPorts. Should I replace it by 
> build_arch  x86_64
> ?
> 

I believe macports automatically sets build_arch to the proper value depending 
on your hardware .



Don't forget, in macports.conf, the commented out values are actually the 
default values being used, they are not really ignored.

Best,

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

Re: clang 3.4 can't be configured (part of a selfupdate)

[Ken Cunningham]

Maybe, indeed.

I just realized my package installer (and my OpenSCAD application) are x86_64 
specific. And some 10.6.8 systems can't run that.

I have a lot to learn.

Ken




On 2016-07-30, at 6:16 PM, Ryan Schmidt wrote:

> 
>> On Jul 30, 2016, at 7:58 AM, [ftp83plus] wrote:
>> 
>>> El 29 jul 2016, a las 16:45, Lawrence Velázquez escribió:
>>> 
>>>> On Jul 29, 2016, at 1:35 AM, Ken Cunningham wrote:
>>>> 
>>>>> /opt/local/bin/clang++-mp-3.3   -pipe -Os -stdlib=libc++   -arch i386 
>>>>> -mmacosx-version-min=10.6 -Wl,-search_paths_first 
>>>>> -Wl,-headerpad_max_install_names  -L/opt/local/lib 
>>>>> -Wl,-headerpad_max_install_names  
>>>>> CMakeFiles/cmTC_70577.dir/testCXXCompiler.cxx.o  -o cmTC_70577  
>>>>> ld: warning: ignoring file /usr/lib/libc++.dylib, file was built for 
>>>>> unsupported file format ( 0xcf 0xfa 0xed 0xfe 0x 7 0x 0 0x 0 0x 1 0x 3 0x 
>>>>> 0 0x 0 0x 0 0x 6 0x 0 0x 0 0x 0 ) which is not the architecture being 
>>>>> linked (i386): /usr/lib/libc++.dylib
>>>> 
>>>> You're building for -arch i386, but your libc++.dylib does not have
>>>> that architecture (it's likely going to be x64_86) -- So somewhere
>>>> ( probably in your macports.conf file, I would think) your
>>>> architecture is not set correctly.
>>> 
>>> The libomp port is being installed +universal. Since it uses the 
>>> muniversal-1.0 portgroup, MacPorts builds it for each architecture 
>>> separately, then lipo(1)s everything together at the end.
>>> 
>>> The problem is that the i386 build is trying to link to libc++, which in 
>>> your case appears to be provided by libcxx. But libomp does not declare a 
>>> dependency on libcxx, so MacPorts did not attempt to rebuild libcxx 
>>> +universal. You may have to do this yourself.
>>> 
>>> vq
>> 
>> So should I rebuild libcxx +universal variant first before performing Step 4 
>> of the LibcxxOnOlderSystems?
> 
> Jeremy, shouldn't we modify the LibcxxOnOlderSystems instructions to include 
> installing libcxx +universal?
> 

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

Re: clang 3.4 can't be configured (part of a selfupdate)

[Ken Cunningham]

Interestingly, I just went to update my libmacho and libunwind to the universal 
variants given this conversation (already did the cxx and cxxabi ports) -- but 
oddly, perhaps, this seemingly fully functional 10.6.8 /libc++ system with 
clang-3.8, all installed through macports, has neither libmacho nor libunwind 
installed. But it does have the headers.

For your consideration

Ken



port -v installed libcxxabi
The following ports are currently installed:
libcxxabi @3.7.0_1+universal (active) platform='darwin 10' archs='i386 x86_64'

port -v installed libcxx
The following ports are currently installed:
libcxx @3.7.1_0+universal (active) platform='darwin 10' archs='i386 x86_64'

port -v installed libunwind*
The following ports are currently installed:
libunwind-headers @3.7.0_1 (active) platform='darwin 10' archs='noarch'

port -v installed libmac*
The following ports are currently installed:
libmacho-headers @877.8_0 platform='darwin 10' archs='noarch'
libmacho-headers @886_0 (active) platform='darwin 10' archs='noarch'




> 
> 
> libcxx depends on libcxxabi which depends on libunwind and libmacho.  We'd 
> need to force all four to build +universal for that.
> 
> r150880
> 
> --Jeremy
> 

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

Re: clang 3.4 can't be configured (part of a selfupdate)

[Ken Cunningham]

Pat,

I seemed to have none of these issues... but I installed libomp-universal on my 
x86_64 compatible mac.

  libomp @3.8.1_0-universal (active) platform='darwin 10' archs='x86_64'

And so it remains.

That seems to have been the main reason I didn't run into any of the issues you 
have run into, I guess.

Ken




On 2016-08-03, at 7:36 AM, [ftp83plus] wrote:

> Hmmm, and how would I install the +universal variant of libcxx wile avoiding 
> the python-related bug?
> 
> PAt
> 
> El 2016-08-01, a las 22:13, Jeremy Huddleston Sequoia escribió:

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

X11 and QD name space conflicts as they apply to webkit2-gtk on snowleopard

[Ken Cunningham]

I'm attempting to build Epiphany on SnowLeopard with libc++ installed, as Snow 
Leopard has no up-to-date browser options available any longer.

Epiphany uses webkit2-gtk, and with some minor fixes, webkit2-gtk does build on 
snow leopard. But there are name space conflicts between X11 and QD, so as the 
webkit2-gtk code base stands now, the only way to build it is to disable X11 
and build for quartz only.

Unfortunately, Epiphany pulls in gnome-desktop, which pulls in gtk3 +X11, and 
gnome-desktop appears to build only with X11 enabled. So catch-22.

I note upon cruising the web that this is a very old problem, which both Dave 
Evans and Jeremy appear to have worked on over the years, both in webkit and in 
xserver.





and more

At various points, the bug is declared fixed, but it popped up again just now 
when I tried to build webkit2-gtk.

Does anyone have any advice on how to best proceed here? It appears that I need 
to find a way to build webkit2-gtk with +x11 to proceed. There is some code 
referenced above to santize QD types on xserver -- perhaps I could try to 
integrate that into webkit2-gtk.

Thanks,

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

Re: X11 and QD name space conflicts as they apply to webkit2-gtk on snowleopard

[Ken Cunningham]

Thanks, Dave

It seems as though Epiphany is a reasonable option to investigate for a 
snowleopard browser going forward (unless there is a better browser option I 
don't know about). So it appears worth the effort to try to get it functional 
on snowleopard. 

If Epiphany can build without X11, that seems a great option - probably the 
best option I think -- I appreciate your looking into that.

Meanwhile, I'll poke around in webkit2-gtk-devel source and see if there is a 
place to insert what I assume is Jeremy's QD sanitizing code from xserver.

Will open a ticket on the build attempt as you suggest as soon as there is 
something to post. At this moment, most of the many  dependencies for epiphany 
install cleanly on snowleopard with +quartz-x11 , leaving only the following 
two as residuals left to install, both of which however require gtk3 +x11

gnome-desktop
libwnck3


Thanks again,

Ken




On 2016-08-15, at 4:36 PM, David Evans wrote:

> On 8/15/16 3:15 PM, Ken Cunningham wrote:
>> I'm attempting to build Epiphany on SnowLeopard with libc++ installed, as 
>> Snow Leopard has no up-to-date browser options available any longer.

> Thanks for your report, Ken.  I suspect that you are one of first to try 
> building webkit2-gtk with libc++ on SnowLeopard
> so it's not too unexpected to run into some problems.  Jeremy is really your 
> best bet on advice in this area as he has
> more expertise on the webkit2-gtk internals at this point and he also is most 
> familiar with the procedures for
> installing libc++ on the older platforms.  At this point, I no longer have 
> access to a SL machine let
> alone one configured for libc++.
> 
> If you really are serious about trying to come up with a patch for 
> webkit2-gtk on your platform, then you probably would
> be best off to use the unstable version webkit2-gtk-devel as the code is 
> constantly changing and a new stable
> version will be out around the time the GNOME-3 3.22 is released in mid 
> September.  Looks like it needs updating so I'll
> try and push it to the latest unstable release as well.
> 
> However, let me take a look at epiphany and see if there is a way to get it 
> to build cleanly without X11.  As you say,
> gnome-desktop is X11 dependent but it may not be entirely necessary for a 
> +quartz build.  That would at least get you
> running with a browser.
> 
> As you proceed, please be sure to upload your latest build logs with issues 
> to the appropriate ticket on trac so we can
> see exactly what you are.
> 
> Hopefully, Jeremy will see this and respond with something more useful. 
> Copying him for his information.
> 
> Thanks for sticking with this.
> 
> Dave
> 

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

Re: Updating tk failed on Snow Leopard

[Ken Cunningham]

Hi Richard,

I have tk 8.6.6 running on snow leopard, but with +x11 (and not universal, but 
x86_64)

$ port -v installed tk
The following ports are currently installed:
  tk @8.6.6_0+x11 (active) platform='darwin 10' archs='x86_64'

for what that's worth. I installed it with clang-3.7, and my first thought is 
that your compiler might be too old. You might try installing clang-3.7 (and 
ld64/cctools/llvm-3.7 that go along with it) and see where that takes you

K




On 2016-08-22, at 3:48 PM, Richard L. Hamilton wrote:

> Updating tk failed on Snow Leopard, trying to update to the current tk@8.6.6 
> (probably +quartz+universal, given that's what the current @8.6.5_0 is)
> 
> Hardware Version: Mac mini (Mid 2007) (Macmini2,1)
> Mac OS X 10.6.8 10K549 (Snow Leopard)
> Xcode 4.2 4C199
> MacPorts Version: 2.3.4
> 
> Relevant lines from log:
> 
> 
> Is this a known problem?
> ___
> macports-users mailing list
> macports-users@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-users

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

Re: Can't upgrade gtk3 as part of a "upgrade outdated", Segmentation fault?

[Ken Cunningham]

Yikes. Clang is segfaulting on you again, eh? Do I assume you're still using 
the libc++ upgrade for older systems on snow leopard? This has happened to me a 
couple of times, as you know from previous discussions.

Try writing up and running just a simple clang compilation on a five-line 
"hello, world" app in C to see if it's just clang blowing up. I think you'll 
find it is, and if so, it has nothing to do with gtk specifically.

If you find that it is just a dead clang-3.7 (on that hello, world test), 
here's what I do to fix it:

Although I __do not__ fully understand what inconsistency between tools seems 
to develop in the toolchain that leads to this, in each case (three times now 
in three months) I've resolved it by fully unintstalling all versions of clang, 
llvm, cctools, and ld64 (often having to --follow-dependents to make the 
uninstall happen), resetting the macports.conf and variants.conf back to their 
defaults, and then reinstalling LibCxxOnOlderSystems from the beginning. That 
has fixed the problem in every case, __for me__ .

you need to get it spotless clean, though -- port -v installed clang* llvm* 
cctools* and ld* all have to show nothing. Then the reinstall works and all is 
well, although it's time wasted.

There must be a more elegant answer / way to do this, though. And there must be 
some explanation for what happens to cause this -- but I don't know what it is 
at present.

But anyway, that is how I do it.

Ken






On 2016-08-26, at 8:51 AM, [ftp83plus] wrote:

> Hello there, 
> 
> just encountered this issue when gtk3 tried to rebuild as part of an upgrade 
> outdated operation:
> Relevant extract of main.log: http://pastebin.com/KL0kKinG
> 
> Knowing that a Segmentation fault doesn't mean much, I cleaned gtk3 at 
> attempted a rebuild, but it still segfaults for some reason.
> http://pastebin.com/TK81EYnZ
> 
> What is the source of the problem?
> 
> 
> ___
> macports-users mailing list
> macports-users@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-users

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

Re: Can't upgrade gtk3 as part of a "upgrade outdated", Segmentation fault?

[Ken Cunningham]

Hmm.

Would you mind test compiling your hello world program like this, and see what 
happens? (This is the specific clang you're segfaulting). -- Ken

/opt/local/bin/clang-mp-3.7 -v hw.c -o hw2


On 2016-08-26, at 9:39 AM, [ftp83plus] wrote:

> Complete main.log for failure to upgrade gtk3, after the first clean-up with 
> "port clean gtk3": http://ovh.to/jgFHoPk
> 
>  However, maybe it's worthy of note that previous ports upgraded as part of 
> the "upgrade outdated" operation didn't threw any error.
> 
> My sample "Hello world" program does not do much, but compiles without 
> segfaulting:
> clang hw.c -o hw2
> hw.c:5:1: warning: type specifier missing, defaults to 'int' [-Wimplicit-int]
> main()
> ^~~~
> 1 warning generated.
> 
> 
> Of course I could re-do the whole LibcXXOnOlderSystems process, but it's a 
> bit on the slow and noisy side
> 
> 
> El 2016-08-26, a las 12:13, Brandon Allbery escribió:
> 
>> 
>> On Fri, Aug 26, 2016 at 12:09 PM, Ken Cunningham 
>>  wrote:
>> There must be a more elegant answer / way to do this, though. And there must 
>> be some explanation for what happens to cause this -- but I don't know what 
>> it is at present.
>> 
>> Possibly some port somewhere along the line is buggy and not using the 
>> libcxx settings; when you reset everything you remove that port, and 
>> everything is fine until it gets pulled back in and then subsequent builds 
>> find it. (If this is happening in clang itself, it could be a build tool 
>> that is not compatible.)
>> 
>> -- 
>> 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: Can't upgrade gtk3 as part of a "upgrade outdated", Segmentation fault?

[Ken Cunningham]

Nope - your clang-3.7 is working, it appears.
Thanks for checking.

??

K




On 2016-08-26, at 10:08 AM, [ftp83plus] wrote:

> Here it the output: http://pastebin.com/JJ4iUjPU
> 
> El 2016-08-26, a las 12:55, Ken Cunningham escribió:
> 
>> Hmm.
>> 
>> Would you mind test compiling your hello world program like this, and see 
>> what happens? (This is the specific clang you're segfaulting). -- Ken
>> 
>> /opt/local/bin/clang-mp-3.7 -v hw.c -o hw2
>> 
>> 
>> On 2016-08-26, at 9:39 AM, [ftp83plus] wrote:
>> 
>>> Complete main.log for failure to upgrade gtk3, after the first clean-up 
>>> with "port clean gtk3": http://ovh.to/jgFHoPk
>>> 
>>>  However, maybe it's worthy of note that previous ports upgraded as part of 
>>> the "upgrade outdated" operation didn't threw any error.
>>> 
>>> My sample "Hello world" program does not do much, but compiles without 
>>> segfaulting:
>>> clang hw.c -o hw2
>>> hw.c:5:1: warning: type specifier missing, defaults to 'int' 
>>> [-Wimplicit-int]
>>> main()
>>> ^~~~
>>> 1 warning generated.
>>> 
>>> 
>>> Of course I could re-do the whole LibcXXOnOlderSystems process, but it's a 
>>> bit on the slow and noisy side
>>> 
>>> 
>>> El 2016-08-26, a las 12:13, Brandon Allbery escribió:
>>> 
>>>> 
>>>> On Fri, Aug 26, 2016 at 12:09 PM, Ken Cunningham 
>>>>  wrote:
>>>> There must be a more elegant answer / way to do this, though. And there 
>>>> must be some explanation for what happens to cause this -- but I don't 
>>>> know what it is at present.
>>>> 
>>>> Possibly some port somewhere along the line is buggy and not using the 
>>>> libcxx settings; when you reset everything you remove that port, and 
>>>> everything is fine until it gets pulled back in and then subsequent builds 
>>>> find it. (If this is happening in clang itself, it could be a build tool 
>>>> that is not compatible.)
>>>> 
>>>> -- 
>>>> 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: Can't upgrade gtk3 as part of a "upgrade outdated", Segmentation fault?

[Ken Cunningham]

It's going to be something like that.

I've also seen a few executables at times that are linked to both -libc++ and 
to -libstdc++, and you just know that can't be a good thing. (Probably exactly 
what you're suggesting.)

No doubt, although this libc++ upgrade enables quite a bit more software to 
build and run, you do need to keep your wits about you.

K



On 2016-08-26, at 9:13 AM, Brandon Allbery wrote:

> 
> On Fri, Aug 26, 2016 at 12:09 PM, Ken Cunningham 
>  wrote:
> There must be a more elegant answer / way to do this, though. And there must 
> be some explanation for what happens to cause this -- but I don't know what 
> it is at present.
> 
> Possibly some port somewhere along the line is buggy and not using the libcxx 
> settings; when you reset everything you remove that port, and everything is 
> fine until it gets pulled back in and then subsequent builds find it. (If 
> this is happening in clang itself, it could be a build tool that is not 
> compatible.)
> 
> -- 
> 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: Can't upgrade gtk3 as part of a "upgrade outdated", Segmentation fault?

[Ken Cunningham]

I'll try later this afternoon to update my own gtk3 on the same system and let 
you know what happens.

Looks like it might be just your ld64* port that is dysfunctional - I suppose 
we could make up an example that tests the linker, like we did for clang, and 
see if that segfaults. Sorry I don't have time to create that right now.

I don't know if you can just uninstall and then reinstall ld64 to "short 
version"  the reinstall of what appears to be the faulty executable. I would 
probably try to see if I could do that, myself. I suspect the dependencies 
might prevent that.

I think ultimately you're into the reinstall of the tool chain that I described 
previously to fix the segfaulting ld64.

Having these as binaries that you could install rather than the 6 hour 
compiling process would make it less painful. I usually run it overnight (the 
clang and llvm parts take all the time). I know you have to "build from source" 
for this system at present (lots of talk about the buildbot coming soon, 
though). 

You are coming through some 'real-world' issues that are helpful to figure out 
any inconsistencies in the system. 

I hope this helps,

Ken




On 2016-08-28, at 1:44 AM, Ryan Schmidt wrote:

> On Aug 27, 2016, at 12:41, [ftp83plus]  wrote:
>> 
>> So, after reinstalling Mac OS X as I did to get out of the startup crash as 
>> I did, even if ports stayed in place, I should re-perform the 
>> LibcxxOnOlderSystems steps?
> 
> In general, no, reinstalling the same version of macOS does not necessitate 
> reinstalling MacPorts and your ports. However, the issues Mihai noted may 
> require reinstalling the affected ports. I'm not an expert at reading crash 
> logs so I can't say for certain why your crash occurred. I just know that 
> when a crash occurs, you should provide the crash log so that someone who is 
> more familiar might be able to help. 
> 
> 
> 
>>> El 2016-08-27, a las 12:17, Mihai Moldovan escribió:
>>> 
 On 27.08.2016 04:00 PM, [ftp83plus] wrote:
 Crash log, approximately when gtk3 segfaulted:
 
 http://pastebin.com/bzuez8Xp
>>> 
>>> In there, I see two things that look weird:
>>> 
>>> - you're using ld64-136, although step 8 and 9 of the LibcxxOnOlderSystems
>>>  guide explicitly says to switch to ld64-latest
>>> - ld64-136 was installed with +llvm37, although step 5 and 7 make sure that
>>>  +llvm38 is used
>>> 
>>> The second problem may be explicable by upgrading - earlier versions 
>>> probably
>>> used llvm37 and the llvm38 change is relatively new.
>>> 
>>> Still, your setup is broken/deviates from what is advertised to work on 
>>> 10.6.
>>> That crash is probably a consequence of that.
> 
> ___
> macports-users mailing list
> macports-users@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-users

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

Re: Can't upgrade gtk3 as part of a "upgrade outdated", Segmentation fault?

[Ken Cunningham]

I note that ld64-latest, ld64-136, and cctools were all updated just now.

I sense the omnipresence of jeremy in the background somewhere, Obiwan...

Perhaps in hopes of saving your processor time you might just try updating 
those ports and try your gtk3 install again?

K

On 2016-08-28, at 7:40 AM, Ken Cunningham wrote:

> I'll try later this afternoon to update my own gtk3 on the same system and 
> let you know what happens.
> 
> Looks like it might be just your ld64* port that is dysfunctional - I suppose 
> we could make up an example that tests the linker, like we did for clang, and 
> see if that segfaults. Sorry I don't have time to create that right now.
> 
> I don't know if you can just uninstall and then reinstall ld64 to "short 
> version"  the reinstall of what appears to be the faulty executable. I would 
> probably try to see if I could do that, myself. I suspect the dependencies 
> might prevent that.
> 
> I think ultimately you're into the reinstall of the tool chain that I 
> described previously to fix the segfaulting ld64.

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

Re: Can't upgrade gtk3 as part of a "upgrade outdated", Segmentation fault?

[Ken Cunningham]

Sorry for all the emails one after another, but I noted that updating cctools 
and llvm this morning somehow called back ld64-latest @264.3.102_2+llvm34, 
which is not the right one. You need  ld64-latest @264.3.102_1+llvm37.

--->  Dependencies to be installed: llvm-3.4
--->  Activating llvm-3.4 @3.4.2_11
--->  Fetching distfiles for ld64-latest
--->  Verifying checksums for ld64-latest
--->  Extracting ld64-latest
--->  Applying patches to ld64-latest
--->  Configuring ld64-latest
--->  Building ld64-latest
--->  Staging ld64-latest into destroot
--->  Installing ld64-latest @264.3.102_2+llvm34
--->  Computing dependencies for ld64-latest
--->  Deactivating ld64-latest @264.3.102_1+llvm37
--->  Activating ld64-latest @264.3.102_2+llvm34

this is not expected. Maybe this happened to you.

do

$ port -v installed ld64*
The following ports are currently installed:
 ld64 @2_0-ld64_127-ld64_136-ld64_236-ld64_97 (active) platform='darwin 10' 
archs='x86_64'
 ld64 @2_0+ld64_136 platform='darwin 10' archs='x86_64'
 ld64-136 @136_5+llvm34 platform='darwin 10' archs='x86_64'
 ld64-136 @136_5+llvm37-llvm34 (active) platform='darwin 10' archs='x86_64'
 ld64-latest @264.3.102_1+llvm37 platform='darwin 10' archs='x86_64'
 ld64-latest @264.3.102_2+llvm34 (active) platform='darwin 10' archs='x86_64'

and if you get something like what I got above: 

sudo port activate ld64-latest @264.3.102_1+llvm37

$ sudo port activate ld64-latest @264.3.102_1+llvm37
--->  Computing dependencies for ld64-latest
--->  Deactivating ld64-latest @264.3.102_2+llvm34
--->  Activating ld64-latest @264.3.102_1+llvm37

then recheck:

$ port -v installed ld64*
The following ports are currently installed:
 ld64 @2_0-ld64_127-ld64_136-ld64_236-ld64_97 (active) platform='darwin 10' 
archs='x86_64'
 ld64 @2_0+ld64_136 platform='darwin 10' archs='x86_64'
 ld64-136 @136_5+llvm34 platform='darwin 10' archs='x86_64'
 ld64-136 @136_5+llvm37-llvm34 (active) platform='darwin 10' archs='x86_64'
 ld64-latest @264.3.102_1+llvm37 (active) platform='darwin 10' archs='x86_64'
 ld64-latest @264.3.102_2+llvm34 platform='darwin 10' archs='x86_64'


and that looks to me like the correct mixture. 

Ken




On 2016-08-28, at 7:52 AM, Ken Cunningham wrote:

> I note that ld64-latest, ld64-136, and cctools were all updated just now.

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

Re: Can't upgrade gtk3 as part of a "upgrade outdated", Segmentation fault?

[Ken Cunningham]

No - that doesn't work either...pulls in old ld64 version 

then when you try to fix it, you get

$ sudo port upgrade --enforce-variants ld64-latest +llmv37 -llvm34
Error: Your platform cannot be configured without LTO support in ld64.  Please 
enable one of the llvmXX variants, and try again.

... have to do a better fix once I figure out what's happening here. -- K


> 
> and that looks to me like the correct mixture. 
> 
> Ken
> 
> 
> 
> 
> On 2016-08-28, at 7:52 AM, Ken Cunningham wrote:
> 
>> I note that ld64-latest, ld64-136, and cctools were all updated just now.
> 

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

Re: Can't upgrade gtk3 as part of a "upgrade outdated", Segmentation fault?

[Ken Cunningham]

OK - I see what happened.

All traces of llvm37 have been from the new ld64 portfile.


and so when the porfile saw my requested +llvm37, it saw that as no llvm 
variant, and defaulted to llvm34. And now my toolchain is looking pretty 
inoperable.

there isn't an llm37 option in the ld64 portfile any longer.

I either have to add one -- or -- reinstall everything

but the  instructions 
currently have a mixture of clang-3.7 references and llvm38 references.

I thought 3.8 was not yet workable, and so we were to stick with 3.7 -- maybe 
this is in transition?

Looks like I need to let this all settle down in the portfile evolution for a 
bit, and come back in a few days :>

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

LibCxx on older systems toolchain blew up on 10.6 -- and fixed -- WAS Re: Can't upgrade gtk3 as part of a "upgrade outdated", Segmentation fault?

[Ken Cunningham]

Thanks for the info. I realize it's a small audience, and I'm happy to help, 
and in fact, don't mind plugging away at it when I have some time. No wonder 
the OP had trouble though. The toolchain blew up with the last updates to 
cctools and ld64, and the current instructions and state of things don't appear 
(to me) to be able to work. 

But I believe have it fixed now, I think, with one small change in the 
instructions,  and one small change in the ld64 portfile.

I was unable to resuscitate the toolchain after it pulled in ld64 +llvm34, and 
ultimately I had to uninstall the toolchain completely and start over.

The current LibCxxOnOlderSystems instructions are mixed between +llvm37 and 
+llvm38. You can't use +llvm37 or clang-3.7 options because they no longer 
exist in cctools or ld64, so +llvm34 will get pulled back in instead.

The install goes OK if you ignore all the references to +llvm37 or clang-3.7, 
and just insert +llvm38 or clang-3.8 instead.


HOWEVER you can't build ld64 against +llvm38 due to errors in math.h (as Jeremy 
pointed out).

sudo port -v upgrade --enforce-variants ld64 -ld64_97 -ld64_127 -ld64_136 
-ld64_236


As per:

<http://clang-developers.42468.n3.nabble.com/problems-building-libcxx-td2353619.html>

These math errors appear to be fixed on 10.6 by adding this line in the ld64 
portfile -- 

configure.cppflags-append -I${workpath}/dyld-${dyld_version}/include
+configure.cppflags-append -U__STRICT_ANSI__

And then it all installs and appears to be a coherent toolchain that works 
again (with clang-3.8, llvm-3.8).

Best,

Ken



On 2016-08-29, at 1:45 AM, Mojca Miklavec wrote:

> On 28 August 2016 at 23:21, Ken Cunningham wrote:
>> OK - I see what happened.
>> 
>> All traces of llvm37 have been from the new ld64 portfile.
>> 
>> and so when the porfile saw my requested +llvm37, it saw that as no llvm 
>> variant, and defaulted to llvm34. And now my toolchain is looking pretty 
>> inoperable.
>> 
>> there isn't an llm37 option in the ld64 portfile any longer.
>> 
>> I either have to add one -- or -- reinstall everything
>> 
>> but the <https://trac.macports.org/wiki/LibcxxOnOlderSystems> instructions 
>> currently have a mixture of clang-3.7 references and llvm38 references.
> 
> That's partially because it was written when 3.7 made sense (ok, it
> was probably earlier, when 3.5 or 3.6 was there), then 3.8 was
> released, but buggy, so some instructions reverted back to 3.7 ...
> 
>> I thought 3.8 was not yet workable, and so we were to stick with 3.7 -- 
>> maybe this is in transition?
> 
> Probably. Your feedback might help though.
> 
>> Looks like I need to let this all settle down in the portfile evolution for 
>> a bit, and come back in a few days :>
> 
> Jeremy was cleaning up some of these files recently and it's quite
> likely that not all of the changes were heavily tested on 10.5 and
> 10.6.
> 
> As an example, a recently discovered problem on 10.5 has just been
> fixed and more changes have been applied just now. It makes sense to
> open a new ticket for a problem like the one you mentioned. (Actually,
> it also makes sense to upload crash reports and other problems to a
> ticket in Trac. Trac can easily handle a 2 MB file that pastebin is
> refusing.)
> 
> The setup for libc++ has a very small audience / a very small pool of
> testers. Until we set up new build slaves and attract more users,
> problems are to be expected. (Even then it will still be a problem
> because most developers use the latest OS, so there are very often
> very few people able to help.) Most support for old OSes is there
> because those OSes used to be "up-to-date" some time back and
> developers made sure everything was working (at least until new
> software came up that required C++11). The libc++ support came later
> and is constantly evolving due to releases of newer compilers.
> 
> Mojca

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

Re: Can't upgrade gtk3 as part of a "upgrade outdated", Segmentation fault?

[Ken Cunningham]

FYI - the gtk3 upgrade does ultimately proceed normally on 10.6, once the 
LibCxxOnOlderSystems toolchain is repaired, per the separate instructions I 
posted.

The problem was not with gtk specifically, but the toolchain it appears. 

Ken



$ sudo port upgrade gtk3
--->  Computing dependencies for gtk3
--->  Fetching distfiles for gtk3
--->  Attempting to fetch gtk+-3.20.9.tar.xz from 
http://sea.us.distfiles.macports.org/macports/distfiles/gtk3
--->  Attempting to fetch gtk+-3.20.9.tar.xz from 
https://muug.ca/mirror/gnome/sources/gtk+/3.20/
--->  Verifying checksums for gtk3  
 
--->  Extracting gtk3
--->  Applying patches to gtk3
--->  Configuring gtk3
--->  Building gtk3
--->  Staging gtk3 into destroot
--->  Installing gtk3 @3.20.9_0+quartz
--->  Cleaning gtk3
--->  Computing dependencies for gtk3
--->  Deactivating gtk3 @3.20.6_0+quartz
--->  Cleaning gtk3
--->  Activating gtk3 @3.20.9_0+quartz
--->  Cleaning gtk3
--->  Updating database of binaries
--->  Scanning binaries for linking errors
--->  No broken files found. 
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

qemu, and using gcc45+ compilers on systems set up with LibCxxOnOlderSystems and libc++

[Ken Cunningham]

I would like to try building qemu, but it doesn't seem to be able to build with 
clang-3.7 or clang-3.8 (on 10.68 with LibCxxOnOlderSystems and libc++)

the error for both 
:info:configure ERROR: Your compiler does not support the __thread specifier 
for 
:info:configureThread-Local Storage (TLS). Please upgrade to a version 
that does.

this error is out on the net, as far as I can see doesn't have any present 
fixes; the recommended next step is to try with a newer version of gcc, like 4.9

but

I am not totally sure how to use gcc* versions, building cxx code, when my 
system has been set up for LibCxxOnOlderSystems, and all the installed ports to 
date link against libc++.

I _think_ I can just 

sudo port install gcc49

for example. This would build gcc49 using clang, and I believe that command 
would link gcc itself against libc++, which I guess is no big deal and maybe a 
fine thing.

gcc49 has lots of dependents, including most of the same ones as clang-3.7, 
which I certainly don't want to mess with. Hopefully they would be untouched.


Then - assuming that goes OK - when I try to build something with gcc49, 
according to this page:



I would do something like this with the flags to keep gcc on trac with libc++.


g++ -nostdinc++ -I/include/c++/v1 \
   test.cpp -nodefaultlibs -lc++ -lc++abi -lm -lc -lgcc_s -lgcc

Have to set that collection into the CXX flags and LDFLAGS, I would think.

Just a bit nervous about blowing things up...

Any thoughts, comments, or experience much appreciated

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

Re: qemu, and using gcc45+ compilers on systems set up with LibCxxOnOlderSystems and libc++

[Ken Cunningham]

> Someone else can elaborate if they want, but all I'll say at the moment is 
> that we have encountered an obscene amount of trouble involving g++, 
> libstdc++, and libc++, and a long time ago we basically decided that g++ was 
> dead to us.
> 
> vq

_That_ is exactly what has stopped me from typing those "install gcc" commands 
so far :>

Thanks! 

> 
> clang 3.3 and later do support thread-local storage, provided you have 
> libc++abi 3.6 or later, which we do in MacPorts.
> 

It must be something else then, triggering that error falsely. I read somewhere 
in the qemu discussion list pages this can happen.
I'll approach this differently, and try working back down the chain from my El 
Cap machine instead then.

Thanks,

Ken

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

Re: Can't install qt4?

[Ken Cunningham]

Pat, look here for instructions on how to install qt4 on systems upgraded with 
LibCxxOnOlderSystems.



There is a patch there I submitted about a month ago, and your issue is likely 
the same kind of issue I had, given similar systems.


It is labelled as being a patch to port qt4-mac, so you know you can search for 
issues and patches against specific ports in the tracker:

 

and put qt4-mac into the search box, and you'll see what issues and fixes have 
been found -- will save you some time.



It doesn't look like there is much enthusiasm for applying the patch I made to 
the actual portfile, though, so you might need to do that yourself if you want 
it to work.

It does ultimately work, though:

$ port -v installed qt4*
The following ports are currently installed:
  qt4-mac @4.8.7_4 (active) platform='darwin 10' archs='x86_64'
  qt4-mac-sqlite3-plugin @4.8.7_1 (active) platform='darwin 10' archs='x86_64'



Best,

Ken


On 2016-09-16, at 4:08 PM, [ftp83plus] wrote:

> Hello all, 
> 
> I want to install cutecom on Mac OS X 10.6.
> 
> As a dependency, qt4 needs to be installed as well, but fails:
> http://pastebin.com/YMLLEvZ1 (cut because exceeded 512kb)
> 
> Why?
> Pat
> ___
> macports-users mailing list
> macports-users@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-users

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

Re: User for startupitem.executable

[Ken Cunningham]

Here's a snippet from another port that might help:

startupitem.create  yes
startupitem.netchange   yes
if {[getuid] == 0} {
startupitem.executable  ${prefix}/sbin/asterisk -d -U asterisk -G asterisk
} else {
startupitem.executable  ${prefix}/sbin/asterisk -d
}

and there is a discussion in the mailing list about this from years gone by  
the might be worth reading if that doesn't happen:


Hope this helps.

ken


On 2016-09-17, at 8:12 AM, Javier Alcázar wrote:

> Hi people,
> 
> I'm creating a new Portfile with startupitem.executable, and wondering what 
> is the best way to execute the command with a specific user.
> 
> I tried using "su -c executable args" but with this approach launchd ends up 
> monitoring the "su" process instead of the "executable"
> 
> What would you recommend to do so launchd looks at the "executable" process?
> 
> 
> 
> 
> 
> Cheers
> 
> 
> -- 
> Javier
> ___
> macports-users mailing list
> macports-users@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-users

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

Re: Can't install qt4?

[Ken Cunningham]

Hi Pat,

just rebuilt it to make sure it's all still good with the current port mix -- 
indeed, it built without trouble, with the patch I referenced. It took about 
two and a half hours, though.

If you get stuck and it won't build for you, let me know and I'll send you a 
link to a binary.

ken

On 2016-09-16, at 4:08 PM, [ftp83plus] wrote:

> Hello all, 
> 
> I want to install cutecom on Mac OS X 10.6.
> 
> As a dependency, qt4 needs to be installed as well, but fails:
> http://pastebin.com/YMLLEvZ1 (cut because exceeded 512kb)
> 
> Why?
> Pat
> ___
> macports-users mailing list
> macports-users@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-users

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

Re: Qt 5.x and OS X 10.6

[Ken Cunningham]

Hi Rene,

Thought I'd report progress. Short answer - it's not working so far.

Installed Qt 5.4.2 on a 10.11 machine into the /opt/local/libexec/qt directory, 
then tarballed it and installed it onto a 10.6 machine in the same directory.

The big apps (QTDesigner, etc) don't run on 10.6 due to some missing 
functionality, to no great surprise:
Dyld Error Message:
 Symbol not found: _NSPreferredScrollerStyleDidChangeNotification
 Referenced from: 
/opt/local/libexec/qt/5.4/clang_64/lib/QtWidgets.framework/Versions/5/QtWidgets
 Expected in: /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
in 
/opt/local/libexec/qt/5.4/clang_64/lib/QtWidgets.framework/Versions/5/QtWidgets


In the new installed qt directory on the 10.6 machine, I can find the examples, 
for example in "/opt/local/libexec/qt/Examples/Qt-5.4/gui", and after editing 
the qmake.conf in 
/
opt/local/libexec/qt/5.4/clang_64/mkspecs/macx-clang/qmake.conf

to 
QMAKE_MACOSX_DEPLOYMENT_TARGET = 10.6

I can qmake the .pro file (have to specify the right qmake now, of course)

so frome the gui sample directory

sudo /opt/local/libexec/qt/5.4/clang_64/bin/qmake -spec macx-clang

does generate a makefile and a .qmake.stash file

the .qmake.stash file has to be edited to change the compiler to macports 
clang, and after the initial try failed, I also removed the SDK spec to use 
system roots (as per the troubles with 10.6 with libcxx and qt4-mac)

=
QMAKE_XCODE_DEVELOPER_PATH = /Developer
QMAKE_XCODE_VERSION = 4.2
QMAKE_MAC_SDK.macosx.path = /
QMAKE_MAC_SDK.macosx.version = 10.6
QMAKE_MAC_SDK.macx-clang.macosx.QMAKE_CC = clang
QMAKE_MAC_SDK.macx-clang.macosx.QMAKE_CXX = clang++
QMAKE_MAC_SDK.macx-clang.macosx.QMAKE_FIX_RPATH = \
   /Developer/usr/bin/install_name_tool \
   -id
QMAKE_MAC_SDK.macx-clang.macosx.QMAKE_AR = \
   /Developer/usr/bin/ar \
   cq
QMAKE_MAC_SDK.macx-clang.macosx.QMAKE_RANLIB = \
   /Developer/usr/bin/ranlib \
   -s
QMAKE_MAC_SDK.macx-clang.macosx.QMAKE_LINK = clang++
QMAKE_MAC_SDK.macx-clang.macosx.QMAKE_LINK_SHLIB = clang++
QMAKE_MAC_SDK.macosx.platform_name = macosx


and with all this, the build actually successfully proceeds through to 
completion and generates binaries for the gui examples.

Ultimately, though, running the example application hits an abort() trap in the 
QT core code


Exception Type:  EXC_CRASH (SIGABRT)
Exception Codes: 0x, 0x
Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Application Specific Information:
abort() called

Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
0   libSystem.B.dylib   0x7fff8988f0b6 __kill + 10
1   libSystem.B.dylib   0x7fff8992f9f6 abort + 83
2   org.qt-project.QtCore   0x0001005df119 
qt_message_fatal(QtMsgType, QMessageLogContext const&, QString const&) + 9
3   org.qt-project.QtCore   0x0001005e05d1 
QMessageLogger::fatal(char const*, ...) const + 161
4   org.qt-project.QtGui0x00010002a247 
QGuiApplicationPrivate::createPlatformIntegration() + 6359
5   org.qt-project.QtGui0x00010002a26b 
QGuiApplicationPrivate::createEventDispatcher() + 27
6   org.qt-project.QtCore   0x0001007fa901 
QCoreApplication::init() + 113
7   org.qt-project.QtCore   0x0001007fa877 
QCoreApplication::QCoreApplication(QCoreApplicationPrivate&) + 39
8   org.qt-project.QtGui0x000100027694 
QGuiApplication::QGuiApplication(int&, char**, int) + 228
9   com.medicalrounds.analogclock   0x00013e24 main + 36
10  com.medicalrounds.analogclock   0x000132a4 start + 52
===

so it looks like QT itself stops the run for some reason.

That's as far as I got with this so far. I know you got 5.4.x running on 10.6, 
so perhaps there's some further wrinkle I need to ponder ...

I think 5.3.2 might install on 10.6 (it does for homebrew, I understand). But I 
assume if we/I could get 5.4.x running instead then more qt5 apps might make it 
to 10.6 someday.

Anyway, thanks for your help.

Ken




On 2016-09-15, at 7:09 AM, René J.V. Bertin wrote:

> On Thursday September 15 2016 06:00:44 Ken Cunningham wrote:
> 
> 
>> have been using exactly the install prefix you suggest, as it turns out... 
>> well I put qt5 on the end, but otherwise the same.
> 
> I'd have avoided /opt/local/libexec/qt5 in order to be able to put symlinks 
> in that directory, pointing into the real Qt install directory. Qt's 
> installer adopts a different layout, and it'll be easier to map that onto the 
> one expected by MacPorts (as defined in the Qt5 PortGroup) if 
> /opt/local/libexec/qt5 is still empty.
> 
>> 
>> Been reading your posts to the qt5 interest mailing list for a few clues. I 
>> don't have your skills, but I do have some time

Re: Qt 5.x and OS X 10.6

[Ken Cunningham]

Thanks,

I tried 10.7 first, but 5.4.2 would not install due to this message. Ergo moved 
up the chain to the next machine I had in line. 

>> Symbol not found: _NSPreferredScrollerStyleDidChangeNotification


> It would probably be possible to do this in the mkspec itself, and/or a 
> module.pri file.
> 

check

>> Ultimately, though, running the example application hits an abort() trap in 
>> the QT core code
> 
>> 2   org.qt-project.QtCore0x0001005df119 
>> qt_message_fatal(QtMsgType, QMessageLogContext const&, QString const&) + 9

> 
> You may actually get to see that message by running the application (the one 
> in XXX.app/Contents/MacOS) from a Terminal... 


aha ; of course. Good clue, and should have done that myself naturally... Leads 
me somewhere...

$ ./analogclock
This application failed to start because it could not find or load the Qt 
platform plugin "cocoa".

$ otool -L analogclock
analogclock:
/opt/local/libexec/qt/5.4/clang_64/lib/QtGui.framework/Versions/5/QtGui 
(compatibility version 5.4.0, current version 5.4.2)

/opt/local/libexec/qt/5.4/clang_64/lib/QtCore.framework/Versions/5/QtCore 
(compatibility version 5.4.0, current version 5.4.2)

/System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration 
(compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit 
(compatibility version 1.0.0, current version 275.0.0)
/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL 
(compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/AGL.framework/Versions/A/AGL (compatibility 
version 1.0.0, current version 1.0.0)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current 
version 7.9.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
version 125.2.11)


===
Hey - why is it linked against libstdc++ ??? It was installed on 10.11 from a 
5.4.2 binary. Would've thought it would link against libc++. 

That might be a dealbreaker...

Later on I'll check the linking for the for QT components... bet I find they 
are somehow all messed up too.



> Yes, that's almost certain. But remember that this is a war that's lost in 
> advance, no matter how many battles you win...

Agreed. Sigh. I have several machines with EFI32 boot architectures that are 
stuck in the time warp... unless I can figure out how to do that bootloader 
hack with them I've seen on the 'net.

Besides 10.6 is just great - Rosetta, fast, etc, etc. And it runs enough to be 
useful, but I'd like qt5 if it will be available...

Best,

ken




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

Re: Qt 5.x and OS X 10.6

[Ken Cunningham]

I think this might be progress.

Fixed the libstdc++ linking (my fault, sorta, not theirs -- had to do the 
-std=libc++  in the CXX flags that is pervasive on the LibCxxOnOlderSystems 
machine).

I note this 'platform plugin' issue was all over the 'net when 5.4 came out a 
while back, so I suspect I'll find some kind of fix eventually... so far moving 
the libqcocoa.dylib into various places in the app bundle, or setting the DYLD 
path, hasn't worked, but I have other things to try still.

I'll be mighty pleased if qt5 opens a window here one day :> I'll plug along 
for a bit with 5.4 before I skulk away to 5.3.2.

qt has configuration files all over the place, all calling each other -- what a 
maze to follow...

K

here's the output of what you suggested -- perhaps you see something there that 
I don't immediately notice...

$ otool -L /opt/local/libexec/qt/5.4/clang_64/plugins/platforms/libqcocoa.dylib
/opt/local/libexec/qt/5.4/clang_64/plugins/platforms/libqcocoa.dylib:
libqcocoa.dylib (compatibility version 0.0.0, current version 0.0.0)
/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa 
(compatibility version 1.0.0, current version 21.0.0)
/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon 
(compatibility version 2.0.0, current version 157.0.0)
/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit 
(compatibility version 1.0.0, current version 275.0.0)
/usr/lib/libcups.2.dylib (compatibility version 2.0.0, current version 
2.11.0)
/opt/local/libexec/qt/5.4/clang_64/lib/QtGui.framework/Versions/5/QtGui 
(compatibility version 5.4.0, current version 5.4.2)

/opt/local/libexec/qt/5.4/clang_64/lib/QtCore.framework/Versions/5/QtCore 
(compatibility version 5.4.0, current version 5.4.2)

/System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration 
(compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 
1.2.5)
/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL 
(compatibility version 1.0.0, current version 1.0.0)

/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
 (compatibility version 1.0.0, current version 48.0.0)
/System/Library/Frameworks/AGL.framework/Versions/A/AGL (compatibility 
version 1.0.0, current version 1.0.0)

/opt/local/libexec/qt/5.4/clang_64/lib/QtPrintSupport.framework/Versions/5/QtPrintSupport
 (compatibility version 5.4.0, current version 5.4.2)

/opt/local/libexec/qt/5.4/clang_64/lib/QtWidgets.framework/Versions/5/QtWidgets 
(compatibility version 5.4.0, current version 5.4.2)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 
120.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
version 1213.0.0)
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit 
(compatibility version 45.0.0, current version 1343.14.0)

/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation 
(compatibility version 150.0.0, current version 1151.16.0)

/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices 
(compatibility version 1.0.0, current version 62.0.0)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation 
(compatibility version 300.0.0, current version 1151.16.0)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 
228.0.0)
KensMacBookPro:~ cunningh$ 

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

Re: Qt 5.x and OS X 10.6

[Ken Cunningham]

> 
> %< dlsym /opt/local/libexec/qt/5.4/clang_64/plugins/platforms/libqcocoa.dylib

Aha! Very clever -- I'm learning lots from you. Thanks for taking the time. 

It shows that same missing symbol, 
_NSPreferredScrollerStyleDidChangeNotification

Too bad that darned scroller needs to change style like that -- so much of qt5 
would work otherwise on 10.6!

I wonder if I can get rid of that call somehow :>

Let me try some earlier 5.4 versions and see if this was a new addition ...

K




$ ./dlsym /opt/local/libexec/qt/5.4/clang_64/plugins/platforms/libqcocoa.dylib
./dlsym: can't open 
/opt/local/libexec/qt/5.4/clang_64/plugins/platforms/libqcocoa.dylib 
(dlopen(/opt/local/libexec/qt/5.4/clang_64/plugins/platforms/libqcocoa.dylib, 
5): Symbol not found: _NSPreferredScrollerStyleDidChangeNotification
  Referenced from: 
/opt/local/libexec/qt/5.4/clang_64/lib/QtWidgets.framework/Versions/5/QtWidgets
  Expected in: /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
 in 
/opt/local/libexec/qt/5.4/clang_64/lib/QtWidgets.framework/Versions/5/QtWidgets)

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

Re: Qt 5.x and OS X 10.6

[Ken Cunningham]

On 2016-09-20, at 12:54 PM, René J.V. Bertin wrote:

> That's a Qt bug you should report if 5.4.2 is still supposed to install and 
> work on 10.7!

Rene, I see I made an error there -- I just tried again to install 5.4.2 on 
10.7 and it installed. I must have been slightly mixed up when I thought I had 
tried that and it failed.

Apologies for my error -- this is tricky business, and I'll be more careful 
with my notes.

Ken


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

Re: Can't install qt4?

[Ken Cunningham]

Sure! Basically, you need the diff file in the folder with the Portfile, and 
then you run “patch”. Details to follow:

1. clean out any current leftovers from previous attempts

“sudo port clean qt4-mac”

2. find the existing port file for qt4-mac

$ port file qt4-mac
/opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports/aqua/qt4-mac/Portfile
 <http://rsync.macports.org/release/tarballs/ports/aqua/qt4-mac/Portfile>

3. go into the the portfile’s directory

$ cd 
/opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports/aqua/qt4-mac/

4. take a moment to look and make sure all is well in there

$ pwd
/opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports/aqua/qt4-mac
$ ls -la
total 80
drwxr-xr-x4 root  wheel136  4 Mar  2016 .
drwxr-xr-x  113 root  wheel   3842  4 Sep 17:00 ..
-rw-r--r--1 root  wheel  39430  4 Mar  2016 Portfile
drwxr-xr-x   51 root  wheel   1734 14 Oct  2015 files

5. download the patch from the website link. You can download this using a 
browser to your home folder (easiest to understand, but slowest) and ‘sudo mv’ 
it to where you are

a) download the patch using Safari, for example, to your home folder from the 
website
you want this one: 
https://trac.macports.org/attachment/ticket/51844/qt4-SL-Libcxx-fix-revised.diff
 
<https://trac.macports.org/attachment/ticket/51844/qt4-SL-Libcxx-fix-revised.diff>
right click on the little drawer with the down arrow above it to the right of 
qt4-SL-Libcxx-fix-revised.diff in the attached files to ‘download linked file 
as’ and then save it in your home folder

b) make sure it’s there if you want to…

$ls ~

your should see
qt4-SL-Libcxx-fix-revised.diff

if you see
qt4-SL-Libcxx-fix-revised.diff.hml

then you clicked on the name instead of the badge, and try again until you see 
it with just the .diff ending

c) then move it into your current folder (the port’s folder)
$ sudo mv ~/qt4-SL-Libcxx-fix-revised.diff ./

d) and just for good measure, check that all is well. The portfile and the 
.diff file need to be in the same directory
$ ls
Portfilefiles   
qt4-SL-Libcxx-fix-revised.diff


 (or as a shortcut, once you understand what you’re doing you can just do all 
of step 5 by using 

$ sudo wget 
https://trac.macports.org/attachment/ticket/51844/qt4-SL-Libcxx-fix-revised.diff

 from the port's folder once you have found and copied the proper link with 
Safari

6. You’re almost done. Patch the portfile using the .diff file

sudo patch https://trac.macports.org/ticket/51844>
platform darwin {
if {${os.major} == 9 || ${os.major} == 10} {
if {${configure.cxx_stdlib} eq "libc++"} {
set SDK ""
configure.ldflags-append "-lobjc"
}
}
}


8. when you’re happy, go for it:

sudo port -v install qt4-mac


The above works for me. There are lots of options in the manpages for patch, 
but for this simple application, doesn’t seem you need any. You can back up 
portfiles before patching them if you want, etc, etc — but in this case, if you 
mess things up, you can just “sudo port selfupdate” and macports will set 
everything back to the beginning for you automagically.

Best,

Ken






> On Sep 21, 2016, at 8:48 AM, [ftp83plus]  wrote:
> 
> That may sound silly, but the instructions on how to patch a port are not 
> clear when attempting to apply a patch to a port that hasn't been 
> successfully installed.
> 
> Would you point me to a clear explanation please? 
> 
> El 2016-09-17, a las 21:08, Ken Cunningham escribió:
> 
>> Hi Pat,
>> 
>> just rebuilt it to make sure it's all still good with the current port mix 
>> -- indeed, it built without trouble, with the patch I referenced. It took 
>> about two and a half hours, though.
>> 
>> If you get stuck and it won't build for you, let me know and I'll send you a 
>> link to a binary.
>> 
>> ken
>> 
>> On 2016-09-16, at 4:08 PM, [ftp83plus] wrote:
>> 
>>> Hello all, 
>>> 
>>> I want to install cutecom on Mac OS X 10.6.
>>> 
>>> As a dependency, qt4 needs to be installed as well, but fails:
>>> http://pastebin.com/YMLLEvZ1 <http://pastebin.com/YMLLEvZ1> (cut because 
>>> exceeded 512kb)
>>> 
>>> Why?
>>> Pat
>>> ___
>>> macports-users mailing list
>>> macports-users@lists.macosforge.org 
>>> <mailto:macports-users@lists.macosforge.org>
>>> https://lists.macosforge.org/mailman/listinfo/macports-users 
>>> <https://lists.macosforge.org/mailman/listinfo/macports-users>
>> 
> 

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

Re: Can't install qt4?

[Ken Cunningham]

When something like that happens, it's best if you take a look and see.
What's it telling you -- hmm-- what could be ending in the middle of the line?
maybe your patch download file is incomplete for some reason?


$cat qt4-SL-Libcxx-fix-revised.diff 

should look like this (as you can also see from web page).

-


--- Portfile.orig   2016-09-18 21:43:07.0 -0700
+++ Portfile2016-09-18 21:45:27.0 -0700
@@ -585,6 +585,18 @@
 
 }
 
+# on Leopard and Snow Leopard with libc++ForOlderSystems installed, SDK 
must be unset as we can only use system libraries
+# also, a missing library link must be replaced for build to succeed
+# <https://trac.macports.org/ticket/51844>
+platform darwin {
+if {${os.major} == 9 || ${os.major} == 10} {
+if {${configure.cxx_stdlib} eq "libc++"} {
+set SDK ""
+configure.ldflags-append "-lobjc"
+}
+}
+}
+
 # set the SDK, if it was found and exists
 
 if {[file exists ${SDK}]} {


--

if not, I guess you should download it again. Or copy/paste the part above, as 
it's very short :>

Best,

K


On 2016-09-21, at 6:38 PM, [ftp83plus] wrote:

> Hmmm, I get:
> 
> sudo patch  patch unexpectedly ends in middle of line
> patch:  Only garbage was found in the patch input.
> 
> 
> El 2016-09-21, a las 13:40, Ken Cunningham escribió:
> 
>> https://trac.macports.org/attachment/ticket/51844/qt4-SL-Libcxx-fix-revised.diff
> 

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

Re: Can't install qt4?

[Ken Cunningham]

Can't see exactly what the wget URL was I sent you this afternoon, but the 
proper raw file URL is this one (as you can see from the ticket page).

​​https://trac.macports.org/raw-attachment/ticket/51844/qt4-SL-Libcxx-fix-revised.diff

The link listed below in your message gets you an HTML-ized version, which of 
course wouldn't work due to the HTMl.

Best,

Ken



On 2016-09-21, at 6:38 PM, [ftp83plus] wrote:

> Hmmm, I get:
> 
> sudo patch  patch unexpectedly ends in middle of line
> patch:  Only garbage was found in the patch input.
> 
> 
> El 2016-09-21, a las 13:40, Ken Cunningham escribió:
> 
>> https://trac.macports.org/attachment/ticket/51844/qt4-SL-Libcxx-fix-revised.diff
> 

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

Re: how to maintain multiple active versions of a port (e.g. octave)?

[Ken Cunningham]

> 
> One last question … can you give me a quick idea of how much work would be 
> involved in me attempting to locally implement the first approach you 
> mentioned (different ports for different versions of octave). That is, 
> starting with the files for the 3.8.2 revision of the octave port, what would 
> be involved in creating a local octave38 port that could be installed 
> simultaneously with the regular, current octave port? Am I crazy to attempt 
> this?
> 


I see octave is a reasonably complex portfile. Not easy to fiddle with, I would 
think.

There is the possibility of having separate macports installations, under 
different prefixes. You could set your PATH to the one you want to use.

or alternatively you could swap /opt/local macports installations in and out 
(moving /opt/local to /opt/local-octave38, say, and then installing /opt/local 
for octave 4). Watch out for anything that might go into ${applications-dir} 
with this approach, if you try it. Might have to swap that too.

you'd have to keep your wits about you, but that might work to have multiple 
octave versions to work on one machine.

Both those only let you use one octave version at a time, but at least they are 
on the same machine.

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

Re: osxfuse

[Ken Cunningham]

On 2016-09-23, at 12:57 PM, Raoul MEGELAS wrote:

> info:build OSXFUSEBuildTool(): building OSXFUSE kernel extension 
> and tools
> :info:build xcrun: error: missing DEVELOPER_DIR path: 
> :info:build OSXFUSEBuildTool() failed: xcodebuild cannot build configuration 
> Release.

Looks like a cmake issue. 

xcrun is gone, so there is no Developer_Dir found

if you edit the script (look into similar errors in qt5) to change xcrun to 
xcodebuild you might get somewhere.

check this 

K


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

Re: osxfuse @3.5.0 build error

[Ken Cunningham]

and sometimes because of the tremendous support by people like jeremy and many 
others, macports can build things that don’t exist out there in the world — 
like a current version of OpenSCAD or Widelands that runs on 10.6, for example.

or versions of software you can customize to your liking, using the basic 
macports port file as a template.

Ken




> On Sep 24, 2016, at 6:22 PM, Brandon Allbery  wrote:
> 
> 
> On Sat, Sep 24, 2016 at 9:18 PM, Al Varnell  > wrote:
> Sorry for my ignorance here, but why do we need MacPorts to maintain a port 
> when there is are perfectly good installers available on GitHub 
>  > including a 
> developer release of version 3.5.1 posted close to a week ago?
> 
> The same can be said for a fair chunk of the software in MacPorts. Some of us 
> prefer not to have to chase down and (possibly build and) install every 
> single piece of software ourselves. That's the *point* of MacPorts.
> 
> -- 
> 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

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

LibCxxOnOlderSystems - and more software that is pushing for gcc

[Ken Cunningham]

I realize I asked this a bit ago about qemu, and received a very reasonable big 
caution regarding any attempt to combine gcc of any version on a system set up 
with LibCxxOnOlderSystems...

but I just thought I'd mention that a few more fairly common ports appear to be 
failing to install without access to gcc, so this might turn out to be a 
problem.

gimp
octave
... more I don't know about yet?

$ sudo port install gimp2 +quartz
--->  Computing dependencies for gimp2
--->  Dependencies to be installed: babl gegl libopenraw libspiro lua w3m 
gimp-help-en gsed pngcrush libwmf py27-pygtk py27-numpy gcc6 libgcc webkit-gtk 
py27-simplejson

in gimp's case, it pulls in py27-numpy that seems to want to pull in gcc6 no 
matter what variants I try.


$ port info py27-numpy
py27-numpy @1.11.1 (python, math)
Variants: atlas, clang37, gcc49, gcc5, gcc6, gcc7, [+]gfortran, 
llvm, openblas, universal

Description:  The core utilities for the scientific library scipy for 
Python
Homepage: https://github.com/numpy/numpy

Build Dependencies:   gcc6, clang-3.7


octave has what seems to be a hard build dep for gcc6 directly, even if I 
select the +clang37 variant...

and letting gcc6 start building, it certainly links against libstdc++ (in the 
freshly built libgcc), which will blow everything up.

So this could turn out to be a hard choice for systems set up like this, I 
guess, unless Jeremy has a fancy trick up his sleeve.

At the moment, it appears you can either get c++11 ports, OR any ports which 
require gcc, but not both. But then I see "-std=gnu++11" in this long line, 
which puzzles me a bit...


Ken


a typical link example below:

libtool: compile:  
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc6/libgcc/work/build/./gcc/xgcc
 -shared-libgcc 
-B/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc6/libgcc/work/build/./gcc
 -nostdinc++ 
-L/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc6/libgcc/work/build/x86_64-apple-darwin10/libstdc++-v3/src
 
-L/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc6/libgcc/work/build/x86_64-apple-darwin10/libstdc++-v3/src/.libs
 
-L/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc6/libgcc/work/build/x86_64-apple-darwin10/libstdc++-v3/libsupc++/.libs
 -B/opt/local/x86_64-apple-darwin10/bin/ 
-B/opt/local/x86_64-apple-darwin10/lib/ -isystem 
/opt/local/x86_64-apple-darwin10/in
 clude -isystem /opt/local/x86_64-apple-darwin10/sys-include 
-I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc6/libgcc/work/gcc-6.1.0/libstdc++-v3/../libgcc
 
-I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc6/libgcc/work/build/x86_64-apple-darwin10/libstdc++-v3/include/x86_64-apple-darwin10
 
-I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc6/libgcc/work/build/x86_64-apple-darwin10/libstdc++-v3/include
 
-I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc6/libgcc/work/gcc-6.1.0/libstdc++-v3/libsupc++
 -D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra -Wwrite-strings 
-Wcast-qual -Wabi -fdiagnostics-show-location=once -fvisibility-inlines-hidden 
-ffunction-sections -fdata-sections -frandom-seed=atexit_thread.lo -g -O2 -pipe 
 -Os -std=gnu++11 -c 
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc6/libgcc/work/gcc-6.1.0/libstdc++-v3/libsupc++/atexit_thread.cc
  -fno-common -DPIC -D_GLIBCXX_SHARED -o atexit_thread.o

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

Re: LibCxxOnOlderSystems - and more software that is pushing for gcc

[Ken Cunningham]

> 
> The problem is not really about libc++; it's about mixing multiple C++
> runtimes.

Indeed.

What is happening exactly on my MacPros running 10.11, I wonder? Software 
installed by macports on 10.11 is using clang++ (mostly) and g++ (sometimes). 
clang++ is linking against libc++, and g++ is presumably  linking against 
libstdc++ as that is what it does -- yet there appear to be no visible 
issues...and these libraries find each other. 

Why exactly is the situation different on a LibCxxOnOlderSystems installation?


> As far as I know, you can use the C or Fortran
> compilers as much as you'd like. Several ports do this for various
> reasons. 

But not easily to link c++ code against libc++. I sent the link on how to do 
that previously, and may be forced to explore that. It just looks like a lot of 
messing with the compiler commands on every port using g++, which seems 
unpleasant -- unless I were to wrap g++ in a shell script that does it 
automatically, perhaps...



> These dependencies are coming from the +gfortran variants, which
> instruct the builds to use the Fortran compiler from gcc6. This is fine
> and expected.

but won't work on LibCxxOnOlderSystems, if it links the binaries against 
lilbstdc++

> What links against libstdc++, specifically?

gcc6 itself, at least. And by default at least, any c++ code gcc would compile 

> 
> Jeremy unfortunately cannot do much of anything about GCC. I believe
> Apple employees are not allowed to look at GPL3 code.

I wasn't thinking he'd need to read the gcc compiler code.

> I wouldn't be surprised if GCC used C++11 features. It doesn't really
> matter because it is self-hosted.

It's an alternative way to get c++11 code compiled; I was just noticing that 
clang++/libc++ aren't the only option for c++11.


It would appear there are a few choices.

1. give up and accept it's an either / or situation
2. just let it go on, and see how it works with cross linking -- is this what 
10.11 macports does?
3. figure out how to make this work: 
, possibly by 
wrapping g++ in a shell script that does it for every use.
4. a parallel installation of macports with libstdc++ and gcc, to install gimp, 
octave, qemu, and whatever other similar gcc-requiring ports come along.



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

Re: LibCxxOnOlderSystems - and more software that is pushing for gcc

[Ken Cunningham]

> 
> Why would the Fortran compiler link its build products against
> libstdc++? Are you seeing this behavior?


> Please provide evidence that these ports are actually using g++. If they
> are, then they should be fixed to not do so. If they are not and are
> only using gcc and/or gfortran, then *there is no problem*.

> 
> FWIW, I have py35-numpy+gcc6 installed, and none of its object files
> link to libstdc++, although many of them do link to MacPorts'
> libgcc_s.1.dylib.
> 
> % port -q contents py35-numpy | xargs otool -L | fgrep 'libstdc++'
> % echo $?
> 1


Lawrence, perhaps you've hit upon the final answer to this, then.

gcc6 is required for some ports, and gets pulled in -- but apparently only for 
it's fortran compiler (at least if what you've said about it being a macports 
bug to use g++ holds true).

And although the fortran compiler is written in C and C++ (according to the gcc 
fortran website) it does not in the end actually link it's output binaries to 
libstdc++ (as you've just demonstrated) so there is no worry about letting it 
proceed to completion on a system running Macports on 10.11, or any other 
version, including LibCxxOnOlderSystems.

So it's a "non problem", in the end.

Thanks, everyone. I always learn something from these brief discussions.

Ken


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

Re: Can't install qt4?

[Ken Cunningham]

AS life has it, the patch was applied to the main macports trunk, and probably 
is on the portfile now if you selfupdate.

 ah, but look what you've learned!

Best,

Ken




On 2016-09-25, at 7:18 PM, [ftp83plus] wrote:

> Finally patched. One has to pay attention to right-click (or cmd+click on 
> Mac) the arrow right next 
> to the file name, not the file name itself. 
> 
> Thanks Ken, 
> Pat
> 
> El 2016-09-22, a las 02:35, Ken Cunningham escribió:
> 
>> Can't see exactly what the wget URL was I sent you this afternoon, but the 
>> proper raw file URL is this one (as you can see from the ticket page).
>> 
>> ​​https://trac.macports.org/raw-attachment/ticket/51844/qt4-SL-Libcxx-fix-revised.diff
>> 
>> The link listed below in your message gets you an HTML-ized version, which 
>> of course wouldn't work due to the HTMl.
>> 
>> Best,
>> 
>> Ken
>> 
>> 
>> 
>> On 2016-09-21, at 6:38 PM, [ftp83plus] wrote:
>> 
>>> Hmmm, I get:
>>> 
>>> sudo patch >> patch unexpectedly ends in middle of line
>>> patch:  Only garbage was found in the patch input.
>>> 
>>> 
>>> El 2016-09-21, a las 13:40, Ken Cunningham escribió:
>>> 
>>>> https://trac.macports.org/attachment/ticket/51844/qt4-SL-Libcxx-fix-revised.diff
>>> 
>> 
> 

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

fetching of some ports fails, but you can wget them from the same URL

[Ken Cunningham]

I've noticed this behaviour a few times recently, most recently today with 
hexchat, but this is not the only example.

Trying to get a file using macports' fetch fails, but you can manually wget it 
without trouble.

I'm not sure if it's an SSL certificate thing, or why this is happening, 
exactly.

Sorry I don't know how to debug the exact problem further than that.

Here's an example.

Ken


$ sudo port upgrade hexchat
--->  Computing dependencies for hexchat
--->  Fetching distfiles for hexchat
--->  Attempting to fetch hexchat-2.12.1.tar.xz from 
https://dl.hexchat.net/hexchat/
--->  Attempting to fetch hexchat-2.12.1.tar.xz from 
http://sea.us.distfiles.macports.org/macports/distfiles/hexchat
--->  Attempting to fetch hexchat-2.12.1.tar.xz from 
http://ykf.ca.distfiles.macports.org/MacPorts/mpdistfiles/hexchat
--->  Attempting to fetch hexchat-2.12.1.tar.xz from 
https://distfiles.macports.org/hexchat
--->  Attempting to fetch hexchat-2.12.1.tar.xz from 
http://cjj.kr.distfiles.macports.org/hexchat
--->  Attempting to fetch hexchat-2.12.1.tar.xz from 
http://mse.uk.distfiles.macports.org/sites/distfiles.macports.org/hexchat
--->  Attempting to fetch hexchat-2.12.1.tar.xz from 
http://lil.fr.distfiles.macports.org/hexchat
--->  Attempting to fetch hexchat-2.12.1.tar.xz from 
http://aarnet.au.distfiles.macports.org/pub/macports/mpdistfiles/hexchat
--->  Attempting to fetch hexchat-2.12.1.tar.xz from 
http://osl.no.distfiles.macports.org/hexchat
--->  Attempting to fetch hexchat-2.12.1.tar.xz from 
http://fco.it.distfiles.macports.org/mirrors/macports-distfiles/hexchat
--->  Attempting to fetch hexchat-2.12.1.tar.xz from 
http://nue.de.distfiles.macports.org/hexchat
--->  Attempting to fetch hexchat-2.12.1.tar.xz from 
http://nou.nc.distfiles.macports.org/pub/macports/distfiles.macports.org/hexchat
--->  Attempting to fetch hexchat-2.12.1.tar.xz from 
http://jog.id.distfiles.macports.org/macports/distfiles/hexchat
--->  Attempting to fetch hexchat-2.12.1.tar.xz from 
http://jnb.za.distfiles.macports.org/distfiles/hexchat
--->  Attempting to fetch hexchat-2.12.1.tar.xz from 
http://her.gr.distfiles.macports.org/hexchat
--->  Attempting to fetch hexchat-2.12.1.tar.xz from 
http://svn.macports.org/repository/macports/distfiles/hexchat
Error: org.macports.fetch for port hexchat returned: fetch failed
Please see the log file for port hexchat for details:
   
/opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_irc_hexchat/hexchat/main.log
Error: Unable to upgrade port: 1
To report a bug, follow the instructions in the guide:
   http://guide.macports.org/#project.tickets

$ locate distfiles | grep hexchat
/opt/local/var/macports/distfiles/hexchat
/opt/local/var/macports/distfiles/hexchat/hexchat-2.10.2.tar.xz

$ cd /opt/local/var/macports/distfiles/hexchat/

$ sudo wget https://dl.hexchat.net/hexchat/hexchat-2.12.1.tar.xz
--2016-09-27 06:37:15--  https://dl.hexchat.net/hexchat/hexchat-2.12.1.tar.xz
Resolving dl.hexchat.net (dl.hexchat.net)... 104.27.132.137, 104.27.133.137, 
2400:cb00:2048:1::681b:8589, ...
Connecting to dl.hexchat.net (dl.hexchat.net)|104.27.132.137|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1585532 (1.5M) [application/octet-stream]
Saving to: ‘hexchat-2.12.1.tar.xz’

hexchat-2.12.1.tar.xz   
100%[==>]   1.51M  5.69MB/s 
   in 0.3s

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

Re: fetching of some ports fails, but you can wget them from the same URL

[Ken Cunningham]

That explains it. The port I remembered failing to fetch from a few weeks ago 
turns out to have been the older version of hexchat, I recalled sometime later 
this morning.

Ken



On 2016-09-27, at 3:28 PM, Rainer Müller wrote:

> On 2016-09-27 15:45, Ken Cunningham wrote:
>> I've noticed this behaviour a few times recently, most recently today with 
>> hexchat, but this is not the only example.
>> 
>> Trying to get a file using macports' fetch fails, but you can manually wget 
>> it without trouble.
>> 
>> I'm not sure if it's an SSL certificate thing, or why this is happening, 
>> exactly.
> 
> In case of hexchat, the download server enforces strong security that
> your client cannot fulfill. Our mirror infrastructure can also not
> handle that.
> 
> https://trac.macports.org/ticket/51112#comment:6
> 
> MacPorts itself uses libcurl for fetching, which is linked against
> OpenSSL 0.9.8 or earlier on old versions of OS X. wget from MacPorts
> will use OpenSSL 1.0, which is recent enough.
> 
> Rainer
> ___
> macports-users mailing list
> macports-users@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-users

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

Re: osxfuse @3.5.0 build error

[Ken Cunningham]

> 
> info:build pbxcp: mount_osxfuse: No such file or directory
> :info:build pbxcp: mount_osxfuse: No such file or directory
> :info:build CpResource

> :info:build The following build commands failed:
> :info:build mount_osxfuse:
> :info:build CompileC

> build/mount_osxfuse.build/Release/mount_osxfuse.build/Objects-normal/x86_64/mount_osxfuse.o
> /Volumes/MacPorts/hopeful/build/_opt_macports-git_trunk_dports_fuse_osxfuse/osxfuse/work/osxfuse-osxfuse-cc7d953/support/mount_osxfuse/mount_osxfuse.c
> normal x86_64 c com.apple.compilers.llvmgcc42


First of all, it’s a very different kind of port. It selects it’s own compilers 
(llvmgcc42), and has intricate links into the Xcode installation.

Most of the options I tried in the portfile that might have normally worked 
(supported_archs etc) have no effect at all on this build.

As you point out, the build fails when trying to build mount_osxfuse.o in 
architecture x86_64. The i386 build does seem to get built on my system.

I think you might make progress initially by trying to just build it yourself 
in the work directory, using the build script. 

The README.md says that you should just be able to run ./build.sh -t 
distribution from there (with sudo of course for the macports location) — but 
that fails with the error above.

Maybe it can be limited to a specific architecture?

The architectures are passed in via an array, and I tried a number of different 
versions of 

 ./build.sh -t distribution -a i386
 ./build.sh -t distribution -architecture i386
 ./build.sh -t distribution -architecture = i386

but so far haven’t divined the secret code.

Once you have it building in the work directory with the proper chord of 
options, translating that to the Portfile will be easier.


Or maybe we’ll just have to get the developer to tell us what we’re doing wrong 
here.


I hope this helps.

Ken



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

Re: osxfuse @3.5.0 build error

[Ken Cunningham]

> 
> cc1: warnings being treated as errors
> /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_fuse_osxfuse/osxfuse/work/osxfuse-osxfuse-cc7d953/support/mount_osxfuse/mount_osxfuse.c:
>  In function 'send_fd':
> /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_fuse_osxfuse/osxfuse/work/osxfuse-osxfuse-cc7d953/support/mount_osxfuse/mount_osxfuse.c:603:
>  warning: implicit conversion shortens 64-bit value into a 32-bit value
> 
> I'm not sure if that has anything to do with architecture mismatches; rather, 
> it sounds like a perfectly normal bug in handling numbers of different sizes, 
> that the developers of osxfuse should resolve.

It certainly seems very likely this is the error that needs to be fixed.


I notice in the development tree there is some activity on this file 2 days ago:

https://github.com/osxfuse/support/tree/support/osxfuse-3/mount_osxfuse.

mount_osxfuse.c 

   (mount_osxfuse) Fix build warning on Mac OS X 10.6 


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

Re: osxfuse @3.5.0 build error - fixed

[Ken Cunningham]

> 
> I notice in the development tree there is some activity on this file 2 days 
> ago:
> 
> https://github.com/osxfuse/support/tree/support/osxfuse-3/mount_osxfuse.
> 
> mount_osxfuse.c   (mount_osxfuse) Fix build warning on Mac OS X 10.6
> 


So that fixed the osxfuse build on 10.6 for me this morning.

Just go get that file 

sudo port extract osxfuse

and replace the current one with the new one

sudo port build osxfuse

and the build goes through to completion, for me just now on 10.6

Best

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

Re: LLVM not supported on Sierra?

[Ken Cunningham]

llvm-3.5 is not supported on macOS Sierra or newer.

I don't think llvm-3.5 is a version to be used. One of the Apple engineers
frequently steers people to newer versions.

Why not llvm-3.7, 3.8, or 3.9?

On Sun, Oct 2, 2016 at 8:05 PM, Dave Horsfall  wrote:

> Doing a "port upgraded outdated" after installing Sierra (and had some
> trouble with X11), I get this:
>
> --->  Computing dependencies for llvm-3.5
> --->  Fetching distfiles for llvm-3.5
> Error: llvm-3.5 is not supported on macOS Sierra or newer.
> Error: org.macports.fetch for port llvm-3.5 returned: unsupported platform
> Please see the log file for port llvm-3.5 for details:
>
> /opt/local/var/macports/logs/_opt_local_var_macports_
> sources_rsync.macports.org_release_ports_lang_llvm-3.5/llvm-3.5/main.log
> Error: Unable to upgrade port: 1
>
> main.log:
>
> version:1
> :msg:main --->  Computing dependencies for llvm-3.5:info:main .:debug:main
> Searching for dependency: xz
> :debug:main Found Dependency: receipt exists for xz
> :msg:main
> :debug:main Executing org.macports.main (llvm-3.5)
> :debug:main changing euid/egid - current euid: 0 - current egid: 20
> :debug:main egid changed to: 20
> :debug:main euid changed to: 502
> :debug:fetch fetch phase started at Mon Oct  3 13:55:43 AEDT 2016
> :notice:fetch --->  Fetching distfiles for llvm-3.5
> :debug:fetch Executing proc-pre-org.macports.fetch-fetch-0
> :debug:fetch Executing proc-pre-org.macports.fetch-fetch-1
> :error:fetch llvm-3.5 is not supported on macOS Sierra or newer.
> :error:fetch org.macports.fetch for port llvm-3.5 returned: unsupported
> platform
> :debug:fetch Error code: NONE
> :debug:fetch Backtrace: unsupported platform
> while executing
> "proc-pre-org.macports.fetch-fetch-1 org.macports.fetch"
> ("eval" body line 1)
> invoked from within
> "eval $pre $targetname"
> :info:fetch Warning: targets not executed for llvm-3.5:
> org.macports.destroot or
> rg.macports.configure org.macports.build
> :notice:fetch Please see the log file for port llvm-3.5 for details:
> /opt/local/var/macports/logs/_opt_local_var_macports_
> sources_rsync.macports.org_release_ports_lang_llvm-3.5/llvm-3.5/main.log
>
> Is this a problem with Macports itself?  Or have I screwed up as usual?
>
> --
> Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will
> suffer."
> ___
> macports-users mailing list
> macports-users@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-users
>
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Subversion checkout failed...?

[Ken Cunningham]

looks like v8 is here now:

https://github.com/v8/v8

K

On 2016-10-08, at 8:07 AM, Ryan Schmidt wrote:

> 
>> On Oct 8, 2016, at 9:55 AM, Carlo Tambuatco  wrote:
>> 
>> Made the leap to Sierra yesterday and a few ports have had trouble 
>> downloading.
>> 
>> The v8 and word2vec ports both failed to be checked out via subversion.
>> 
>> It’s a lot to get into, I’ll just include the log files for both of them 
>> here…
> 
> These projects were both hosted at Google Code. Google Code no longer exists, 
> so it's true that you can't check out the code from their now nonexistent 
> servers. The ports need to be updated for wherever those projects have moved 
> to.
> 
> The ticket for v8 is https://trac.macports.org/ticket/52532
> 
> There are no open tickets for word2vec; feel free to file one.
> 
> 
> ___
> macports-users mailing list
> macports-users@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-users

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

gtk2 and gtk3 ports and +x11 vs +quartz variant worries

[Ken Cunningham]

Is there a wiki page I missed perhaps for how to sort out the conflicting 
requirements for +x11 and +quartz in the various gtk port implementations?

I understand the basic reasons for this, but  I quite frequently seem to find 
myself on the wrong side of the line with this.

Perhaps there is no answer to satisfy all requirements, and I get that. A 
'cheat sheet' of what ports go with what variants (+x11 vs +quartz) would be 
nice, if anyone has that level of experience with it.

Best, Ken


Here are this mornings issues (after 24 hours of compiling following 
yesterday's port selfupdate). I'm sure I'll eventually figure out how to 
straighten this out


port upgrade outdated led to -->

--->  Computing dependencies for gcr
Error: org.macports.archivefetch for port gcr returned: gtk3 must be installed 
with +x11.


$ sudo port install gtk3 +x11
Error: org.macports.archivefetch for port gtk3 returned: gdk-pixbuf2 must be 
installed with +x11.

$ sudo port install gdk-pixbuf2 +x11
sudo port install gdk-pixbuf2 +x11

--->  Found 42 broken file(s), matching files to ports   
--->  Found 7 broken port(s), determining rebuild order
--->  Rebuilding in order
 gtk2 @2.24.31 +universal+x11
 py27-pygtk @2.24.0 +quartz-x11
 avahi @0.6.31 +gtk+gtk3+quartz
 gtk-osx-application-gtk2 @2.0.8 +universal
 libsexy @0.1.11 
 hexchat @2.12.1 +quartz+ssl
 webkit-gtk @2.4.11 +quartz+video

Error: org.macports.archivefetch for port py27-pygtk returned: gtk2 must be 
installed with +quartz.



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

Re: gtk2 and gtk3 ports and +x11 vs +quartz variant worries

[Ken Cunningham]

> 
> 
> These are all legitimate and in my experience tend to come from trying to 
> switch from building +x11 to building +quartz
> without "cleaning the slate" as it were.  I always do this when switching 
> like this (say with gimp2 that can build
> either way).
> 
> sudo port install gimp2 (implied +x11 since it builds with x11 by default)
> sudo port deactivate active
> sudo port install gimp2 +quartz
> 
> This ensures that all the various sub-dependencies get built in the correct 
> flavor.
> 
> Or install a separate MacPorts instance for building +quartz.  I've 
> successfully done this as well.
> 
> I run into these issues alot with the GNOME ports because some GNOME ports 
> can build +quartz but not all.  In
> particular, ports that are part of the GNOME desktop infrastructure (e.g. 
> gnome-desktop, gnome-settings-daemon) still
> use X11 features directly and thus can't be built +quartz.  Others, like gcr, 
> are just old implementations that use some
> X11 hack instead of porting to a backend agnostic gtk3 implementation.
> 
> My general guidelines are this: if there is no +quartz variant, it builds 
> with X11.  This includes ports with no variant
> at all.  Only ports with +quartz variants should be assumed to build that way.
> 
> Dave
> 

Very helpful, thanks Dave.

It’s true — I had decided to go with +quartz (why not, I thought) but then 
something I wanted to install required +x11 along the way and I blew things up 
when I tried to satisfy that dependency.

 I see there was a similar thread on the dev list that I noticed afterwards. 

Would there be use for a list or table of gtk ports that are only available in 
either quartz or x11 variants, but not both, so someone might know going in 
before they start which way to lean? Perhaps I might work on creating something 
like that, for my own education if for no other reason.

I can see the logic behind the separate installation for the other variant.

Thanks again,

Ken


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

Re: python, port select and group

[Ken Cunningham]

> This problem was brought up previously on this list. You may have
> uninstalled python34 at some point while it was selected; the "port
> select" code doesn't handle this properly and leaves dangling symlinks.

There is also a very useful port (for me) called "symlinks" that helps find and 
optionally manage these kinds of things.

Ken

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

Re: gcc6 build failed on Snow Leopard

[Ken Cunningham]

  gcc6 @6.1.0_0 platform='darwin 10' archs='x86_64'
  gcc6 @6.2.0_0 (active) platform='darwin 10' archs='x86_64'

  libgcc @6.1.0_0 platform='darwin 10' archs='x86_64'
  libgcc @6.2.0_0 (active) platform='darwin 10' archs='x86_64'


It does build -- but I recall there was something, perhaps ... I'll see if I 
can remember what it was

Ken




On 2016-10-13, at 2:58 PM, Richard L. Hamilton wrote:

> This was a build prerequisite for py27-numpy, so I can't build that either.  
> It failed both with and without +universal (I think I have the latter set as 
> default).
> 
> 
> Hardware Version: Mac mini (Mid 2007)
> Model Identifier: Macmini2,1
> Mac OS X 10.6.8 10K549 (Snow Leopard)
> Xcode 3.2.6 DevToolsSupport-1806.0
> MacPorts Version: 2.3.4
> 
> 
> 
> :info:build make[3]: Entering directory 
> `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc6/gcc6/work/build'
> :info:build rm -f stage_current
> :info:build make[3]: Leaving directory 
> `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc6/gcc6/work/build'
> :info:build Comparing stages 2 and 3
> :info:build warning: gcc/cc1-checksum.o differs
> :info:build warning: gcc/cc1obj-checksum.o differs
> :info:build warning: gcc/cc1objplus-checksum.o differs
> :info:build warning: gcc/cc1plus-checksum.o differs
> :info:build Bootstrap comparison failure!
> :info:build x86_64-apple-darwin10/libstdc++-v3/src/c++11/cxx11-locale-inst.o 
> differs
> :info:build x86_64-apple-darwin10/libstdc++-v3/src/c++11/cxx11-wlocale-inst.o 
> differs
> :info:build x86_64-apple-darwin10/libstdc++-v3/src/c++11/locale-inst.o differs
> :info:build x86_64-apple-darwin10/libstdc++-v3/src/c++11/wlocale-inst.o 
> differs
> :info:build make[2]: *** [compare] Error 1
> :info:build make[2]: Leaving directory 
> `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc6/gcc6/work/build'
> :info:build make[1]: *** [stage3-bubble] Error 2
> :info:build make[1]: Leaving directory 
> `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc6/gcc6/work/build'
> :info:build make: *** [bootstrap-lean] Error 2
> :info:build make: Leaving directory 
> `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc6/gcc6/work/build'
> :info:build Command failed:  cd 
> "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc6/gcc6/work/build"
>  && /usr/bin/make -j2 -w bootstrap-lean 
> :info:build Exit code: 2
> :error:build org.macports.build for port gcc6 returned: command execution 
> failed
> :debug:build Error code: CHILDSTATUS 69968 2
> :debug:build Backtrace: command execution failed
>while executing
> "system -nice 0 $fullcmdstring"
>("eval" body line 1)
>invoked from within
> "eval system $notty $nice \$fullcmdstring"
>invoked from within
> "command_exec build"
>(procedure "portbuild::build_main" line 8)
>invoked from within
> "portbuild::build_main org.macports.build"
>("eval" body line 1)
>invoked from within
> "eval $procedure $targetname"
> :info:build Warning: targets not executed for gcc6: org.macports.activate 
> org.macports.build org.macports.destroot org.macports.install
> :notice:build Please see the log file for port gcc6 for details:
>
> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc6/gcc6/main.log
> ___
> macports-users mailing list
> macports-users@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-users

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

Re: gcc6 build failed on Snow Leopard

[Ken Cunningham]

Weird. Is this on the same exact machine? 

on one hand the checksum differs and it says bootstrap fails.
on the other, the checksum differs and it says comparison sucessful.


No difference in file system / case sensitivitiy?
? race condition involving parallel build threads?
on one hand the checksum differs and it says bootstrap fails.
on the other, the checksum differs and it says comparison sucessful.

K




relevant part where the build logs diverge:

failed build:

make[5]: Entering directory 
`/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_gcc6/gcc6/work/build/x86_64-apple-darwin10/libstdc++-v3/testsuite'
make[5]: Nothing to be done for `all'.
make[5]: Leaving directory 
`/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_gcc6/gcc6/work/build/x86_64-apple-darwin10/libstdc++-v3/testsuite'
Making all in python
make[5]: Entering directory 
`/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_gcc6/gcc6/work/build/x86_64-apple-darwin10/libstdc++-v3/python'
sed -e 's,@pythondir@,/opt/local/share/gcc-6/gcc-6.2.0/python,' \
-e 's,@toolexeclibdir@,/opt/local/lib/gcc6,' < 
/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_gcc6/gcc6/work/gcc-6.2.0/libstdc++-v3/python/hook.in
 > gdb.py
make[5]: Leaving directory 
`/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_gcc6/gcc6/work/build/x86_64-apple-darwin10/libstdc++-v3/python'
make[5]: Entering directory 
`/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_gcc6/gcc6/work/build/x86_64-apple-darwin10/libstdc++-v3'
true "AR_FLAGS=rc" "CC_FOR_BUILD=/usr/bin/gcc-4.2 -arch x86_64" 
"CC_FOR_TARGET=/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_gcc6/gcc6/work/build/./gcc/xgcc
 
-B/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_gcc6/gcc6/work/build/./gcc/"
 "CFLAGS=-g -O2 -pipe -Os" "CXXFLAGS=-g -O2 -pipe -Os" 
"CFLAGS_FOR_BUILD=-pipe -Os" "CFLAGS_FOR_TARGET=-g -O2 -pipe 
-Os" "INSTALL=/usr/bin/install -c" 
"INSTALL_DATA=/usr/bin/install -c -m 644" 
"INSTALL_PROGRAM=/usr/bin/install -c" 
"INSTALL_SCRIPT=/usr/bin/install -c" "LDFLAGS=" 
"LIBCFLAGS=-g -O2 -pipe -Os" "LIBCFLAGS_FOR_TARGET=-g -O2 -pipe 
-Os" "MAKE=/usr/bin/make" "MAKEINFO=makeinfo 
--split-size=500 --split-size=500 --split-size=500   " 
"SHELL=/bin/sh" "RUNTESTFLAGS=" 
"exec_prefix=/opt/local" "infodir=/opt/loc
 al/share/info" "libdir=/opt/local/lib/gcc6" 
"includedir=/opt/local/include/gcc6" "prefix=/opt/local" 
"tooldir=/opt/local/x86_64-apple-darwin10" 
"gxx_include_dir=/opt/local/include/gcc6/c++/" 
"AR=/opt/local/bin/ar" 
"AS=/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_gcc6/gcc6/work/build/./gcc/as"
 
"LD=/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_gcc6/gcc6/work/build/./gcc/collect-ld"
 "RANLIB=/opt/local/bin/ranlib" 
"NM=/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_gcc6/gcc6/work/build/./gcc/nm"
 "NM_FOR_BUILD=" "NM_FOR_TARGET=/opt/local/bin/nm" 
"DESTDIR=" "WERROR=" DO=all multi-do # /usr/bin/make
make[5]: Leaving directory 
`/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_gcc6/gcc6/work/build/x86_64-apple-darwin10/libstdc++-v3'
make[4]: Leaving directory 
`/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_gcc6/gcc6/work/build/x86_64-apple-darwin10/libstdc++-v3'
make[3]: Leaving directory 
`/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_gcc6/gcc6/work/build/x86_64-apple-darwin10/libstdc++-v3'
make[2]: Leaving directory 
`/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_gcc6/gcc6/work/build'
/usr/bin/make "DESTDIR=" "RPATH_ENVVAR=DYLD_LIBRARY_PATH" 
"TARGET_SUBDIR=x86_64-apple-darwin10" "bindir=/opt/local/bin" 
"datadir=/opt/local/share/gcc-6" "exec_prefix=/opt/local" 
"includedir=/opt/local/include/gcc6" 
"datarootdir=/opt/local/share/gcc-6" 
"docdir=/opt/local/share/gcc-6/doc/" 
"infodir=/opt/local/share/info" 
"pdfdir=/opt/local/share/gcc-6/doc/" 
"htmldir=/opt/local/share/gcc-6/doc/" 
"libdir=/opt/local/lib/gcc6" "libexecdir=/opt/local/libexec" 
"lispdir=" "localstatedir=/opt/local/var" 
"mandir=/opt/local/share/man" "oldincludedir=/usr/include" 
"prefix=/opt/local" "sbindir=/opt/local/sbin" 
"sharedstatedir=/opt/local/com" "sysconfdir=/opt/local/etc" 
"tooldir=/opt/local/x86_64-apple-darwin10" 
"build_tooldir=/opt/local/x86_64-apple-darwin10" 
"target_alias=x86_64-apple-darwin10
 4; "AWK=awk" "BISON=bison" "CC_FOR_BUILD=/usr/bin/gcc-4.2 
-arch x86_64" "CFLAGS_FOR_BUILD=-pipe -Os" 
"CXX_FOR_BUILD=/usr/bin/g++-4.2 -arch x86_64 -std=gnu++98" 
"EXPECT=expect" "FLEX=flex" "INSTALL=/usr/bin/install 
-c" "INSTALL_DATA=/usr/bin/install -c -m 644" 
"INSTALL_PROGRAM=/usr/bin/install -c

Re: gcc6 build failed on Snow Leopard

[Ken Cunningham]

>> 
>> on the other, the checksum differs and it says comparison successful.


I'm a bit curious why the comparison is successful and the build proceeds when 
the checksum differs like that ...  I'm actually not sure which build attempt 
is the more valid. Perhaps it is supposed to fail, and the error is in the 
build that proceeds?

I assume there are some compiler tests that I could/should run on  gcc6 on SL ? 

the gcc website  suggests this:

make bootstrap
make -k check

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

Re: webkit-gtk2: Will it ever be fixed?

[Ken Cunningham]

Thanks for posting your worries instead of just giving up.

I will leap here to assume you actually do want help to get this to work, and 
you're not just venting frustration.

You have to realize that with the kind of information you've volunteered so 
far, no-one on Earth is likely to be able to help you.

Please consider first of all searching for an existing ticket that explains 
your issue in the Macports tickets (https://trac.macports.org/wiki/Tickets). 
There likely is one.

If there is not a ticket that represents your issue, then open a ticket 
yourself. Be accurate about the name of the port. Upload the build log, 
mentioned in every error report. Let us have a look.

If you were to do those things, there is a very reasonable chance one of the 
dozens of kind-hearted souls who hang out around here will help you solve the 
issue, whatever it might be!

Best,

Ken





On 2016-10-17, at 5:19 PM, Bachsau wrote:

> Am 18.10.2016 um 01:19 schrieb Lawrence Velázquez:
>> Are you talking about webkit-gtk-2.0?
> 
> I think so. Whats the alternative?
> 
>> That port is not supported on recent systems, and it errors out with a 
> message saying so.
> 
> No, it fails with "command execution failed"...
> ___
> macports-users mailing list
> macports-users@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-users

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

Re: Libc++ on Snow Leopard

[Ken Cunningham]

Jasper, I've been using this for months now, and I think I've worked through 
most of the hiccups, often with Jeremy's help.

If you get stuck or have any questions or issues, please don't hesitate to ask, 
either on the list here if you want, or offline to me directly if you prefer to 
conceal your questions from the public.

What I really should do sometime is post up the built binaries I have made, 
which would reduce the time it takes to do this from days to minutes. Building 
compilers is a very time-consuming process...

Ken






On 2016-10-27, at 12:18 PM, Jasper van der Schors wrote:

>  Hi i've got a problem with the libc++.
> 
> I want to follow the guide: 
> ​https://trac.macports.org/wiki/LibcxxOnOlderSystems but i can't succeed step 
> 3 under Bootstrapping 3.
> 
> I can't find the following names:
> 
> cxx_stdlib libc++ 
> 
> delete_la_files yes 
> 
> default_compilers macports-clang-3.4 macports-clang-3.3 gcc-4.2 apple-gcc-4.2 
> gcc-4.0
> 
> 
> 
> Is there someone who can tell me what i am doing wrong? Is there a forum 
> where i can find a answer?
> 
> 
> Regards,
> Jasper
> ___
> macports-users mailing list
> macports-users@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-users

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

Re: 10.6.8 and ffmpeg

[Ken Cunningham]

libsdl2 will build without trouble on 10.6.8 if you find a copy of the 10.7 SDK 
and put it like so in /Developer/SDKs/MacOSX10.7.sdk

Ken


On 2016-10-28, at 9:58 PM, Richard L. Hamilton wrote:

> Am I right in thinking that  ffmpeg now requires libsdl2 while it previously 
> required libsdl?  That causes ffmpeg to fail on 10.6.x, because libsdl2 fails:
> 
> Error: org.macports.fetch for port libsdl2 returned: Building libsdl2 
> requires OS X 10.7 SDK or later
> Error: Failed to install libsdl2
> Please see the log file for port libsdl2 for details:
>
> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_libsdl2/libsdl2/main.log
> Error: The following dependencies were not installed: libsdl2
> Error: Unable to upgrade port: 1
> To report a bug, follow the instructions in the guide:
>http://guide.macports.org/#project.tickets
> 
> ___
> macports-users mailing list
> macports-users@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-users

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

Re: 10.6.8 and ffmpeg

[Ken Cunningham]

I know -- I'm sorry for stepping out there and just blurting it like that. I'm 
just trying to help Richard 'get it done'.

Also - I upgraded libsdl to the new 2.0.5 version here -- perhaps i should put 
up a diff for JMR to use?

Best,

Ken


$ port -v installed | grep ffmpeg
  ffmpeg @3.1.4_0+gpl2+x11 platform='darwin 10' archs='x86_64'
  ffmpeg @3.1.5_0+gpl2+x11 (active) platform='darwin 10' archs='x86_64'


$ port -v installed | grep libsdl
  libsdl @1.2.15_3+universal+x11 (active) platform='darwin 10' archs='i386 
x86_64'
  libsdl2 @2.0.4_0+universal platform='darwin 10' archs='i386 x86_64'
  libsdl2 @2.0.5_0 platform='darwin 10' archs='x86_64'
  libsdl2 @2.0.5_0+universal (active) platform='darwin 10' archs='i386 x86_64'
  libsdl2_image @2.0.1_0+universal (active) platform='darwin 10' archs='i386 
x86_64'
  libsdl2_mixer @2.0.1_0 (active) platform='darwin 10' archs='x86_64'
  libsdl2_net @2.0.1_0+universal (active) platform='darwin 10' archs='i386 
x86_64'
  libsdl2_ttf @2.0.14_0 (active) platform='darwin 10' archs='x86_64'
  libsdl_gfx @2.0.24_1 (active) platform='darwin 10' archs='x86_64'
  libsdl_image @1.2.12_5 (active) platform='darwin 10' archs='x86_64'
  libsdl_mixer @1.2.12_0 (active) platform='darwin 10' archs='x86_64'
  libsdl_net @1.2.8_0 (active) platform='darwin 10' archs='x86_64'
  libsdl_ttf @2.0.11_0 (active) platform='darwin 10' archs='x86_64'




On 2016-10-29, at 7:17 AM, Ryan Schmidt wrote:

> 
>> On Oct 29, 2016, at 12:05 AM, Ken Cunningham 
>>  wrote:
>> 
>> libsdl2 will build without trouble on 10.6.8 if you find a copy of the 10.7 
>> SDK and put it like so in /Developer/SDKs/MacOSX10.7.sdk
> 
> That is not a procedure we have ever recommended users do before. I know that 
> using the 10.12 SDK on 10.11 will work. If using the 10.7 SDK on 10.6 will 
> work, and we want to help users do that, maybe we should have a documented 
> way for the user to do that. And maybe we should install the 10.7 SDK on the 
> 10.6 buildbot machines so that these ports can be built automatically.
> 

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

Re: 10.6.8 and ffmpeg

[Ken Cunningham]

Hi Richard

You have a lot of Xcode versions installed! Keeping them all straight must be a 
bit of a mind-bender.
perhaps select the most modern one (Xcode 4.2) and put the macOSX10.7.sdk in 
there?

> ld: library not found for -lcrt1.10.6.o
that's a bit weird. that's a basic library.



In the 'full disclosure' category, my day-to-day 10.6.8 setup is as follows:

Xcode 4.2 is installed in /Developer and usually selected unless I'm testing 
something for Xcode 3.2.6, which I have installed in /Xcode3 but usually not 
selected
MacOSX10.7.sdk added to  /Developer/SDKs/MacOSX10.7.sdk (only used by libsdl2 
that I know of)
LibcxxOnOlderSystems installed
default compiler set to macports-clang-3.7 (as per the libcxx instructions)


Best,

Ken





On 2016-10-29, at 7:02 AM, Richard L. Hamilton wrote:

> Thanks - closer, but must be more to it than that:
> 
> h-3.2# ls -ld /Dev*
> lrwxr-xr-x   1 root  admin   16 Aug 23 20:42 /Developer -> /Developer-3.2.6
> drwxrwxr-x@ 20 root  admin  680 Nov 16  2010 /Developer-3.2.2
> drwxrwxr-x@ 16 root  admin  544 Aug 23 19:50 /Developer-3.2.6
> drwxrwxr-x  14 root  admin  476 Jun  4  2011 /Developer-4.0.2
> drwxrwxr-x  14 root  admin  476 Mar 26  2015 /Developer-4.2
> 
> sh-3.2# ls /Developer?*/SDKs
> /Developer-3.2.2/SDKs:
> MacOSX10.4u.sdk   MacOSX10.5.sdk  MacOSX10.6.sdk
> 
> /Developer-3.2.6/SDKs:
> MacOSX10.5.sdkMacOSX10.6.sdk  MacOSX10.7.sdk
> 
> /Developer-4.0.2/SDKs:
> MacOSX10.6.sdk
> 
> /Developer-4.2/SDKs:
> MacOSX10.6.sdk
> 
> sh-3.2# xcode-select --print-path
> /Developer-3.2.6
> 
> 
> --->  Configuring libsdl2
> Error: Failed to configure libsdl2, consult 
> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_libsdl2/libsdl2/work/SDL2-2.0.5/config.log
> 
> 
> Lines of likely interest from config.log:
> 
> configure:2919: checking for gcc
> configure:2946: result: /usr/bin/gcc-4.2
> configure:3175: checking for C compiler version
> configure:3184: /usr/bin/gcc-4.2 --version >&5
> i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3)
> Copyright (C) 2007 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> configure:3195: $? = 0
> configure:3184: /usr/bin/gcc-4.2 -v >&5
> Using built-in specs.
> Target: i686-apple-darwin10
> Configured with: /var/tmp/gcc/gcc-5666.3~6/src/configure --disable-checking 
> --enable-werror --prefix=/usr --mandir=/share/man 
> --enable-languages=c,objc,c++,obj-c++ 
> --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib 
> --build=i686-apple-darwin10 --program-prefix=i686-apple-darwin10- 
> --host=x86_64-apple-darwin10 --target=i686-apple-darwin10 
> --with-gxx-include-dir=/include/c++/4.2.1
> Thread model: posix
> gcc version 4.2.1 (Apple Inc. build 5666) (dot 3)
> configure:3195: $? = 0
> configure:3184: /usr/bin/gcc-4.2 -V >&5
> gcc-4.2: argument to `-V' is missing
> configure:3195: $? = 1
> configure:3184: /usr/bin/gcc-4.2 -qversion >&5
> i686-apple-darwin10-gcc-4.2.1: no input files
> configure:3195: $? = 1
> configure:3215: checking whether the C compiler works
> configure:3237: /usr/bin/gcc-4.2 -pipe -Os 
> -isysroot/Developer-3.2.6/SDKs/MacOSX10.7.sdk -arch x86_64 -arch i386 
> -I/opt/local/include -isysroot/Developer-3.2.6/SDKs/MacOSX10.7.sdk 
> -L/opt/local/lib -Wl,-headerpad_max_install_names 
> -Wl,-syslibroot,/Developer-3.2.6/SDKs/MacOSX10.7.sdk -arch x86_64 -arch i386 
> conftest.c  >&5
> ld: library not found for -lcrt1.10.6.o
> collect2: ld returned 1 exit status
> ld: library not found for -lcrt1.10.6.o
> collect2: ld returned 1 exit status
> fatal error: lipo: can't open input file: 
> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_libsdl2/libsdl2/work/.tmp/ccWPQ19t.out
>  (No such file or directory)
> configure:3241: $? = 1
> configure:3279: result: no
> configure: failed program was:
> | /* confdefs.h */
> | #define PACKAGE_NAME ""
> | #define PACKAGE_TARNAME ""
> | #define PACKAGE_VERSION ""
> | #define PACKAGE_STRING ""
> | #define PACKAGE_BUGREPORT ""
> | #define PACKAGE_URL ""
> | /* end confdefs.h.  */
> | 
> | int
> | main ()
> | {
> | 
> |   ;
> |   return 0;
> | }
> configure:3284: error: in 
> `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_libsdl2/libsdl2/work/SDL2-2.0.5':
> configure:3286: error: C

Re: 10.6.8 and ffmpeg

[Ken Cunningham]

> 
> If sdl2 can be built on Snow Leopard using a copy of the 10.7 SDK obtained 
> from a later Xcode, and that sdl2 then works ok on Snow Leopard, then I'd be 
> happy if we could come up with an official way to support that, and then we 
> could do that on the buildbot, which would cover a lot of users' needs.

As you wish. 

Personally I agree with you, but then I don’t field the tickets that might 
follow...

I can attest to the fact it builds and works well enough on the configuration I 
mentioned. The macpro I use it on has a pretty good video card for the day. 
Once it’s built, there is no further need for the 10.7 sdk, so someone getting 
it from a buildbot would not need to know any of this unless they wanted to 
rebuild it from source (libc++ , basically).

I’d be happy to test the minimum requirements to build it, if Richard doesn’t 
beat me to it :>

Get back to you in a day or two with the info.

Ken


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

Re: 10.6.8 and ffmpeg

[Ken Cunningham]

>  I can do that on the buildbot machines, and we can write the libsdl2 
> portfile so that it uses that SDK if available and instructs the user how to 
> download and install it if it's not yet there.


The portfile is already written like that.

Also, see:





Ken

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

Re: 10.6.8 and ffmpeg

[Ken Cunningham]

> 
> Agreed, the problem here is with libsdl2.  We need to understand what the 
> problem is on
> 10.6 at least and either help upstream to fix it or fix it ourselves. 


Dave,

I may not be seeing the entire picture (often happens!), but I don’t think 
there is actually a problem on 10.6. It uses the more recent SDKs mostly for 
the iPhone IOS stuff, I think, and maybe for a few other features.

It’s just written in that Availability.h Apple-sanctioned way that enables 
certain features on higher OS versions, but works on lower OS versions as well. 


For example, in MacOSX 10.7 there is a show and hide menu bar feature that is 
enabled if you are on 10.7, but worked around on 10.6.

#if (MAC_OS_X_VERSION_MIN_REQUIRED < 1070) && !defined(__LP64__)
if (show) {
ShowMenuBar();
} else {
HideMenuBar();
}
#endif


one thing — in the code of libsdl 2.05 it has this:

#if MAC_OS_X_VERSION_MIN_REQUIRED < 1060
# error SDL for Mac OS X only supports deploying on 10.6 and above.


so I think 10.5 is out of luck. libSDL 2.02 or 2.03 was still OK on 10.5 I 
think. I couldn’t get 2.04 to work, and gave up trying as life is too short.



Ken



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

Re: 10.6.8 and ffmpeg

[Ken Cunningham]

Oh — I see that there’s a lot of build info in

docs/ README-macosx.md

in there it says you need minimum Xcode 4.6 and the 10.7 SDK (maybe that’s why 
macports-clang-3.7 worked for me?)

and a lot more info that I didn’t read fully through.

Ken








> On Oct 30, 2016, at 2:28 PM, Ken Cunningham  
> wrote:
> 
>> 
>> Agreed, the problem here is with libsdl2.  We need to understand what the 
>> problem is on
>> 10.6 at least and either help upstream to fix it or fix it ourselves. 
> 
> 
> Dave,
> 
> I may not be seeing the entire picture (often happens!), but I don’t think 
> there is actually a problem on 10.6. It uses the more recent SDKs mostly for 
> the iPhone IOS stuff, I think, and maybe for a few other features.
> 
> It’s just written in that Availability.h Apple-sanctioned way that enables 
> certain features on higher OS versions, but works on lower OS versions as 
> well. 
> 
> 
> For example, in MacOSX 10.7 there is a show and hide menu bar feature that is 
> enabled if you are on 10.7, but worked around on 10.6.
> 
> #if (MAC_OS_X_VERSION_MIN_REQUIRED < 1070) && !defined(__LP64__)
> if (show) {
> ShowMenuBar();
> } else {
> HideMenuBar();
> }
> #endif
> 
> 
> one thing — in the code of libsdl 2.05 it has this:
> 
> #if MAC_OS_X_VERSION_MIN_REQUIRED < 1060
> # error SDL for Mac OS X only supports deploying on 10.6 and above.
> 
> 
> so I think 10.5 is out of luck. libSDL 2.02 or 2.03 was still OK on 10.5 I 
> think. I couldn’t get 2.04 to work, and gave up trying as life is too short.
> 
> 
> 
> Ken
> 
> 
> 

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

Re: 10.6.8 and ffmpeg

[Ken Cunningham]

On 2016-10-31, at 2:28 AM, René J. V. Bertin wrote:
> 
> Probably an open door, possibly a forbidden one: it may be relevant here to 
> block concerned ports at the latest supported version for legacy platforms? 

Although I think not needed for libsdl2 (which builds and works without issue 
on 10.6.8), this idea is a good one, needed, and in fact was about the first 
post I ever made on macports.

(trac is down again, or I'd reference the post from about June).

A collection of ports pegged to the 'last working' version is absolutely needed 
to make macports work on 10.4, 10.5, and 10.6. 

One Raimue explained how to do this, I set this up for my own use a while back, 
and shared it on github for others to use:

https://github.com/ken-cunningham-webuse/TigerPorts
https://github.com/ken-cunningham-webuse/LeopardPorts
https://github.com/ken-cunningham-webuse/SnowLeopardPorts

These are three shadow repos for such 'last known working' ports for these 
systems (and also a few fixes to allow some ports to work on these os versions 
that were never accepted into svn for one reason or another).



Ken



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

Re: 10.6.8 and ffmpeg

[Ken Cunningham]

> 
> I’d be happy to test the minimum requirements to build it, if Richard doesn’t 
> beat me to it :>
> 
> Get back to you in a day or two with the info.
> 

Hello friends,

ran some tests with a spanking new installation of 10.6.8 and macports 2.3.4 
with nothing installed


to build libsdl2 on 10.6.8 requires

MacOS10.7.sdk in ${developer_dir}/SDKs/MacOSX10.7.sdk

and 

PortGroup compiler_blacklist_versions 1.0
compiler.blacklist *gcc* { clang < 211 }


I have no clue how to submit a portfile *.diff any longer (is that a sigh of 
relief I hear?? :> ) , but hopefully this helps.


Best,

Ken



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

Re: 10.6.8 and ffmpeg

[Ken Cunningham]

OK! Just submitted my first git pull — please be gentle — I think I did it 
correctly, but ….

Ken




> On Oct 31, 2016, at 8:56 PM, Ryan Schmidt  wrote:
> 
> On Oct 31, 2016, at 22:44, Ken Cunningham  
> wrote:
>> 
>> I have no clue how to submit a portfile *.diff any longer (is that a sigh of 
>> relief I hear?? :> ) , but hopefully this helps.
> 
> Thanks! The new way is to submit a pull request on GitHub, but I think we can 
> also still accept patch files attaches to a Trac ticket. 

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

Re: 10.6.8 and ffmpeg

[Ken Cunningham]

On 2016-11-02, at 2:03 AM, Jeremy Huddleston Sequoia wrote:

> Do you know *why* it is requiring the 10.7 SDK to build?  Why can't libsdl2 
> use the 10.6 SDK effectively?
> 

I took a quick look at the code. It has a lot of AVAILABILITY_ macros in it, a 
few mentioning 10.7, most of them mentioning IOS / IPHONE things.

I assume that some of those macros don't work right with the 10.6 SDK, but the 
details of exactly which ones I didn't look into.

It seems like a lot of work (too much!) to try to fix that code, and the next 
version of libsdl2 would just break it all anyway.

The 10.7 SDK shouldn't be hard to find for anyone motivated to do so, and once 
it's on the buildbot (and we get that libc++ buildbot naming issue organized) 
that would make it sorta moot, I would think?


Thanks,

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

Re: stuck in loop with restore_ports.tcl migrating to macOS Sierra (10.12.1)

[Ken Cunningham]

here’s what I do when stuff like this happens

check your path `printenv` and see if it’s set correctly

cat ~/.profile

try “which clang” and “clang —version” 

try writing up a very simple “hello.c” source file and see if it compiles (with 
the -v option to see what happens) and whether the executable runs

install some really really simple ports, like symlinks

…
at least make sure the basics work
…
if all that works correctly, then … gotta dig deeper

Ken




> On Nov 2, 2016, at 6:20 PM, Murray Eisenberg  
> wrote:
> 
> I did install both Xcode 8.1 and the corresponding Xcode 8.1 tools for 
> Sierra.  (not sure how to verify the version of command-line tools there.)
> 
> [~”]$  xcode-select --install
> xcode-select: error: command line tools are already installed, use "Software 
> Update" to install updates
> [murray@Blackstone:~]$ xcode-select -p
> /Applications/Xcode.app/Contents/Developer
> 
> 
>> On Nov 2, 2016, at 9:11 PM, Brandon Allbery > > wrote:
>> 
>> 
>> On Wed, Nov 2, 2016 at 9:08 PM, Murray Eisenberg > > wrote:
>> So I started doing a reinstall of ports for migration, and at first got a 
>> “no C compiler available”
>> 
>> Sounds like missing command line tools to me.
>> 
>> 
>> -- 
>> brandon s allbery kf8nh   sine nomine associates
>> allber...@gmail.com  
>>  ballb...@sinenomine.net 
>> unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net 
>> 
> ---
> Murray Eisenberg  murrayeisenb...@gmail.com 
> 
> 503 King Farm Blvd #101   Home (240)-246-7240
> Rockville, MD 20850-6667  Mobile (413)-427-5334
> 
> 
> ___
> macports-users mailing list
> macports-users@lists.macosforge.org 
> 
> https://lists.macosforge.org/mailman/listinfo/macports-users 
> 
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: 10.6.8 and ffmpeg

[Ken Cunningham]

> That's just:
> 
> #if MAC_OS_X_VERSION_MAX_ALLOWED < 1070
> # error SDL for Mac OS X must be built with a 10.7 SDK or above.
> #endif /* MAC_OS_X_VERSION_MAX_ALLOWED < 1070 */
> 

that’s what I meant when I referred to using availability macros - sorry if it 
was the wrong term.

Mojca did an extensive dissection of the process in the trac ticket, trying a 
number of such things

https://trac.macports.org/ticket/52210 

I haven’t dug into it like she has …


Can I just distribute a 10.7SDK from a weblink? I suppose I'd get a call from 
Apple Legal if I did that ..?



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

Re: 10.6.8 and ffmpeg

[Ken Cunningham]

> 
> Why would you do that? It can be downloaded from the Apple developer web site 
> (in a newer version of Xcode).

Well, everyone seems to feel it’s way to difficult to expect a user to do that, 
so I’m trying to help you come up with an easier way.

Of course, I just downloaded the darned thing myself, and I don’t see why that 
is too much to expect everyone else to do… but I don’t have 14 years of 
fielding tickets to put me off, I guess :>

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

Re: stuck in loop with restore_ports.tcl migrating to macOS Sierra (10.12.1)

[Ken Cunningham]

Murray, I note the error in your log looks somewhat like this error in trac:



__SWIFT_UNAVAILABLE_MSG
…

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

Re: stuck in loop with restore_ports.tcl migrating to macOS Sierra (10.12.1)

[Ken Cunningham]

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/pthread.h:423:25:
 error: expected parameter declarator
So I'd open that file and look at line 423 and see if you can figure out what 
is happening.

If this is only you, then it’s something local on your system — who knows what 
- bad file, etc, etc.

take a look at it with 

ls -la (that long filename).

is it a simlink? Is it messed up?

find another copy on your computer maybe

locate pthread.h

and compare them

—
ultimately - reinstall it if nothing else works.

something is up…


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

Re: stuck in loop with restore_ports.tcl migrating to macOS Sierra (10.12.1)

[Ken Cunningham]

hmmm, So do I

lrwxr-xr-x  1 root  wheel  17 31 Oct 09:43 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/pthread.h
 -> pthread/pthread.h


feels like we’re finding a bug, maybe.

Where is that symlink pointing, I wonder?

K



> On Nov 2, 2016, at 8:38 PM, Murray Eisenberg  
> wrote:
> 
> I do have a symlink there:
> 
> [~]$ ls -la 
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/pthread.h
> lrwxr-xr-x  1 root  wheel  17 Oct 28 15:04 
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/pthread.h
>  -> pthread/pthread.h
> 
> [~]$ mdfind -name pthread.h
> /usr/include/pthread/pthread.h
> /Applications/MAMP/Library/include/my_pthread.h
> /Applications/Server/mampstack/mysql/include/my_pthread.h
> /Application Docs/Server/drupal-7.39-0/mysql/include/my_pthread.h
> 
> Note no change since El Capitan in the 2nd through 4th items there.
> 
> [:~]$ ls -la /usr/include/pthread/pthread.h
> -rw-r--r--  1 root  wheel  19414 Sep 19 17:53 /usr/include/pthread/pthread.h
> 
>> On Nov 2, 2016, at 11:26 PM, Ken Cunningham > <mailto:ken.cunningham.web...@gmail.com>> wrote:
>> 
>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/pthread.h:423:25:
>>  error: expected parameter declarator
>> So I'd open that file and look at line 423 and see if you can figure out 
>> what is happening.
>> 
>> If this is only you, then it’s something local on your system — who knows 
>> what - bad file, etc, etc.
>> 
>> take a look at it with 
>> 
>> ls -la (that long filename).
>> 
>> is it a simlink? Is it messed up?
>> 
>> find another copy on your computer maybe
>> 
>> locate pthread.h
>> 
>> and compare them
>> 
>> —
>> ultimately - reinstall it if nothing else works.
>> 
>> something is up…
>> 
>> 
>> Ken
> 
> ---
> Murray Eisenberg  murrayeisenb...@gmail.com 
> <mailto:murrayeisenb...@gmail.com>
> 503 King Farm Blvd #101   Home (240)-246-7240
> Rockville, MD 20850-6667  Mobile (413)-427-5334
> 
> 

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

Re: stuck in loop with restore_ports.tcl migrating to macOS Sierra (10.12.1)

[Ken Cunningham]

no, it just points into a pthread folder.

let me try building (from source) a port that triggers your err.



> On Nov 2, 2016, at 8:40 PM, Ken Cunningham  
> wrote:
> 
> hmmm, So do I
> 
> lrwxr-xr-x  1 root  wheel  17 31 Oct 09:43 
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/pthread.h
>  -> pthread/pthread.h
> 
> 
> feels like we’re finding a bug, maybe.
> 
> Where is that symlink pointing, I wonder?
> 
> K
> 
> 
> 
>> On Nov 2, 2016, at 8:38 PM, Murray Eisenberg > <mailto:murrayeisenb...@gmail.com>> wrote:
>> 
>> I do have a symlink there:
>> 
>> [~]$ ls -la 
>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/pthread.h
>> lrwxr-xr-x  1 root  wheel  17 Oct 28 15:04 
>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/pthread.h
>>  -> pthread/pthread.h
>> 
>> [~]$ mdfind -name pthread.h
>> /usr/include/pthread/pthread.h
>> /Applications/MAMP/Library/include/my_pthread.h
>> /Applications/Server/mampstack/mysql/include/my_pthread.h
>> /Application Docs/Server/drupal-7.39-0/mysql/include/my_pthread.h
>> 
>> Note no change since El Capitan in the 2nd through 4th items there.
>> 
>> [:~]$ ls -la /usr/include/pthread/pthread.h
>> -rw-r--r--  1 root  wheel  19414 Sep 19 17:53 /usr/include/pthread/pthread.h
>> 
>>> On Nov 2, 2016, at 11:26 PM, Ken Cunningham 
>>> mailto:ken.cunningham.web...@gmail.com>> 
>>> wrote:
>>> 
>>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/pthread.h:423:25:
>>>  error: expected parameter declarator
>>> So I'd open that file and look at line 423 and see if you can figure out 
>>> what is happening.
>>> 
>>> If this is only you, then it’s something local on your system — who knows 
>>> what - bad file, etc, etc.
>>> 
>>> take a look at it with 
>>> 
>>> ls -la (that long filename).
>>> 
>>> is it a simlink? Is it messed up?
>>> 
>>> find another copy on your computer maybe
>>> 
>>> locate pthread.h
>>> 
>>> and compare them
>>> 
>>> —
>>> ultimately - reinstall it if nothing else works.
>>> 
>>> something is up…
>>> 
>>> 
>>> Ken
>> 
>> ---
>> Murray Eisenberg murrayeisenb...@gmail.com 
>> <mailto:murrayeisenb...@gmail.com>
>> 503 King Farm Blvd #101  Home (240)-246-7240
>> Rockville, MD 20850-6667 Mobile (413)-427-5334
>> 
>> 
> 

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

Re: 10.6.8 and ffmpeg

[Ken Cunningham]

Wouldn’t it just be a treat if Jeremy fixed libsdl2’s code and this all went 
away :>

Ken




> On Nov 2, 2016, at 8:49 PM, Al Varnell  wrote:
> 
> On Nov 2, 2016, at 8:43 PM, Ryan Schmidt wrote:
>> On Nov 2, 2016, at 10:41 PM, Al Varnell wrote:
>>> On Nov 2, 2016, at 8:38 PM, Brandon Allbery wrote:
 On Wed, Nov 2, 2016 at 11:37 PM, Al Varnell wrote:
 Most users don't have access to Apple's developer download site and cannot 
 be expected to pay $99 to be able to do so.
 
 Um? $99 is only if you want signing certificates. The Mac Developer 
 subscription granting access to downloads is free.
>>> 
>>> Last time I checked Apple had done away with all new free subscriptions. 
>>> Have they reinstated them?
>> 
>> This is the first I'm hearing about that. Can you provide further 
>> information? Citation?
> 
> When I first heard about it, over a year ago, I tried to sign my wife up and 
> the only thing offered for free was Safari Extension developement and that 
> free program was dropped at the same time as they reorganized the entire 
> Development program a few months back.
> 
> -Al-

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

Re: stuck in loop with restore_ports.tcl migrating to macOS Sierra (10.12.1)

[Ken Cunningham]

Murray, that is very specific now

I have that port installed.

$ port -v installed gmp
The following ports are currently installed:
  gmp @6.1.1_0 (active) platform='darwin 16' archs='x86_64'

I just rebuilt it right now from source without trouble.

so it's something on your machine. Jerermy points to a possibly corrupt 
Availability.h file in the trac ticket.

So you might look at that file, or just reinstall Xcode and the command line 
tools.

(Why is this not coming to you as a prebuilt binary from the buldbots, I 
wonder?)


Best,

Ken




On 2016-11-03, at 7:01 AM, Murray Eisenberg wrote:

> After the re-install script (from the migration instructions) got into an 
> infinite loop, I started to reinstall ports manually, starting with the first 
> one on my “myports.txt” list: analitza 
> 
> The failure came when installing that failed during the automatic 
> installation of dependencies, in that case gmp.
> 
> Today, looking at the dependencies for gmp, I see that all build and library 
> dependencies for that are already installed _except_ kdelibs.
> 
> So I tried reinstalling kdelibs, and that in turn choked at trying to install 
> its dependency gmp.
> 
> So everything pretty much comes down to failure to configure gmp. 
> 
> Configuring gmp (specifically, @6.1.1_0) fails with what appears in main.log 
> as:
> 
> :info:configure configure: error: C++ compiler not available, see 
> config.log for details
> 
> In turn, config.log reports:
> 
> /usr/include/pthread.h:423:1: error: C++ requires a type specifier for 
> all declarations
>   __SWIFT_UNAVAILABLE_MSG("Use lazily initialized globals instead”)
> 
> And that seems to reduce to the issue of the problem with 
> /usr/include/pthread.h, namely:
> 
> /usr/include/pthread.h:423:1: error: C++ requires a type specifier for 
> all declarations
>__SWIFT_UNAVAILABLE_MSG("Use lazily initialized globals instead")
>^
>/usr/include/pthread.h:423:66: error: expected ';' after top level 
> declarator
>__SWIFT_UNAVAILABLE_MSG("Use lazily initialized globals instead")
> ^
>2 errors generated.
>configure:10556: $? = 1
>failed program was:
>    /* This test rejects g++ 2.7.2 which doesn't have , only a
>pre-standard iostream.h. */
>#include 
> 
> I just was about to try to do that  
>> On Nov 2, 2016, at 11:46 PM, Ken Cunningham 
>>  wrote:
>> 
>> can you remind me the name of a port that triggers the error so I can test 
>> it (hopefully not clang-3.8 which would take all night to build ) ;>
>> 
>> K
> 
> ---
> Murray Eisenberg  murrayeisenb...@gmail.com
> 503 King Farm Blvd #101   Home (240)-246-7240
> Rockville, MD 20850-6667  Mobile (413)-427-5334
> 
> 

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

Re: stuck in loop with restore_ports.tcl migrating to macOS Sierra (10.12.1)

[Ken Cunningham]

Look at this ticket <https://trac.macports.org/ticket/52776> comment 3

pthreads is not picking up the definition from Availability.h for some reason.

Ken


On 2016-11-03, at 7:26 AM, Murray Eisenberg wrote:

> I looked at the tickets #46589, 51971, and 52326 about gmp, and I don’t see 
> mention of availability.h there.  
> 
> I thought the issue with availability.h concerned gcc48 and was resolved 
> somehow (with newer Xcode? with patched port?) some time ago.
> 
> The logs seem to indicate that the current issue with gmp involves pthread.h.
> 
> 
>> On Nov 3, 2016, at 10:10 AM, Ken Cunningham 
>>  wrote:
>> 
>> Murray, that is very specific now
>> 
>> I have that port installed.
>> 
>> $ port -v installed gmp
>> The following ports are currently installed:
>> gmp @6.1.1_0 (active) platform='darwin 16' archs='x86_64'
>> 
>> I just rebuilt it right now from source without trouble.
>> 
>> so it's something on your machine. Jerermy points to a possibly corrupt 
>> Availability.h file in the trac ticket.
>> 
>> So you might look at that file, or just reinstall Xcode and the command line 
>> tools.
>> 
>> (Why is this not coming to you as a prebuilt binary from the buldbots, I 
>> wonder?)
>> 
>> 
>> Best,
>> 
>> Ken
>> 
>> 
>> 
>> 
>> On 2016-11-03, at 7:01 AM, Murray Eisenberg wrote:
>> 
>>> After the re-install script (from the migration instructions) got into an 
>>> infinite loop, I started to reinstall ports manually, starting with the 
>>> first one on my “myports.txt” list: analitza 
>>> 
>>> The failure came when installing that failed during the automatic 
>>> installation of dependencies, in that case gmp.
>>> 
>>> Today, looking at the dependencies for gmp, I see that all build and 
>>> library dependencies for that are already installed _except_ kdelibs.
>>> 
>>> So I tried reinstalling kdelibs, and that in turn choked at trying to 
>>> install its dependency gmp.
>>> 
>>> So everything pretty much comes down to failure to configure gmp. 
>>> 
>>> Configuring gmp (specifically, @6.1.1_0) fails with what appears in 
>>> main.log as:
>>> 
>>>   :info:configure configure: error: C++ compiler not available, see 
>>> config.log for details
>>> 
>>> In turn, config.log reports:
>>> 
>>>   /usr/include/pthread.h:423:1: error: C++ requires a type specifier for 
>>> all declarations
>>> __SWIFT_UNAVAILABLE_MSG("Use lazily initialized globals instead”)
>>> 
>>> And that seems to reduce to the issue of the problem with 
>>> /usr/include/pthread.h, namely:
>>> 
>>>   /usr/include/pthread.h:423:1: error: C++ requires a type specifier for 
>>> all declarations
>>>  __SWIFT_UNAVAILABLE_MSG("Use lazily initialized globals instead")
>>>  ^
>>>  /usr/include/pthread.h:423:66: error: expected ';' after top level 
>>> declarator
>>>  __SWIFT_UNAVAILABLE_MSG("Use lazily initialized globals instead")
>>>   ^
>>>  2 errors generated.
>>>  configure:10556: $? = 1
>>>  failed program was:
>>>  /* This test rejects g++ 2.7.2 which doesn't have , only a
>>>  pre-standard iostream.h. */
>>>  #include 
>>> 
>>> I just was about to try to do that  
>>>> On Nov 2, 2016, at 11:46 PM, Ken Cunningham 
>>>>  wrote:
>>>> 
>>>> can you remind me the name of a port that triggers the error so I can test 
>>>> it (hopefully not clang-3.8 which would take all night to build ) ;>
>>>> 
>>>> K
>>> 
>>> ---
>>> Murray Eisenbergmurrayeisenb...@gmail.com
>>> 503 King Farm Blvd #101 Home (240)-246-7240
>>> Rockville, MD 20850-6667Mobile (413)-427-5334
>>> 
>>> 
>> 
> 
> ---
> Murray Eisenberg  murrayeisenb...@gmail.com
> 503 King Farm Blvd #101   Home (240)-246-7240
> Rockville, MD 20850-6667  Mobile (413)-427-5334
> 
> 

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

Re: stuck in loop with restore_ports.tcl migrating to macOS Sierra (10.12.1)

[Ken Cunningham]

Hi Murray,

Just to tell you I have not touched a thing on this Sierra install, and it 
works fine for me.


(Did you have a beta installed? Can you think of any reason why your SDK might 
not be stock?)

It takes 5 minutes to reinstall Xcode and the command line tools. That would be 
step 1 for me, but it's up to you.

Ken




On 2016-11-03, at 7:43 AM, Murray Eisenberg wrote:

> OK, and in 
> 
>   
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/Availability.h
> 
> I find at lines 341-355:
> 
> /* for use marking APIs unavailable for swift */
> #if defined(__has_feature)
>   #if __has_feature(attribute_availability_swift)
> #define __SWIFT_UNAVAILABLE   
> __OS_AVAILABILITY(swift,unavailable)
> #define __SWIFT_UNAVAILABLE_MSG(_msg) 
> __OS_AVAILABILITY_MSG(swift,unavailable,_msg)
>   #endif
> #endif
> 
> #ifndef __SWIFT_UNAVAILABLE
>   #define __SWIFT_UNAVAILABLE
> #endif
> 
> #ifndef __SWIFT_UNAVAILABLE_MSG
>   #define __SWIFT_UNAVAILABLE_MSG(_msg)
> #endif
> 
> 
> Is there once again a problem in Availability.h with 'defined(__has_feature)’ 
>  which should really be 'defined(__has_feature)’ 
> again, as discussed in ticket #48471?
> 
> If so, the workaround for that was to make a local copy of Availability.h in 
> /opt/local/include and edit it there.
> 
> 
>> On Nov 3, 2016, at 10:29 AM, Ken Cunningham 
>>  wrote:
>> 
>> Look at this ticket <https://trac.macports.org/ticket/52776> comment 3
>> 
>> pthreads is not picking up the definition from Availability.h for some 
>> reason.
>> 
>> Ken
>> 
>> 
>> On 2016-11-03, at 7:26 AM, Murray Eisenberg wrote:
>> 
>>> I looked at the tickets #46589, 51971, and 52326 about gmp, and I don’t see 
>>> mention of availability.h there.  
>>> 
>>> I thought the issue with availability.h concerned gcc48 and was resolved 
>>> somehow (with newer Xcode? with patched port?) some time ago.
>>> 
>>> The logs seem to indicate that the current issue with gmp involves 
>>> pthread.h.
>>> 
>>> 
>>>> On Nov 3, 2016, at 10:10 AM, Ken Cunningham 
>>>>  wrote:
>>>> 
>>>> Murray, that is very specific now
>>>> 
>>>> I have that port installed.
>>>> 
>>>> $ port -v installed gmp
>>>> The following ports are currently installed:
>>>> gmp @6.1.1_0 (active) platform='darwin 16' archs='x86_64'
>>>> 
>>>> I just rebuilt it right now from source without trouble.
>>>> 
>>>> so it's something on your machine. Jerermy points to a possibly corrupt 
>>>> Availability.h file in the trac ticket.
>>>> 
>>>> So you might look at that file, or just reinstall Xcode and the command 
>>>> line tools.
>>>> 
>>>> (Why is this not coming to you as a prebuilt binary from the buldbots, I 
>>>> wonder?)
>>>> 
>>>> 
>>>> Best,
>>>> 
>>>> Ken
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On 2016-11-03, at 7:01 AM, Murray Eisenberg wrote:
>>>> 
>>>>> After the re-install script (from the migration instructions) got into an 
>>>>> infinite loop, I started to reinstall ports manually, starting with the 
>>>>> first one on my “myports.txt” list: analitza 
>>>>> 
>>>>> The failure came when installing that failed during the automatic 
>>>>> installation of dependencies, in that case gmp.
>>>>> 
>>>>> Today, looking at the dependencies for gmp, I see that all build and 
>>>>> library dependencies for that are already installed _except_ kdelibs.
>>>>> 
>>>>> So I tried reinstalling kdelibs, and that in turn choked at trying to 
>>>>> install its dependency gmp.
>>>>> 
>>>>> So everything pretty much comes down to failure to configure gmp. 
>>>>> 
>>>>> Configuring gmp (specifically, @6.1.1_0) fails with what appears in 
>>>>> main.log as:
>>>>> 
>>>>>  :info:configure configure: error: C++ compiler not available, see 
>>>>> config.log for details
>>>>> 
>>>>> In turn, config.log reports:
>>>>> 
>>>>>  /usr/include/pthread.h:423:1: error: C++ requires a type specifier for 
>>>>> 

Re: stuck in loop with restore_ports.tcl migrating to macOS Sierra (10.12.1)

[Ken Cunningham]

>> 
>> If so, the workaround for that was to make a local copy of Availability.h in 
>> /opt/local/include and edit it there.
>> 

I'd still reinstall Xcode and the command line tools -- but you don't have a 
rogue Availability.h sitting  /opt/local/include do you? If so, that's your 
trouble.

K

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

Re: Do I need +universal to be used when installing ports?

[Ken Cunningham]

WINE is the only thing that comes to mind that really only runs i386 even on 
x86_64. 

And that triggers all it’s deps to be i386 as well.

K


> On Apr 28, 2017, at 8:06 AM, Barrie Stott  wrote:
> 
> I have an iMac as my only computer and am near the beginning of installing 
> ports for Sierra so it’s a good time to change from +universal way of working 
> to -universal; it should save space and installations should be quicker. Does 
> anyone know any good reasons why I should not go ahead? Are there situations 
> where x86_64 cannot be used and i386 is necessary? Once I know which way to 
> jump I can set some defaults and thereafter I suspect that installation would 
> be the same.
> 
> Barrie.
> ___
> macports-users mailing list
> macports-users@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-users

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

Re: Failure to build glib2 as part of xsane dependency

[Ken Cunningham]

On 2017-05-04, at 12:32 PM, ges...@ftp83plus.net wrote:

>> Hello there, 
>> 
>> I needed to reinstall MacPorts on Snow Leopard, and followed the 
>> instructions in LibcxxOnOlderSystems (I recall some ports wouldn't compile 
>> properly without it), including the experimental steps. Only there, I 
>> replaced clang 3.9 by clang 4.0.
>> 
>> However, it failed on completing xsane compilation, as glib2 failed:
>> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_glib2/glib2/main.log
>> 
>> is pasted there:
>> https://pastebin.com/dmNJFQKU
>> 
>> From what I could read, it can't find a given header file. How did it went 
>> missing?
> 


As mentioned privately, it seems likely you've stumbled across this bug 
 which Jeremy reported a few 
months ago.

It looks like a new regression and I don't see that error on 10.6 with 
clang-3.7, clang-3.8, or clang-3.9, so if you back up in the 
libcxxonoldersystems instructions and install clang-3.8 or clang-3.9 you should 
be OK.

I haven't tried clang-4.0 to confirm this bug / error on my system yet, but I 
could assume I'd see it too if I did.

Best,

Ken


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

Re: Failure to build glib2 as part of xsane dependency

[Ken Cunningham]

sudo port uninstall clang-4.0 llvm-4.0 should do it for you.

don't forget to change the line in macports.conf about default_compilers, 
removing clang-4.0.

BTW I appear to have fixed clang-4.0 for snow leopard, and depending on what 
Jeremy wants to do with that, it should be working in macports or upstream 
eventually.

Although I'd recommend you stick with clang-3.8 or clang-3.9 for now, clang-4.0 
for snow leopard will work soonishly. There's a word... :>

Best,

Ken



On 2017-05-09, at 10:53 AM, ges...@ftp83plus.net wrote:

> Me again. 
> 
> I forgot, but how do I uninstall the broken llvm40 version?
> On Step 7, it complains about conflict between llvm39 and llvm 40.
> 
> Thanks
> 
> El 2017-05-05, a las 19:05, Ken Cunningham escribió:
> 
>> 
>> On 2017-05-04, at 12:32 PM, ges...@ftp83plus.net wrote:
>> 
>>>> Hello there, 
>>>> 
>>>> I needed to reinstall MacPorts on Snow Leopard, and followed the 
>>>> instructions in LibcxxOnOlderSystems (I recall some ports wouldn't compile 
>>>> properly without it), including the experimental steps. Only there, I 
>>>> replaced clang 3.9 by clang 4.0.
>>>> 
>>>> However, it failed on completing xsane compilation, as glib2 failed:
>>>> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_glib2/glib2/main.log
>>>> 
>>>> is pasted there:
>>>> https://pastebin.com/dmNJFQKU
>>>> 
>>>> From what I could read, it can't find a given header file. How did it went 
>>>> missing?
>>> 
>> 
>> 
>> As mentioned privately, it seems likely you've stumbled across this bug 
>> <https://bugs.llvm.org//show_bug.cgi?id=31504> which Jeremy reported a few 
>> months ago.
>> 
>> It looks like a new regression and I don't see that error on 10.6 with 
>> clang-3.7, clang-3.8, or clang-3.9, so if you back up in the 
>> libcxxonoldersystems instructions and install clang-3.8 or clang-3.9 you 
>> should be OK.
>> 
>> I haven't tried clang-4.0 to confirm this bug / error on my system yet, but 
>> I could assume I'd see it too if I did.
>> 
>> Best,
>> 
>> Ken
>> 
>> 
> 

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

Re: Can brew and port be used on the same system?

[Ken Cunningham]

I'm about 95% finished a Portfile for OpenJK. It doesn't take but a few minutes 
to make one for a port like this. It's fully built and sitting on my hard 
drive. Just working out a patchfile or two for an openGL glitch on MacOS that 
is widely known, and I'll test it out. If it works, I'll send you the Portfile.

Portfiles for games like this usually involve a couple of "hacks" that are 
generally frowned upon in the rather pure environment of the MacPorts repo. So 
you might need to install it "rogue". We'll see.

Ken


On 2017-05-27, at 9:02 PM, Mark Anderson wrote:

> Yes, but I'd advise against it. I thought I had to for RVM and it caused me 
> loads of trouble. Then I learned I could set it to MacPorts and a deleted 
> brew and never looked back. I've been using MacPorts since before Intel, so 
> I'm attached.
> 
> —Mark
> ___
> Mark E. Anderson 
> 
> On Sat, May 27, 2017 at 10:22 PM, Al Varnell  wrote:
> I'm told it can be done now, but can get messy. I gave up on brew several 
> years ago. Too many conflicts back then.
> 
> Sent from Janet's iPad
> 
> -Al-
> --
> Al Varnell
> Mountain View, CA
> 
> On May 27, 2017, at 7:13 PM, Michael  wrote:
> > So apparently the open source code version of Jedi Knights Academy and 
> > Outcast https://github.com/JACoders/OpenJK rely on brew's SDL 2, and have 
> > that installation pathname in their binaries.
> >
> > Can I install brew, with its use of /usr/local/, at the same time as ports?
> ___
> macports-users mailing list
> macports-users@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-users
> 
> ___
> macports-users mailing list
> macports-users@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-users

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

Re: Can brew and port be used on the same system?

[Ken Cunningham]

It sounds like you got a build working already, so you probably done care about 
this anymore, but this Portfile



with it's associated patches actually does build the port.

I have not added in the deps yet. It builds just fine on my system, but I have 
hundreds of deps installed already. You might run into a missing dep.

Also, although I downloaded the game from the wayback machine



I have not yet figured out where to exactly put all the files to make 
everything work.

Perhaps you can help with that?

Thanks, 

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

Re: Can brew and port be used on the same system?

[Ken Cunningham]

> 
> Oh -- did you know that the filenames displayed in finder do not have to have 
> any correlation to the filenames as seen by the shell and other programs? Or 
> that Finder is perfectly happy to display two different "files with the same 
> name"?

In fact, I did notice that, and was rather confused by it. Maybe a fresh look 
in the morning might sort that out!

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

Re: Can brew and port be used on the same system?

[Ken Cunningham]

OK Mike,

If you care to try out a MacPorts build of OpenJK yourself, the Portfile is in 
reasonable working condition.

> 

I have not yet added in all the deps -- this builds through on my system. I 
have SDL1.2 and SDL2 installed, and lots of others. I'll figure that out on a 
VM I use for that.

You might run into a missing dependency. Let me know.

Also - I don't actually own this game, so I don't have the associated files to 
make it actually work at present.

This site  
seems to have sorted out where to put the files.

I think they can go in ~/Library/Application Support/OpenJK/base

but let me know.

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