<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#333333">
<br>
<div class="moz-cite-prefix">On 1/16/19 19:22 , Ryan Schmidt wrote:<br>
</div>
<blockquote
cite="mid:A012EAA7-8B22-4DE2-99F7-E2D9FCF31622@macports.org"
type="cite">
<pre wrap="">On Jan 15, 2019, at 15:55, Eric F (iEFdev) wrote:
</pre>
<blockquote type="cite">
<pre wrap="">It's a 2 part install. C lib (dependency) + a module.
- <a class="moz-txt-link-freetext" href="https://github.com/maxmind/libmaxminddb/">https://github.com/maxmind/libmaxminddb/</a>
</pre>
</blockquote>
<pre wrap="">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: <a class="moz-txt-link-freetext" href="https://trac.macports.org/ticket/44709">https://trac.macports.org/ticket/44709</a>
</pre>
</blockquote>
Thanks Ryan! I'll look in to this right away.<br>
<br>
I did push the Portfile to a tmp branch on my MP fork:
<a class="moz-txt-link-freetext" href="https://github.com/iEFdev/macports-ports/blob/maxminddb_x2/devel/libmaxminddb/Portfile">https://github.com/iEFdev/macports-ports/blob/maxminddb_x2/devel/libmaxminddb/Portfile</a><br>
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.<br>
<br>
<blockquote
cite="mid:A012EAA7-8B22-4DE2-99F7-E2D9FCF31622@macports.org"
type="cite">
<blockquote type="cite">
<pre wrap=""> - <a class="moz-txt-link-freetext" href="https://github.com/maxmind/mod_maxminddb/">https://github.com/maxmind/mod_maxminddb/</a>
</pre>
</blockquote>
<pre wrap="">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"?</pre>
</blockquote>
Yes, that was prob a “draft issue”. In the version I pushed it is
www. :)<br>
<a class="moz-txt-link-freetext" href="https://github.com/iEFdev/macports-ports/blob/maxminddb_x2/www/mod_maxminddb/Portfile">https://github.com/iEFdev/macports-ports/blob/maxminddb_x2/www/mod_maxminddb/Portfile</a><br>
<br>
<br>
<blockquote
cite="mid:A012EAA7-8B22-4DE2-99F7-E2D9FCF31622@macports.org"
type="cite">
<blockquote type="cite">
<pre wrap="">On 1/16/19 0:35 , Ryan Schmidt wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">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)?
</pre>
</blockquote>
<pre wrap="">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: <a class="moz-txt-link-freetext" href="https://trac.macports.org/ticket/57919">https://trac.macports.org/ticket/57919</a>
</pre>
</blockquote>
Ok, that might explain why I needed to use destroot {} (in mod_*),
instead of post-destroot {} (lib*) then?<br>
<br>
With this patch… There's no need for the other fix
(build.env-append*), or should that one go in this file to?<br>
<br>
// * as in:<br>
<blockquote type="cite">
<pre wrap="">variant universal {}
build.env-append CC="${configure.cc}" \
CFLAGS="${configure.cflags} [get_canonical_archflags cc]" \
LDFLAGS="${configure.ldflags} [get_canonical_archflags ld]"</pre>
</blockquote>
<br>
- - - <br>
<br>
<br>
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.<br>
<br>
At first there was an (exit) error - which resolved to a program
that was symlinked to another. Removed that symlink and it passed.<br>
<br>
They do install with -t, but there are some trace warnings etc. The
tap errors can be seen there to.<br>
<br>
I put the output in a gist here:
<a class="moz-txt-link-freetext" href="https://gist.github.com/iEFdev/1cbf5c6ba046a0a29b3ea0638f5ba4ac">https://gist.github.com/iEFdev/1cbf5c6ba046a0a29b3ea0638f5ba4ac</a>
(note: from earlier - before your changes)<br>
// I'll remove that one later<br>
<br>
- - -<br>
<br>
<br>
Do we continue here, or in the trac ticket(s)?<br>
<br>
- - -<br>
<br>
<br>
<blockquote type="cite">
<pre wrap="">… since github.setup sets it for you;</pre>
</blockquote>
An off-topic question about github.setup… There's no gitlab.setup?<br>
Or can it be used by manually specifying some variables? Their API's
are almost identical.<br>
Haven't seen any port using Gitlab, but it would be great if one
could.<br>
<br>
<br>
· Eric<br>
</body>
</html>