Bug 8531 - Solaris sed does not support regexp in Makefile DSO_EXPORTS_CMD
Solaris sed does not support regexp in Makefile DSO_EXPORTS_CMD
Product: Samba 3.6
Classification: Unclassified
Component: Build environment
Sparc Solaris
: P5 minor
: ---
Assigned To: Karolin Seeger
Samba QA Contact
Depends on:
  Show dependency treegraph
Reported: 2011-10-18 20:15 UTC by Michael Pelletier
Modified: 2012-05-04 13:02 UTC (History)
0 users

See Also:

git-am patch Bjorn pushed to master. (1.36 KB, patch)
2011-10-20 22:36 UTC, Jeremy Allison
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Pelletier 2011-10-18 20:15:07 UTC
I've seen myriad threads over the years discussing this error on Solaris systems:

/usr/local/bin/ld: cannot open linker script file
/install/samba-3.5.2/source3/exports/libtalloc.so.2: No such file or directory
collect2: ld returned 1 exit status
make: *** [bin/libtalloc.so.2] Error 1

Mine happens to be Solaris 8, but it appears from web searches on this error that it affects a number of other Solaris versions as well.

I determined that this is because the Makefile's DSO_EXPORTS_CMD (Makefile.in:31) uses a sed syntax that is probably peculiar to GNU sed:

DSO_EXPORTS_CMD=-Wl,--version-script,$(srcdir)/exports/`basename $@ | \
     sed 's/@SHLIBEXT@\(.[0-9]\{1,\}\)\{0,1\}$$/@SYMSEXT@/'`

That turns into this during the build:

`basename bin/libtalloc.so.2 | sed 's/so\(.[0-9]\{1,\}\)\{0,1\}$/syms/'`

This is supposed to turn into "libtalloc.syms".

However, the Solaris 8 (and others?) sed command does not recognize the use of curly braces against a multi-character regexp, so it just turns into libtalloc.so.2 since the sed doesn't match anything, and that file doesn't exist, of course.

By changing the sed command, it becomes more verbose, but fixes the build problem on Solaris 8 (and others?) and gives the same results, with the "{0}" of {0,1} as the first -e and the {1} as the second -e:

sed -e 's/@SHLIBEXT@$$/@SYMSEXT@/' -e 's/@SHLIBEXT@\.[0-9]\{1,\}$$/@SYMSEXT@/'

(Note that I changed the "." to a "\." so it will match only a period, rather than "sox123" - separate bug?)
Comment 1 Björn Jacke 2011-10-19 12:57:02 UTC
a simple

sed 's/@SHLIBEXT@\.[0-9][0-9]*$$/@SYMSEXT@/'

works as well? AFAICS this should do what we want without looking too ugly, right?
Comment 2 Michael Pelletier 2011-10-19 13:34:01 UTC
(In reply to comment #1)
> a simple
> sed 's/@SHLIBEXT@\.[0-9][0-9]*$$/@SYMSEXT@/'
> works as well? AFAICS this should do what we want without looking too ugly,
> right?

Not quite. In English, the original RE says:

Find "so" followed by zero or one occurrences of the following pattern at the end of the line:
______ any character (should be \., a dot) followed by one or more digits
and replace it with "syms"

So you're looking for "libtalloc.so" as well as "libtalloc.so.2" and "libtalloc.so.999". (You won't match "libtalloc.so.2.1" with the original RE.) The pattern you show above would only match "libtalloc.so.2" and "libtalloc.so.999", not "libtalloc.so" as the original pattern is trying to do.
Comment 3 Björn Jacke 2011-10-20 10:47:03 UTC
given that the solaris sed (maybe others, too) are limited as you pointed out, this might be a way to be compatible, match files ending on .so, .so.1 and .so.1.1 and so on:

sed "s:so[\.0-9]*$:syms:"

sure, this is also matching on "so0815" or "so..." but this is negligible I think.
Comment 4 Michael Pelletier 2011-10-20 15:28:17 UTC
I like the look of that. My main goal above was to duplicate the exact operation of the original, but if there's no grand historical reason dating back to Samba 1.0.3 why .so.1.1 should not be matched and replaced, then there's no reason to slavishly adhere to the original mechanism.

It might be a tad safer to go:

sed "s:\.so[\.0-9]*$:.syms:"

... but that's just me being fussy.
Comment 5 Jeremy Allison 2011-10-20 22:36:07 UTC
Created attachment 7015 [details]
git-am patch Bjorn pushed to master.

Patch Bjorn pushed to master.
Comment 6 Jeremy Allison 2011-10-20 22:36:26 UTC
Assigning to Karolin for 3.6.2.
Comment 7 Björn Jacke 2011-10-21 08:36:54 UTC
wanted to wait for the commit hash in master: it's 37be1df3d7534c2cc8e1e25614164c2178372b94. Thanks Michael!

imho we should also pick this one at least to 3.5.
Comment 8 Karolin Seeger 2011-10-21 18:51:14 UTC
Pushed to v3-5-test and v3-6-test.
Closing out bug report.