Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=498736 --- Comment #3 from David Sugar <dyfet@xxxxxxxxxxxxxxxx> 2009-05-02 13:57:35 EDT --- 1. ucommon is NOT the same as commoncpp. Both can also co-exist. ucommon is technically a successor package to commoncpp. 2. I use a macro for that because ucommon can be built in a deeply embedded profile without using libstdc++, so if in theory one uses to spec to cross-compile such a target, one can force libstdc++ off. Incidentally, related to this, unfortunately libtool forces libstdc++ into a build even if you neither use nor want it, even if otherwise --nostdc is specified for example. To get around this, some special build magic is done to link in libtool under "C" profile. Is there a better way to do this? 3. I define %version and %release this way because I have a build script to override (autogenerate) values for a rpmbuild through the --define option (also why I have %uses_...). These can be killed of course to normalize the spec file :). Hence my goal was to have a single spec I could use internally as well as externally. But easy enough to redefine by normal conventions :) 4. Remaining items look also easy enough to resolve. How do I submit an updated spec file? -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review