request review #52066

[Björn Ketelaars]

Hello,

Would someone be so kind to review (and commit)
https://trac.macports.org/ticket/52066 ?

Thank you!

-- 
Björn Ketelaars
GPG key: 0x4F0E5F21
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [MacPorts] #52068: darkice needs pkgconfig dependency

[Ryan Schmidt]

> On Aug 22, 2016, at 9:20 AM, Rainer Müller  wrote:
> 
> On 2016-08-22 12:39, Niels Dettenbach wrote:
>> Hmmm,
>> i'm just wondering how the port worked up to 1.2 - there was no significant 
>> changes within darkice sources done as far as i know from Rafael Diniz 
>> (darkice maintainer) and i see no differences in the configure flag sheme 
>> too.
> 
> If you had the pkgconfig port installed, it just worked because it was
> already available. That is very likely as pkgconfig is a build
> dependency for many other ports.
> 
>> Do i have to correct here something further? In that case i have to dig in 
>> deeper asap (i.e. next weekend) into macports again.
>> 
>> depends_build-append port:pkgconfig
> 
> That would be correct.
> 
>> Could i add this in general anywhere or should place this under any of the 
>> variant sections? In practice, any mac osx user would at least need jack - 
>> and 
>> i don't know if further of the encoders need pkg-config too.
> 
> According to the configure script, the detection for all of them uses
> pkg-config.

Except lame.

> Makes sense to add it as a general dependency.

Agreed.



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

Re: port install v port mpkg | mdmg

[Ryan Schmidt]

On Aug 23, 2016, at 7:38 AM, Craig Treleaven wrote:

> On Aug 22, 2016, at 11:21 AM, Ryan Schmidt wrote:
> 
>> Craig, until base is fixed to automatically include daemondo in pkgs when 
>> needed, can't you just add a post-pkg block that copies daemondo from the 
>> location where it was installed by MacPorts base, without needing a separate 
>> MacPorts_daemondo port?
> 
> “post-pkg” …  I had no idea such a thing existed.  I thought ‘port mpkg’ was 
> a command like ‘port cat’ or ‘port echo’; not a port phase.  My handy search 
> facility (EasyFind) finds a grand total of 5 portfiles that implement such a 
> block.
> 
> But that is clearly a much better solution than what I have always described 
> as a horrific hack, MacPorts_daemondo.  I’ll try to figure out the process 
> over the next few days.  

pkg is a phase, like configure, build, destroot, it's just not one of the 
phases that runs unless you explicitly tell it to at the command line. Indeed 
there aren't many ports that augment that phase, since the defaults are enough 
to package most any port. And the only reason you want to augment it in your 
port is because of a MacPorts base bug, which is probably what we should work 
on fixing.


> On a related topic, PackageMaker.app is becoming very difficult to find on 
> Apple’s Developer Connection website.  Obviously because it was replaced by 
> pkgbuild about 6 years ago.  Is it on someone’s ToDo list to update mpkg and 
> friends to use pkgbuild instead of PackageMaker?  I’d like to help but I lack 
> a couple of key ingredients.  Knowledge of OS X packaging and confidence to 
> hack base.  Either of those could be solved in time…but that is something 
> else that is lacking for the forseeable future.  

Looks like we haven't done anything about it yet. The ticket (which I see you 
already found and Cc'd yourself on) is:

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

There's a link to a patch there, unfortunately the patch removes our existing 
Package Maker code and replaces it with pkgbuild code. We would want to keep 
the Package Maker code for older macOS versions.

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

Re: how about a 'snowleopardfixes' library port?

[Lawrence Velázquez]

> On Aug 23, 2016, at 1:13 PM, Ryan Schmidt  wrote:
> 
>> On Aug 23, 2016, at 12:00, Ken Cunningham  
>> wrote:
>> 
>> Hmmm. Making the dylib wasn't too hard:
>> 
>> clang -dynamiclib -std=gnu99 strnlen.c getline.c -current_version 1.0 
>> -compatibility_version 1.0 -o libsnowleopardfixes.a.dylib
> 
> I would prefer you work with the developers of the affected software packages 
> to get the necessary compatibility functions into their sources. This will 
> help all Snow Leopard users, not just those using MacPorts.  

