#32482: rtmpdump: update to 2.4 ---------------------------+------------------------------------------------ Reporter: dargo@… | Owner: captsolo@… Type: update | Status: new Priority: Normal | Milestone: Component: ports | Version: Keywords: haspatch | Port: rtmpdump ---------------------------+------------------------------------------------ Changes (by ryandesign@…): * keywords: => haspatch * cc: ryandesign@… (added) Comment: Attached is a Portfile patch and updated patchfiles to update to 2.4. Please evaluate and indicate whether it can be committed, or attach alternate patches. Upstream now defines the library version number as 0; in our old patchfile, since upstream had not defined a library version number, we had set it the same as the program version number. Since with this update the library version number will change from 2.3 down (!) to 0, all ports linking with librtmpdump will need their revisions increased to force a rebuild. Upstream changes in 2.4 include support for building OS X dylibs, and building the shared library by default (in addition to the static one) so some parts of the patchfiles were no longer necessary. Upstream neglected to use the `-install_name` argument when creating the dylib so I retained that from the old patch. I did not retain the `-current_version` and `-compatibility_version` arguments we were using in our old patch, because 0 is the default anyway, and I recall badness on Tiger when these arguments are set to zero. Upstream would be wise to select a library version number greater than zero. Other dylib creation arguments in our old patchfile I did not retain are `-Wl,-undefined`, `-Wl,dynamic_lookup`, and `-Wl,-single_module`, because I do not know their purpose. Meanwhile, dylib creation arguments upstream is using that we were not using are `-flat_namespace`, `-undefined suppress` and `-fno-common`; I do not know their purpose either. I retained the part of our patchfiles that changed the VERSION variable from e.g. "v2.4" to just "2.4". I do not know why we are doing this. I imagine it was at least partly to ease computation of the library version number; since we no longer compute the library version number, perhaps we can stop munging the VERSION. Since this version's distfile does not show up in the directory listing, the livecheck still thinks 2.3 is the latest version. Upstream would be wise to fix their directory listing. -- Ticket URL: <https://trac.macports.org/ticket/32482#comment:7> MacPorts <http://www.macports.org/> Ports system for Mac OS