LogoopenSUSE Build Service > Projects
Sign Up | Log In

View File libatomic_ops.spec of Package libatomic_ops (Project home:aevseev:devel)

%define realname libatomic_ops
%define realver  7.6.8
%define srcext   tar.gz

# turn off the generation of debuginfo rpm  (RH9) ??
%global debug_package %{nil}

# Common info
Name:          %{realname}
Version:       %{realver}
Release:       wiz%{?extraver:0.}1%{?dist}
License:       GPL-2.0+ and MIT
Group:         System/Libraries
URL:           https://github.com/ivmai/libatomic_ops/
Summary:       Atomic memory update operations portable implementation

# Build-time parameters
BuildRequires: pkgconfig
BuildRoot:     %{_tmppath}/%{name}-root
Source0:       http://www.ivmaisoft.com/_bin/atomic_ops/%{realname}-%{realver}%{?extraver}.%{srcext}
Source999:     baselibs.conf

%description
This package provides semi-portable access to hardware-provided
atomic memory update operations on a number architectures.  These might
allow you to write code:

* That does more interesting things in signal handlers.

* Makes more effective use of multiprocessors by allowing you to write
  clever lock-free code.  Note that such code is very difficult to get
  right, and will unavoidably be less portable than lock-based code.  It
  is also not always faster than lock-based code.  But it may occasionally
  be a large performance win.

* To experiment with new and much better thread programming paradigms, etc.

%package devel
Group:         Development/Languages/C and C++
Summary:       Atomic memory update operations portable implementation
Provides:      %{name}

%description devel
This package provides semi-portable access to hardware-provided
atomic memory update operations on a number architectures.  These might
allow you to write code:

* That does more interesting things in signal handlers.

* Makes more effective use of multiprocessors by allowing you to write
  clever lock-free code.  Note that such code is very difficult to get
  right, and will unavoidably be less portable than lock-based code.  It
  is also not always faster than lock-based code.  But it may occasionally
  be a large performance win.

* To experiment with new and much better thread programming paradigms, etc.

# Preparation step (unpackung and patching if necessary)
%prep
%setup -q -n %{realname}-%{realver}%{?extraver}

%build
%configure \
 CFLAGS="%{optflags} %{?gcc_lto}" \
 CXXFLAGS="%{optflags} %{?gcc_lto}" \
 LDFLAGS="-Wl,--as-needed -Wl,--strip-all %{?gcc_lto}"
%{__make} %{?_smp_mflags}

%install
%{__make} install DESTDIR=%{buildroot}
[ "%{buildroot}" != "/" ] && %{__rm} -rf %{buildroot}%{_datadir}/%{name}
[ "%{buildroot}" != "/" ] && %{__rm} -rf %{buildroot}%{_datadir}/doc

%clean
[ "%{buildroot}" != "/" ] && %{__rm} -rf %{buildroot}

%files devel
%defattr(-,root,root)
%doc AUTHORS COPYING ChangeLog README.md doc/*.txt
%{_libdir}/pkgconfig/atomic_ops.pc
%{_includedir}/atomic_ops/
%{_includedir}/*.h
%{_libdir}/*.a
%exclude %{_libdir}/*.la

%changelog