Help with a Portfile (part 2)

[Eric F (iEFdev)]

On 1/16/19 19:22 , Ryan Schmidt wrote:
> On Jan 15, 2019, at 15:55, Eric F (iEFdev) wrote:
>> It's a 2 part install. C lib (dependency) + a module.
>>     - https://github.com/maxmind/libmaxminddb/
> I tried to build this Portfile and found that in the libtap directory, the build system is not using the compiler nor flags that MacPorts specified. This can be fixed with the usual dance:
>
> variant universal {}
> build.env-append    CC="${configure.cc}" \
>                     CFLAGS="${configure.cflags} [get_canonical_archflags cc]" \
>                     LDFLAGS="${configure.ldflags} [get_canonical_archflags ld]"
>
> Then it builds fine for me. If you're ready, I'll commit this one for you.
>
> I've made a few minor changes: Removed the name line, since github.setup sets it for you; changed the homepage to the one indicated on the GitHub project; and fixed the maintainer line: would you like to maintain the port? If so, I'll list your obfuscated email and "openmaintainer", otherwise "nomaintainer".
>
> I've attached my revised Portfile to this ticket: https://trac.macports.org/ticket/44709
Thanks Ryan! I'll look in to this right away.

I did push the Portfile to a tmp branch on my MP fork:
https://github.com/iEFdev/macports-ports/blob/maxminddb_x2/devel/libmaxminddb/Portfile
For the maintainer… The old 'libgeoip' was pixilla. I sent him an email asking
if he wanted this one as well, but haven't heard anything. I guess nomaintainer
is better, unless I should be in there. It's ok.

>>    - https://github.com/maxmind/mod_maxminddb/
> Some of the same changes apply to this Portfile, including about the name, homepage, and maintainers.
>
> Also, every other Apache module is in the primary category "www" but you've listed this in "devel". Can we change it to "www"?
Yes, that was prob a “draft issue”. In the version I pushed it is www. :)
https://github.com/iEFdev/macports-ports/blob/maxminddb_x2/www/mod_maxminddb/Portfile


>> On 1/16/19 0:35 , Ryan Schmidt wrote:
>>> Sounds like apxs doesn't like the -arch flag, so don't pass that to it. Maybe using "-Wl,-arch,x86_64" instead of "-arch x86_64" is what you need. Or maybe you don't need an -arch flag at all.
>> Been doing some trial'n'error here, but I think I've got it to work now. :)
>>
>> This: build.args LDFLAGS=-L${prefix}/lib
>> …or: build.args LDFLAGS="-L${prefix}/lib -Wl,-arch,x86_64"
>>
>> Both works, but neither one works with: -headerpad_max_install_names
>> (The original line: -L/opt/local/lib -Wl,-headerpad_max_install_names -arch x86_64)
>>
>> Anything to worry about? Isn't that one something about names on OS X (from quick web search)?
> Yes, -headerpad_max_install_names is a linker flag that adds maximum padding to install_names of Mach-O files, so that they could be changed later with install_name_tool. MacPorts adds this flag to LDFLAGS by default.
>
> The point is: Are the LDFLAGS being passed to apxs in the correct way? From the apxs manpage, the usage is:
>
>        apxs -c [ -S name=value ] [ -o dsofile ] [ -I incdir ] [ -D name=value ] [ -L libdir ] [ -l libname ] [ -Wc,compiler-flags ] [ -Wl,linker-flags ] files ...
>
> So linker flags should be passed using -Wl.
>
> MacPorts happens to already pass the "-headerpad_max_install_names" linker flag as "-Wl,-headerpad_max_install_names" because it does not know whether LDFLAGS will be passed to the linker (which would accept this flag directly) or to the compiler (which would not). But in this case, all LDFLAGS need to be passed with this prefix.
>
> This looks like a bug in the mod_maxminddb build system which should be reported to its developers. Its src/Makefile.am correctly uses the "-Wc," prefix for CFLAGS, but does not do the equivalent for LDFLAGS. Patching that allows the build to succeed for me.
>
> The destroot then fails because apxs is trying to install directly into prefix, bypassing destroot. I don't know how to fix that. If apxs can be told about DESTDIR that would be great, otherwise we could bypass apxs and just copy the file to the right place ourselves.
>
> I've attached my modified Portfile to this new ticket: https://trac.macports.org/ticket/57919
Ok, that might explain why I needed to use destroot {} (in mod_*), instead of
post-destroot {} (lib*) then?

With this patch… There's no need for the other fix (build.env-append*), or
should that one go in this file to?

// * as in:
> variant universal {}
> build.env-append    CC="${configure.cc}" \
>                     CFLAGS="${configure.cflags} [get_canonical_archflags cc]" \
>                     LDFLAGS="${configure.ldflags} [get_canonical_archflags ld]"

- - -


Haven't tried anything yet, of the Portfiles, been doing some tests with port
-vst install / port -t install. There's a lot of output there It creates a lot
of systemfolders, and also som trace warnings using stuff outside. Both
/opt/local, /usr/loca, /usr. Perhaps that's normal.

At first there was an (exit) error - which resolved to a program that was
symlinked to another. Removed that symlink and it passed.

They do install with -t, but there are some trace warnings etc. The tap errors
can be seen there to.

I put the output in a gist here:
https://gist.github.com/iEFdev/1cbf5c6ba046a0a29b3ea0638f5ba4ac (note: from
earlier - before your changes)
// I'll remove that one later

- - -


Do we continue here, or in the trac ticket(s)?

- - -


> … since github.setup sets it for you;
An off-topic question about github.setup… There's no gitlab.setup?
Or can it be used by manually specifying some variables? Their API's are almost
identical.
Haven't seen any port using Gitlab, but it would be great if one could.


· Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20190116/68abc05c/attachment.html>