Closed ctreleaven closed 1 year ago
Right, the files didn't find their way into the tarball that's mirrored to sourceforge. I just wonder if macports is not able to use the zip from github, or even better, why it can't just be pointed directly to the release-tag?
MacPorts prefers bz2 archives where possible since they're typically a fair bit smaller. (We package several thousand open source projects.)
I'd prefer to keep using the Github release tarball since that's worked well for some time now. It appears we're not the only ones who uses Github releases:
https://repology.org/project/libupnp/information
Is it a problem to do a new release including the missing files?
The tarball in sourceforge is supposed to be an automatic copy of the tarball here in GitHub. If it is not, then there is a problem with the process.
I'd prefer to keep using the Github release tarball since that's worked well for some time now. It appears Is it a problem to do a new release including the missing files?
Not at all. But I need to know what went wrong.
The bz2 file has been generated by me with make distcheck
. Then I generate the .bz2.sha1 file by hand too.
Which are the missing files? Maybe they are not in the autotools file list, we could fix that easily.
In the configure phase, cmake is complaining that the following files are missing:
Log says cmake/test-functions.cmake, cmake/autoheader.cmake and cmake/options.cmake but it doesn't go any further. So basically 3/4 of the cmake dir. I remember we talked about something like that, but maybe in the other branch.
@ctreleaven ,
Please check 1.14.15 and close this issue if solved.
Regards, Marcelo.
Thank you for the quick turnaround, the new release seems to be working well.
Just fyi, our project has a fleet of buildbots to test building each project ("port") on various Mac archs and OS versions. libupnp is still waiting in the backlog for a few of the buildbots but it has now built successfully on Apple Silicone with recent OS versions as well as Intel (both 64-bit and ancient 32-bit platforms). Appropriate versions of clang are used on all of these builders.
In case it helps, clang does note a warning during the build. For example, building on macOS 12.2.1 on Apple silicone, the following warning is issued:
/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_devel_libupnp/libupnp/work/libupnp-1.14.15/upnp/src/threadutil/ThreadPool.c:431:3: warning: cast to smaller integer type 'unsigned int' from 'pthread_t _Nonnull' (aka 'struct _opaque_pthread_t *') [-Wpointer-to-int-cast]
1 warning generated.
/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_devel_libupnp/libupnp/work/libupnp-1.14.15/upnp/src/threadutil/ThreadPool.c:431:3: warning: cast to smaller integer type 'unsigned int' from 'pthread_t _Nonnull' (aka 'struct _opaque_pthread_t *') [-Wpointer-to-int-cast]
1 warning generated.
Full build log is here: https://build.macports.org/builders/ports-12_arm64-builder/builds/72938/steps/install-port/logs/main.log (These logs will be deleted after a few weeks.)
A similar warnings seem to be issued on the other builders. This is not a show-stopper but I thought you might like to know.
Thanks again.
Hi Craig,
Thank you for your report and the error message. I have no way to test it here, but if you send a tested pull request, I can accept it. The typecasts are there just to generate the seed for the srand()
function, so you could probably change them to unsigned long
and the message should go away. Maybe you will need an extra typecast to unsigned int
because the parameter of srand()
is unsigned int
. Something like this:
#elif defined(BSD) || defined(__APPLE__) || defined(__FreeBSD_kernel__)
srand((unsigned int)((unsigned long)t.tv_usec +
(unsigned long)ithread_get_current_thread_id()));
Best regards, Marcelo.
Trying to build libupnp 1.14.14 for MacPorts with the tarball from releases but configure fails due to missing files, as follows: