Issue 15899 - patch on Solaris is not GNU patch
Summary: patch on Solaris is not GNU patch
Status: CLOSED FIXED
Alias: None
Product: Build Tools
Classification: Code
Component: code (show other issues)
Version: OOo 1.1 Beta2
Hardware: Sun Solaris
: P3 Trivial (vote)
Target Milestone: OOo 1.1
Assignee: sander_traveling
QA Contact: issues@tools
URL:
Keywords:
: 16618 (view as issue list)
Depends on:
Blocks:
 
Reported: 2003-06-21 19:05 UTC by pavel
Modified: 2004-08-12 17:27 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description pavel 2003-06-21 19:05:36 UTC
Hi,

Solaris' patch can not apply boost patch in current RC tree (the same applied to
11beta2 and 1.0.3):

x boost_1_27_0/tools/build/tru64cxx-tools.jam, 3038 bytes, 6 tape blocks
x boost_1_27_0/tools/build/tru64cxx65-tools.jam, 2930 bytes, 6 tape blocks
x boost_1_27_0/tools/build/unit-tests.jam, 9655 bytes, 19 tape blocks
x boost_1_27_0/tools/build/vacpp-tools.jam, 2205 bytes, 5 tape blocks
x boost_1_27_0/tools/make-cputime-page.pl, 1173 bytes, 3 tape blocks
make writeable...
cd ./unxsols4.pro/misc/build && cat ../../../boost_1_27_0.patch | patch -b -p2
&& touch so_patched_ooo_boost
  Looks like a new-style context diff.
  The next patch looks like a new-style context diff.
  The next patch looks like a new-style context diff.
  The next patch looks like a new-style context diff.
  The next patch looks like a new-style context diff.
  The next patch looks like a new-style context diff.
File to patch: ^C

[1] 18641 18642
---* TG_SLO.MK *---

ERROR: Error 65280 occurred while making /ultra/BuildDir/ooo_11rc_src/boost
oo@ultra:/ultra/BuildDir/ooo_11rc_src/boost> 

What do you really use to build OOo for Solaris? :-)
It seems to me like GNU system with SOlaris kernel...

Using GNU patch:

oo@ultra:/ultra/BuildDir/ooo_11rc_src/boost/unxsols4.pro/misc/build> cat
../../../boost_1_27_0.patch | /usr/local/bin/patch --dry-run -p2
patching file boost_1_27_0/boost/config/user.hpp
patching file boost_1_27_0/boost/detail/atomic_count_linux.hpp
patching file boost_1_27_0/boost/detail/shared_array_nmt.hpp
patching file boost_1_27_0/boost/detail/shared_count.hpp
patching file boost_1_27_0/boost/detail/shared_ptr_nmt.hpp
patching file boost_1_27_0/boost/detail/linux_atomic.h
oo@ultra:/ultra/BuildDir/ooo_11rc_src/boost/unxsols4.pro/misc/build> 

No problem!
Comment 1 sander_traveling 2003-06-22 22:25:32 UTC
hmm... I thought this was the reason why there is a 'gnupatch' in
unitools.mk 8-)
Comment 2 pavel 2003-06-29 11:58:04 UTC
;-)

Will we do something with it?

I'm all for using only context diffs instead of unified diffs and not
requiring GNU patch on Solaris systems.
Comment 3 Martin Hollmichel 2003-07-09 16:51:12 UTC
*** Issue 16618 has been marked as a duplicate of this issue. ***
Comment 4 pavel 2003-07-10 12:31:43 UTC
Vladimir Glazounov notified me, that GNU patch should be patch on
Solaris - see http://tools.openoffice.org/ext_comp.html

Although I use GNU patch (and have in in /usr/local/bin, I do not
agree with this solution (calling patch on Solaris should be patch,
not GNU patch).

So we should remove all those gnupatch things from sources or (IMHO
better) remove the need for GNU patch at all and use system patch on
Solaris.

Or we should test in configure for the version or call configure
--with-patch=/usr/local/bin/patch. We should not depend on patch being
GNU patch!
 
Comment 5 pavel 2003-07-13 11:03:46 UTC
Changing the title.

patch on Solaris is not GNU patch and should not be!
Comment 6 hjs 2003-07-14 18:52:48 UTC
as GNU patch is a stated requirement  i see no real advantage on
switching back to solaris system patch. it would be nice to be
"solaris patch clean" but it would require to check each and every
patch for compatibility. not only the existing but also every new one.
i admit that calling it patch also is no good idea and should be fixed.
Comment 7 sander_traveling 2003-07-14 18:58:48 UTC
i think the only really feasible fix is to a) make sure patch is
always called via $GNUPATCH (just as make needs to be called via
$GNUMAKE) and b) make the value of GNUPATCH be picked up from the
environment. 

otherwise we will get a continuos stream of patches and repatches that
fix when people assume gnu diff/patch 
Comment 8 pavel 2003-07-14 19:58:22 UTC
I agree with a) and would like to propose different b):

b) use `which patch` unless something like
--with-gnu-patch=/usr/local/bin/patch

is specified.

Configure should also check if `which patch` is GNU patch. If it is
not it should emit an error/warning like:

Warning: `which patch` is not GNU patch as required, use --with-gnu-patch

OK?
Comment 9 sander_traveling 2003-07-15 04:16:13 UTC
I added --with-gnu-patch option to configure.in, and made unitools.mk
pick up the value. not quite as fancy implementation but should do the
job. 

marking as fixed 
Comment 10 jens-heiner.rechtien 2004-08-12 17:27:40 UTC
Closing ...