https://bugs.openldap.org/show_bug.cgi?id=9226
Bug ID: 9226
Summary: MinGW build fails to link rewrite program with
--enable-dynamic
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: ryan(a)openldap.org
Target Milestone: ---
/bin/sh ../../libtool --mode=link cc -g -O2 -o rewrite rewrite.o parse.o
librewrite.a ../../libraries/libldap_r/libldap_r.la
../../libraries/liblber/liblber.la ../../libraries/liblutil/liblutil.a
-lregex -lws2_32
libtool: link: cc -g -O2 -o .libs/rewrite rewrite.o parse.o librewrite.a
../../libraries/libldap_r/.libs/libldap_r.dll.a
/home/ryan/openldap/libraries/liblber/.libs/liblber.dll.a
../../libraries/liblber/.libs/liblber.dll.a ../../libraries/liblutil/liblutil.a
-lregex -lws2_32 -L/mingw64/lib
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
../../libraries/liblutil/liblutil.a(utils.o): in function `lutil_str2bin':
C:\msys64\home\ryan\openldap\libraries\liblutil/utils.c:933: undefined
reference to `__imp_ber_memfree_x'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
C:\msys64\home\ryan\openldap\libraries\liblutil/utils.c:887: undefined
reference to `__imp_ber_memalloc_x'
collect2.exe: error: ld returned 1 exit status
make[2]: *** [Makefile:292: rewrite] Error 1
I think this is caused by the order of libraries on the link line. MinGW's
import libraries (.dll.a) behave like static libraries with one .o per
function, so liblutil.a should come before liblber.dll.a. I guess it doesn't
occur on UNIX because the shared libraries are scanned differently. It doesn't
occur with static linking because entire objects are linked and
liblber.a/memory.o is already pulled in by libldap.
N.B.: RE24 with --enable-dynamic fails to link liblber; the error looks
superficially similar but it is not the same. RE24's issue is a libtool bug,
already fixed in master by upgrading libtool.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=9215
Bug ID: 9215
Summary: Embedded _XOPEN_SOURCE breaks Solaris build
[regression]
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: grapvar(a)gmail.com
Target Milestone: ---
The commit [2020-03-26 57b7003 | thr_posix.c: fix implicit function declaration
for 'pthread_setconcurrency']
introduced in the bug 8676, comment 8:
> --- a/libraries/libldap_r/thr_posix.c
> +++ b/libraries/libldap_r/thr_posix.c
> @@ -15,4 +15,6 @@
> */
>
> +#define _XOPEN_SOURCE 500 /* For pthread_setconcurrency() on glibc */
> +
> #include "portable.h"
breaks build on Solaris (likely any version; irrelevant compiling options
omitted):
| cc ... -c ../../../libraries/libldap_r/thr_posix.c -o .libs/thr_posix.o
| "/usr/include/sys/feature_tests.h", line 354: #error: "Compiler or options
invalid for pre-UNIX 03 X/Open applications and pre-2001 POSIX applications"
The system headers bear in mind:
"If you are using c99-compatible compiler ..."
and we all are using such compilers in 2020, isn't it?
"... and want to use X/Open CAE, it must be at least Issue 6"
i.e., not the Issue 5 (_XOPEN_SOURCE=500).
This part of system headers came from the times when Solaris was Sun yet. Given
the long respectful history of Sun's commitment to standard conformance, I
trust this assertion.
The problem, however, is not an incorrect X/Open version this patch employs.
1st of all, this patch is a system-specific hack, that targets not even
GNU-based systems, but, I suppose, specifically, GNU linux, maybe, even
specific version and distro. E.g., there are no problems with
pthread_setconcurrency() visibility on Solaris.
2nd of all, the influence of configuration macros _XOPEN_SOURCE, _POSIX_SOURCE,
_POSIX_C_SOURCE, _XOPEN_VERSION, _XOPEN_SOURCE_EXTENDED, __EXTENSIONS__ etc is
very system- and compiler- specific, and embedding these macros directly in a
source is likely to cause problems.
I believe the best course of action is to put a test in autoconf to check what
is the best way to achieve pthread_setconcurrency() visibility on any given
system.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=9213
Bug ID: 9213
Summary: undefined reference in back_ldap when
--enable-ldap=mod and --disable-dynamic
Product: OpenLDAP
Version: 2.4.49
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: ryan(a)openldap.org
Target Milestone: ---
./configure --enable-modules --enable-ldap=mod
doesn't link back_ldap with libldap (--enable-dynamic is disabled per default).
The resulting binary doesn't work; slapd has libldap statically linked, but
doesn't include all the symbols back_ldap uses: specifically ldap_modify_ext.
slaptest passes, but back_ldap fails at runtime (test022 fails). Not sure if
other modules would have the same problem.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=9212
Bug ID: 9212
Summary: [2.5] entry_schema_check can leave text uninitialized
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: ryan(a)openldap.org
Target Milestone: ---
76df74dbeab47195e42946a474c3a5f8557c168d removed some important snprintfs in
schema_check.c. Now we can get uninitialized data in *text for these cases. For
example:
$ ./clients/tools/ldapmodify -H ldap://:9000 -x -D cn=admin,dc=example,dc=com
-w secret
dn: cn=test,dc=example,dc=com
changetype: add
objectclass: device
adding new entry "cn=test,dc=example,dc=com"
dn: cn=test,dc=example,dc=com
add: sn
sn: test
modifying entry "cn=test,dc=example,dc=com"
ldap_modify: Object class violation (65)
additional info: |
$ ./clients/tools/ldapmodify -H ldap://:9000 -x -D cn=admin,dc=example,dc=com
-w secret
dn: cn=test,dc=example,dc=com
add: sn
sn: test
modifying entry "cn=test,dc=example,dc=com"
ldap_modify: Object class violation (65)
additional info:
^[[?1;2c
$
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=9209
Bug ID: 9209
Summary: test072/test075 fail on Solaris due to buggy test
script
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Both test072 and test075 have this logic:
if test -z `which dsadm`; then
echo "DSEE dsadm not in path, test skipped"
exit 0
fi
This works fine on Linux, however it does not work on Solaris causing the test
to execute (and then fail).
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=9207
Bug ID: 9207
Summary: Remove Moznss compatibility layer
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
For the 2.5 release, remove the MozNSS compatibility layer.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=9201
Bug ID: 9201
Summary: LDAP_THREAD_DEBUG doesn't compile
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: ryan(a)openldap.org
Target Milestone: ---
on master @ 4ac88b219d:
./configure CPPFLAGS="-DLDAP_THREAD_DEBUG" && make
make[2]: Entering directory '/home/ryan/tmp/openldap/libraries/libldap_r'
/bin/sh ../../libtool --mode=compile cc -g -O2 -I../../include
-I../../include -DLDAP_R_COMPILE -I./../libldap -DLDAP_THREAD_DEBUG
-DLDAP_LIBRARY -c threads.c
cc -g -O2 -I../../include -I../../include -DLDAP_R_COMPILE -I./../libldap
-DLDAP_THREAD_DEBUG -DLDAP_LIBRARY -c threads.c -fPIC -DPIC -o .libs/threads.o
In file included from ldap_thr_debug.h:129,
from threads.c:73:
../../include/ldap_pvt_thread.h:114:1: error: conflicting types for
'ldap_pvt_thread_mutex_recursive_init'
ldap_pvt_thread_mutex_recursive_init LDAP_P(( ldap_pvt_thread_mutex_t *mutex
));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from ldap_thr_debug.h:129,
from threads.c:26:
../../include/ldap_pvt_thread.h:114:1: note: previous declaration of
'ldap_pvt_thread_mutex_recursive_init' was here
ldap_pvt_thread_mutex_recursive_init LDAP_P(( ldap_pvt_thread_mutex_t *mutex
));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
make[2]: *** [Makefile:420: threads.lo] Error 1
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=9194
Bug ID: 9194
Summary: slapd-ndb: Remove backend for the 2.5 release
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Remove the slapd-ndb backend for the 2.5 release, as it was never finished and
development on it has ceased.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=9191
Bug ID: 9191
Summary: libraries\liblutil\meter.c have a bad function
lutil_meter_update, maybe divide 0
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: client tools
Assignee: bugs(a)openldap.org
Reporter: digpython(a)163.com
Target Milestone: ---
int
lutil_meter_update (
lutil_meter_t *meter,
size_t position,
int force)
{
static const double display_rate = 0.5;
double frac, cycle_length, speed, now;
time_t remaining_time, elapsed;
int rc;
assert( meter != NULL );
lutil_get_now( &now );
if ( !force && now - meter->last_update < display_rate ) return 0;
frac = ((double)position) / ((double) meter->goal_value);
elapsed = now - meter->start_time;
if (frac <= 0.0) return 0;
if (frac >= 1.0) {
rc = meter->display->display_update(
&meter->display_data,
1.0,
0,
(time_t) elapsed,
((double)position) / elapsed);
} else {
...
}
--
You are receiving this mail because:
You are on the CC list for the bug.