+1

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

Re: how about a 'snowleopardfixes' library port?

[Ken Cunningham]

That fixed it, indeed. 

Now works as a dylib as well.

Will play with it some more before you/we/I decide what we might to do with it, 
if anything.

Best,

Ken





On 2016-08-23, at 10:42 AM, Lawrence Velázquez wrote:

>> On Aug 23, 2016, at 1:31 PM, Ken Cunningham 
>>  wrote:
>> 
>> Sorry Clemens, I see now what you mean. During the compile stage, I need to 
>> install a name.
>> 
>> Thanks for the tip. I missed that first read.
> 
> I believe `install_name_tool -id /opt/local/lib/libsnowleopardfixes.a.dylib 
> /opt/local/lib/libsnowleopardfixes.a.dylib` would have worked also.
> 
> vq

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

Re: how about a 'snowleopardfixes' library port?

[Lawrence Velázquez]

> On Aug 23, 2016, at 1:31 PM, Ken Cunningham  
> wrote:
> 
> Sorry Clemens, I see now what you mean. During the compile stage, I need to 
> install a name.
> 
> Thanks for the tip. I missed that first read.

I believe `install_name_tool -id /opt/local/lib/libsnowleopardfixes.a.dylib 
/opt/local/lib/libsnowleopardfixes.a.dylib` would have worked also.

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

Re: how about a 'snowleopardfixes' library port?

[Ken Cunningham]

Sorry Clemens, I see now what you mean. During the compile stage, I need to 
install a name.

Thanks for the tip. I missed that first read.

Best,

Ken



>> 
>> On Tue, Aug 23, 2016 at 10:00:05AM -0700, Ken Cunningham wrote:
>>> clang -dynamiclib -std=gnu99 strnlen.c getline.c -current_version 1.0 
>>> -compatibility_version 1.0 -o libsnowleopardfixes.a.dylib
>> 
>> You need -install_name ${prefix}/lib/libsnowleopardfixes.a.dylib here.
>> 
>>> configure:3663: ./conftest
>>> dyld: Library not loaded: libsnowleopardfixes.a.dylib
>>> Referenced from: 
>>> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_sysutils_lnav/lnav/work/lnav-0.8.1/./conftest
>>> Reason: image not found
>>> ./configure: line 3665: 50401 Trace/BPT trap  
>>> ./conftest$ac_cv_exeext
>>> configure:3667: $? = 133
>>> configure:3674: error: in 
>>> `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_sysutils_lnav/lnav/work/lnav-0.8.1':
>>> configure:3676: error: cannot run C++ compiled programs.
>>> If you meant to cross compile, use `--host'.
>> 
>> This check just tests whether you can run compiled programs. Because
>> your library does not have a correct install name it is not found by the
>> loader, which causes the test program to fail.
>> 
>> The configure script just happens to assume that you might be
>> cross-compiling if you cannot run the generated binaries.
>> 
>> -- 
>> Clemens
> 

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

Re: how about a 'snowleopardfixes' library port?

[Ken Cunningham]

thanks,

I thought of that, but 

sudo install_name_tool -add_rpath /opt/local/lib 
/opt/local/lib/libsnowleopardfixes.a.dylib

didn't solve the issue. Sorry I left that step out.

then I went big-gun and set the DYLIB_FALLBACK_LIBRARY_PATH

but that didn't work either.

I'll keep plugging.

As Ryan says, if the upstream would just improve their use of glib a bit and 
test for getline, then we wouldn't need to go through all this nonsense. But it 
is very very common that they don't check for getline.

Ken




On 2016-08-23, at 10:16 AM, Clemens Lang wrote:

