Curiously from --- samba-4.0.3/wscript Tue Dec 4 21:07:44 2012 +++ samba-4.0.26/wscript Mon Dec 8 18:46:38 2014
- if sys.platform != "openbsd4": + if not sys.platform.startswith("openbsd"): conf.env.asneeded_ldflags = conf.ADD_LDFLAGS('-Wl,--as-needed', testflags=True) --- samba-4.0.3/buildtools/wafadmin/Tools/config_c.py Tue Oct 2 18:24:39 2012 +++ samba-4.0.26/buildtools/wafadmin/Tools/config_c.py Wed May 28 03:20:37 2014 @@ -73,6 +73,19 @@ app('CCFLAGS_' + uselib, x) app('CXXFLAGS_' + uselib, x) app('LINKFLAGS_' + uselib, x) + # + # NOTE on special treatment of -Wl,-R and -Wl,-rpath: + # + # It is important to not put a library provided RPATH + # into the LINKFLAGS but in the RPATH instead, since + # the provided LINKFLAGS get prepended to our own internal + # RPATH later, and hence can potentially lead to linking + # in too old versions of our internal libs. + # + elif x.startswith('-Wl,-R'): + app('RPATH_' + uselib, x[6:]) + elif x.startswith('-Wl,-rpath,'): + app('RPATH_' + uselib, x[11:]) elif x.startswith('-Wl'): app('LINKFLAGS_' + uselib, x) elif x.startswith('-m') or x.startswith('-f'): There is also a bunch of PIE related changes too, I'll post if people think they may be relevant. Ian McWilliam ________________________________________ From: owner-t...@openbsd.org [owner-t...@openbsd.org] on behalf of Stuart Henderson [st...@openbsd.org] Sent: Wednesday, 10 June 2015 9:48 PM To: Mark Kettenis Cc: tech@openbsd.org Subject: Re: samba4 slow startup, shared libs? On 2015/06/05 13:27, Mark Kettenis wrote: > > Date: Fri, 5 Jun 2015 11:15:38 +0100 > > From: Stuart Henderson <st...@openbsd.org> > > > > net/samba4 is in the ports tree but not currently enabled in the build, > > we're still only using samba 3.x for various reasons, but unfortunately > > samba 3 is getting decreasingly useful as more Windows setups move to > > newer versions. > > > > One of the issues is that startup of samba4 on OpenBSD is very slow > > indeed, seemingly before control is transferred to the program. From > > the LD_DEBUG output with timestamps (using the very handy ts(1) from > > "moreutils"): > > > > # LD_DEBUG=1 smbd -D 2>&1 | ts %.s > > <..snip..> > > 1433498513.546306 examining: '/usr/local/lib/libhogweed.so.1.1' > > 1433498513.546323 loading: libnettle.so.1.2 required by > > /usr/local/lib/libhogweed.so.1.1 > > 1433498513.546339 loading: libgmp.so.9.0 required by > > /usr/local/lib/libhogweed.so.1.1 > > 1433498513.546354 linking dep /usr/local/lib/libnettle.so.1.2 as child of > > /usr/local/lib/libhogweed.so.1.1 > > 1433498513.546370 linking dep /usr/local/lib/libgmp.so.9.0 as child of > > /usr/local/lib/libhogweed.so.1.1 > > 1433498513.546386 examining: '/usr/local/lib/libgmp.so.9.0' > > 1433498584.125659 flags /usr/libexec/ld.so = 0x0 > > 1433498584.125783 obj /usr/libexec/ld.so has smbd as head > > 1433498584.149165 relocation took 0.023504 > > 1433498584.149215 Start End Type Open Ref > > GrpRef Name > > 1433498584.149249 000004bec6500000 000004bec6910000 exe 1 0 0 > > smbd > > 1433498584.149272 000004c19b74e000 000004c19bb60000 rlib 0 107 0 > > /usr/lib/libpthread.so.19.0 > > 1433498584.149293 000004c18f3df000 000004c18f812000 rlib 0 75 0 > > /usr/local/lib/libsamba-util.so.0.0 > > <..snip..> > > > > - a 74 second delay after "examining: '/usr/local/lib/libgmp.so.9.0'". > > Does anyone have suggestions for finding out what's going on here? > > Full text snipped from the above is at > > http://junkpile.org/samba4-lddebug.txt > > My first guess would have been that it is spending a lot of time on > initial relocations. But the line: > > 1433498584.149165 relocation took 0.023504 > > pretty much rules that out. My suggestion would be to add a few more > DL_DEB() statements inside of ld.so/loader.c:_dl_boot(), starting just > after the _dl_load_dep_libs() call in that function and try to narrow > it down. > The part taking the biggest chunk of time is _dl_cache_grpsym_list() with its recursive calls (64 seconds). 1433936487.139917 _dl_cache_grpsym_list: 1433936551.414114 _dl_cache_grpsym_list:done ctors for libpthread are fairly slow too (35 seconds) but I think that's out of ld.so's hands. ... 1433936551.538493 _dl_debug_state done 1433936551.538508 doing ctors obj 0x138a43269400 @0x138a74fe0ca0: [/usr/lib/libpthread.so.19.0] 1433936587.157910 doing ctors obj 0x138ae5e30800 @0x138af0447f80: [/usr/local/lib/samba/libreplace.so.0.0] ...