> Hi,
> 
> On Tue, Aug 23, 2016 at 10:00:05AM -0700, Ken Cunningham wrote:
>> clang -dynamiclib -std=gnu99 strnlen.c getline.c -current_version 1.0 
>> -compatibility_version 1.0 -o libsnowleopardfixes.a.dylib
> 
> You need -install_name ${prefix}/lib/libsnowleopardfixes.a.dylib here.
> 
>> configure:3663: ./conftest
>> dyld: Library not loaded: libsnowleopardfixes.a.dylib
>>  Referenced from: 
>> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_sysutils_lnav/lnav/work/lnav-0.8.1/./conftest
>>  Reason: image not found
>> ./configure: line 3665: 50401 Trace/BPT trap  ./conftest$ac_cv_exeext
>> configure:3667: $? = 133
>> configure:3674: error: in 
>> `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_sysutils_lnav/lnav/work/lnav-0.8.1':
>> configure:3676: error: cannot run C++ compiled programs.
>> If you meant to cross compile, use `--host'.
> 
> This check just tests whether you can run compiled programs. Because
> your library does not have a correct install name it is not found by the
> loader, which causes the test program to fail.
> 
> The configure script just happens to assume that you might be
> cross-compiling if you cannot run the generated binaries.
> 
> -- 
> Clemens

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

Re: how about a 'snowleopardfixes' library port?

[Clemens Lang]

Hi,

On Tue, Aug 23, 2016 at 10:00:05AM -0700, Ken Cunningham wrote:
> clang -dynamiclib -std=gnu99 strnlen.c getline.c -current_version 1.0 
> -compatibility_version 1.0 -o libsnowleopardfixes.a.dylib

You need -install_name ${prefix}/lib/libsnowleopardfixes.a.dylib here.

> configure:3663: ./conftest
> dyld: Library not loaded: libsnowleopardfixes.a.dylib
>   Referenced from: 
> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_sysutils_lnav/lnav/work/lnav-0.8.1/./conftest
>   Reason: image not found
> ./configure: line 3665: 50401 Trace/BPT trap  ./conftest$ac_cv_exeext
> configure:3667: $? = 133
> configure:3674: error: in 
> `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_sysutils_lnav/lnav/work/lnav-0.8.1':
> configure:3676: error: cannot run C++ compiled programs.
> If you meant to cross compile, use `--host'.

This check just tests whether you can run compiled programs. Because
your library does not have a correct install name it is not found by the
loader, which causes the test program to fail.

The configure script just happens to assume that you might be
cross-compiling if you cannot run the generated binaries.

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

Re: how about a 'snowleopardfixes' library port?

[Ryan Schmidt]

On Aug 23, 2016, at 12:00, Ken Cunningham  
wrote:

>> 
>> Maybe, if you can make a dylib out of it.
> 
> 
> Hmmm. Making the dylib wasn't too hard:
> 
> clang -dynamiclib -std=gnu99 strnlen.c getline.c -current_version 1.0 
> -compatibility_version 1.0 -o libsnowleopardfixes.a.dylib
> 
> 

> dyld: Library not loaded: libsnowleopardfixes.a.dylib
>  Referenced from: 
> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_sysutils_lnav/lnav/work/lnav-0.8.1/./conftest
>  Reason: image not found

You haven't set the library's install_name to the absolute path where it is 
installed. 

I would prefer you work with the developers of the affected software packages 
to get the necessary compatibility functions into their sources. This will help 
all Snow Leopard users, not just those using MacPorts.  
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: how about a 'snowleopardfixes' library port?

[Ken Cunningham]

> 
> Maybe, if you can make a dylib out of it.
> 


Hmmm. Making the dylib wasn't too hard:

clang -dynamiclib -std=gnu99 strnlen.c getline.c -current_version 1.0 
-compatibility_version 1.0 -o libsnowleopardfixes.a.dylib

and setting it up seems equally straightforward:

sudo cp ./libsnowleopardfixes.a.dylib /opt/local/lib/libsnowleopardfixes.a.dylib
sudo ln -s /opt/local/lib/libsnowleopardfixes.a.dylib 
/opt/local/lib/libsnowleopardfixes.dylib

but something a bit odd happens during the configure phase of lnav. With the 
static library, it all went fine through to the build. But with the dyllib, all 
goes well and the dylib seems to be found (and basically ignored) until I get 
this funny error during the check when configure checks for "cross compiling"...

Open to your thoughts - perhaps configure needs libsnowleopardfixes to be a 
universal dylib to function during this phase?

Easy enough to try. I don't exactly know what configure is checking for during 
the cross-compile stage of testing

Ken



--- lnav configure.log part 
configure:3484: $? = 1
configure:3504: checking whether the C++ compiler works
configure:3526: /opt/local/bin/clang++-mp-3.7 -pipe -Os -arch x86_64 
-stdlib=libc++ -I/opt/local/include -I/opt/local/include -I/usr/local/include 
-I/usr/include -L/opt/local/lib -Wl,-headerpad_max_install_names -arch x86_64 
-stdlib=libc++ -lsnowleopardfixes.a -L/opt/local/lib -L/usr/local/lib 
-L/usr/lib conftest.cpp  >&5
configure:3530: $? = 0
configure:3578: result: yes
configure:3581: checking for C++ compiler default output file name
configure:3583: result: a.out
configure:3589: checking for suffix of executables
configure:3596: /opt/local/bin/clang++-mp-3.7 -o conftest -pipe -Os -arch 
x86_64 -stdlib=libc++ -I/opt/local/include -I/opt/local/include 
-I/usr/local/include -I/usr/include -L/opt/local/lib 
-Wl,-headerpad_max_install_names -arch x86_64 -stdlib=libc++ 
-lsnowleopardfixes.a -L/opt/local/lib -L/usr/local/lib -L/usr/lib conftest.cpp  
>&5
configure:3600: $? = 0
configure:3622: result: 
configure:3644: checking whether we are cross compiling
configure:3652: /opt/local/bin/clang++-mp-3.7 -o conftest -pipe -Os -arch 
x86_64 -stdlib=libc++ -I/opt/local/include -I/opt/local/include 
-I/usr/local/include -I/usr/include -L/opt/local/lib 
-Wl,-headerpad_max_install_names -arch x86_64 -stdlib=libc++ 
-lsnowleopardfixes.a -L/opt/local/lib -L/usr/local/lib -L/usr/lib conftest.cpp  
>&5
configure:3656: $? = 0
configure:3663: ./conftest
dyld: Library not loaded: libsnowleopardfixes.a.dylib
  Referenced from: 
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_sysutils_lnav/lnav/work/lnav-0.8.1/./conftest
  Reason: image not found
./configure: line 3665: 50401 Trace/BPT trap  ./conftest$ac_cv_exeext
configure:3667: $? = 133
configure:3674: error: in 
`/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_sysutils_lnav/lnav/work/lnav-0.8.1':
configure:3676: error: cannot run C++ compiled programs.
If you meant to cross compile, use `--host'.

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

Re: how about a 'snowleopardfixes' library port?

[Lawrence Velázquez]

> On Aug 23, 2016, at 12:50 AM, Ken Cunningham 
>  wrote:
> 
> Snow Leopard has two missing but fairly commonly used functions, getline and 
> strnlen.  These two functions are responsible for a number of snow leopard 
> build failures.
> 
> It seemed that reinventing the wheel over and over for a getline replacement 
> was getting rather tedious, port after port. I built a static library with a 
> getline replacement in it, called it 'libsnowleopardfixes.a', put it in 
> /opt/local/lib, and added it to the linked libraries on lnav. 

As a rule, we don't like static libraries because they make it difficult to 
ensure repeatable builds. Binaries that incorporate static libraries must be 
rebuilt to pick up changes, and it's hard to tell what version of a library 
went into a particular binary. Every port that uses a static library has to be 
revbumped every time that library is updated.

> This seems to be a contender for a fairly easy way to solve a lot of troubles 
> with these missing snowleopard functions...

Maybe, if you can make a dylib out of it.

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