Looks like this is the problem:
Makefile.am:
{{{
NSS_LINK = @nss_lib@ -lssl3 -lnss3
}}}
but
{{{

pkg-config --libs nss

-lssl3 -lsmime3 -lnss3 -lnssutil3 -lplds4 -lplc4 -lnspr4 -lpthread -ldl
}}}
So it looks as though we need to add -lnssutil3 to NSS_LINK

No that did not solve my problem.
Changed NSS_LINK to NSS_LINK = @nss_lib@ -lssl3 -lnss3 -lnssutil3 in Makefile.am and Makefile.in; make distclean; reconfigure;make. Same result obtained.
I will try witl all the libs in the pkg-config output and see what happens.

No, it seems it is not working. Do you have other ideas that I could try?

Thanks,
Steve.

Maybe order is significant? Try putting the NSS links near the end, after the libldap_r.so and liblber.so links, followed by the NSPR links, followed by system links such as -lpthread and -ldl

Indeed it was a problem with the libraries. I added path to my nss libraries when linking libslapd.so with -L/path and that solved my problem.

But now I have another problem at "make" stage:
....................................................................
make[1]: *** No rule to make target ldap/ldif/90betxn-plugins.ldif', needed byall-am'. Stop.

Do you have any suggestions for what could be the cause here?

Thanks,
Steve.

Replying to [comment:5 stevegreg]:

Indeed it was a problem with the libraries. I added path to my nss libraries when linking libslapd.so with -L/path and that solved my problem.

I don't understand. Can you be more specific? This is your original build path:
{{{
-L/usr/local/pkgs/389_ds_depencences/nss-3.14/lib
}}}

Was this path not correct?

But now I have another problem at "make" stage:
....................................................................
make[1]: *** No rule to make target ldap/ldif/90betxn-plugins.ldif', needed byall-am'. Stop.

Do you have any suggestions for what could be the cause here?

Does the file ldap/ldif/90betxn-plugins.ldif exist? Are you using the latest source from git master branch?

Thanks,
Steve.

Yes, -L/path was referring to "-L/usr/local/pkgs/389_ds_depencences/nss-3.14/lib"

I use 389-ds-base-1.3.0.a1 and it seems the problem was not solved by adding -L/path but was introducing another one (this with 90betxn-plugins.ldif) before. I commented 90betxn-plugins.ldif from Makefile.am and Makefile.in and get back to my previous error.

ldap/ldif/90betxn-plugins.ldif file does not exist. Should it be there by default or it is created by make?

I belive something is messed up really seriously at my workstation.

From http://directory.fedoraproject.org/wiki/Building#NSS it says:
configure attempts to find all of the dependent components using pkg-config (e.g. pkg-config --libs nspr) or using the component specific script (e.g. net-snmp-config or icu-config).

But running:
pkg-config --libs nspr, gives me:
Package nspr was not found in the pkg-config search path.
Perhaps you should add the directory containing `nspr.pc'
to the PKG_CONFIG_PATH environment variable
No package 'nspr' found
This may be a cause for not having the paths solved by default. Maybe I should try to solve this problem first.

Replying to [comment:7 stevegreg]:

Yes, -L/path was referring to "-L/usr/local/pkgs/389_ds_depencences/nss-3.14/lib"

I use 389-ds-base-1.3.0.a1 and it seems the problem was not solved by adding -L/path but was introducing another one (this with 90betxn-plugins.ldif) before. I commented 90betxn-plugins.ldif from Makefile.am and Makefile.in and get back to my previous error.

ldap/ldif/90betxn-plugins.ldif file does not exist. Should it be there by default or it is created by make?

It is in the upstream source:
master branch - http://git.fedorahosted.org/cgit/389/ds.git/tree/ldap/ldif/90betxn-plugins.ldif
1.2.11 branch - http://git.fedorahosted.org/cgit/389/ds.git/tree/ldap/ldif/90betxn-plugins.ldif?h=389-ds-base-1.2.11

I don't know why you don't have this file.

I belive something is messed up really seriously at my workstation.

From http://directory.fedoraproject.org/wiki/Building#NSS it says:
configure attempts to find all of the dependent components using pkg-config (e.g. pkg-config --libs nspr) or using the component specific script (e.g. net-snmp-config or icu-config).

Right. It attempts if you don't specify --with-nspr, --with-nss, etc.

But running:
pkg-config --libs nspr, gives me:
Package nspr was not found in the pkg-config search path.
Perhaps you should add the directory containing `nspr.pc'
to the PKG_CONFIG_PATH environment variable
No package 'nspr' found
This may be a cause for not having the paths solved by default. Maybe I should try to solve this problem first.

No - your previous messages indicate that you are attempting to build all of the components from source - you would typically only use pkg-config to use the -devel or -dev package provided by your distribution.

I believe it worked now. The ldap/ldif/90betxn-plugins.ldif file was missing becouse I was given "make distclean" and it seems this deletes more files than it should.

I solved the problem by recreating the .libs/libslapd.so.0.0.0 library and its symbolic links by adding to the link line -Wl,-rpath -Wl,path to nss and -Wl,-rpath -Wl,path to nspr and also adding "-lfreebl -lfreebl3" link libraries.

I succeeded to compile and install 389-ds-base, will try to install the consoles too and 389-admin and 389-adminutil and give it a try to see if something works in the end.

Will come back if get more trouble with the rest.

Thanks,
Steve.

I installed everithing and run ./setup-ds-admin.pl. I used:
............................................................
Computer name [linux-6ytl.example.com]: localhost

WARNING: There are problems with the hostname.
The hostname 'localhost' does not look like a
fully qualified host and domain name.

Please check the spelling of the hostname and/or your network configuration.
If you proceed with this hostname, you may encounter problems.

Do you want to proceed with hostname 'localhost'? [no]: yes
............................................................
If you want to configure the Administration Server to bind
to a specific IP address, enter the address below.

IP address [0.0.0.0]: 127.0.0.1
............................................................
The interactive phase is complete. The script will now set up your
servers. Enter No or go Back if you want to change something.

Are you ready to set up your servers? [yes]:
Creating directory server . . .
Warning: hostname localhost is not a fully qualified host and domain name
Failed to issue method call: Unit dirsrv at localhost.service (Unit dirsrv@localhost.service ) failed to load:
No such file or directory.
See system logs and 'systemctl status dirsrv@localhost.service' for details.
Attempting to obtain server status . . .
Attempting to obtain server status . . .
Attempting to obtain server status . . .
Error: Could not read error log /usr/local/pkgs/389_ds_components/389-ds-base-1.3.0.a1-nss_3_14-nspr_4.9.4/ds-base/var/log/dirsrv/slapd-localhost/errors to get server startup status. Error: No such file or directory
Could not start the directory server using command '/bin/systemctl start dirsrv@localhost.service'. The last line from the error log was 'no status'. Error: No such file or directory
Error: Could not create directory server instance 'localhost'.
Exiting . . .
Log file is '/tmp/setupl6Ozb6.log'

I will try to resolve with the hostname to be a FQDN, but meanwhile I want to ask if you could tell me something about the error above:
Failed to issue method call: Unit dirsrv at localhost.service (Unit dirsrv@localhost.service ) failed to load: No such file or directory.

I tried:

linux-6ytl:~ # systemctl status dirsrv@localhost.service
dirsrv at localhost.service
Loaded: error (Reason: No such file or directory)
Active: inactive (dead)
linux-6ytl:~ #
linux-6ytl:~ # systemctl status dirsrv at localhost
Failed to issue method call: Unit name dirsrv@localhost is not valid.
linux-6ytl:~ #

What configure flags did you use?
Does /usr/local/pkgs/389_ds_components/389-ds-base-1.3.0.a1-nss_3_14-nspr_4.9.4/ds-base/var/log/dirsrv/slapd-localhost/errors exist? If so, what are the permissions?

For 389-admin-1.1.30 I used the following command to configure it:
./configure --prefix=/usr/local/pkgs/389_ds_components/389-admin-1.1.30 --enable-debug --enable-rpath --enable-threading
--with-gnu-ld --with-httpd=/usr/local/pkgs/httpd-2.4.3_389_directory_server/bin/httpd
--with-nspr=/usr/local/pkgs/389_ds_depencences/nspr-4.9.4
--with-nss=/usr/local/pkgs/389_ds_depencences/nss-3.14_with_nspr_4.9.4
--with-openldap=/usr/local/pkgs/openldap-2.4.33_389_directory_server
--with-icu=/usr/local/pkgs/389_ds_depencences/icu4c-50_1
--with-adminutil=/usr/local/pkgs/389_ds_components/389-adminutil-1.1.14
--with-apxs=/usr/local/pkgs/httpd-2.4.3_389_directory_server/bin/apxs
--with-apr-config=/usr/local/pkgs/apr-1.4.6/bin/apr-1-config

File "/usr/local/pkgs/389_ds_components/389-ds-base-1.3.0.a1-nss_3_14-nspr_4.9.4/ds-base/var/log/dirsrv/slapd-localhost/errors" does not exist.

ok - what about 389-ds-base? What configure arguments did you use? I'm curious as to why it is attempting to use systemd?

For 389-ds-base I used this:
./configure --prefix=/usr/local/pkgs/389_ds_components/389-ds-base-1.3.0.a1-nss_3_14-nspr_4.9.4/ds-base
--enable-debug=yes --with-gnu-ld=yes
--with-systemdsystemunitdir=/usr/local/pkgs/389_ds_components/389-ds-base-1.3.0.a1-nss_3_14-nspr_4.9.4/confdirs/systemdsystemunitdir
--with-systemdsystemconfdir=/usr/local/pkgs/389_ds_components/389-ds-base-1.3.0.a1-nss_3_14-nspr_4.9.4/confdirs/systemdsystemconfdir
--with-instconfigdir=/usr/local/pkgs/389_ds_components/389-ds-base-1.3.0.a1-nss_3_14-nspr_4.9.4/confdirs/instconfigdir
--with-nspr=/usr/local/pkgs/389_ds_depencences/nspr-4.9.4
--with-nss=/usr/local/pkgs/389_ds_depencences/nss-3.14_with_nspr_4.9.4
--with-nss-inc=/usr/local/pkgs/389_ds_depencences/nss-3.14_with_nspr_4.9.4/include
--with-nss-lib=/usr/local/pkgs/389_ds_depencences/nss-3.14_with_nspr_4.9.4/lib
--with-openldap=/usr/local/pkgs/openldap-2.4.33_389_directory_server
--with-openldap-inc=/usr/local/pkgs/openldap-2.4.33_389_directory_server/include
--with-openldap-lib=/usr/local/pkgs/openldap-2.4.33_389_directory_server/lib64
--with-openldap-bin=/usr/local/pkgs/openldap-2.4.33_389_directory_server/bin
--with-svrcore=/usr/local/pkgs/389_ds_depencences/svrcore-4.0.4
--with-icu=/usr/local/pkgs/389_ds_depencences/icu4c-50_1
--with-netsnmp=/usr/local/pkgs/389_ds_depencences/net-snmp-5.7.2
--with-netsnmp-inc=/usr/local/pkgs/389_ds_depencences/net-snmp-5.7.2/include
--with-netsnmp-lib=/usr/local/pkgs/389_ds_depencences/net-snmp-5.7.2/lib64
--with-kerberos=/usr/local/pkgs/389_ds_depencences/krb5-1.10.3
--with-pcre=/usr/local/pkgs/389_ds_depencences/pcre-8.32

You only need to use systemd if you plan on installing 389 using operating system paths like /etc /usr etc. Otherwise, use --with-systemdsystemunitdir=no --with-systemdsystemconfdir=no --with-tmpfiles-d=no

You'll also need to specify those to build 389-admin

When you configure 389-admin, you will need to specify the same prefix as with ds-base

That worked for me. I also had to remove --with-instconfigdir option from 389-ds-base configure command as it was a problem with the schema folder and files being created in their default location instead of path in --with-instconfigdir.

I successfully run setup-ds-admin.pl and hope all goes easily from now on.

Thank you very much.

Hi Richard,
I have another problem starting 389-console.

I get the following error:
linux-6ytl:/usr/share/java # ./389-console
Error: Could not find or load main class com.netscape.management.client.console.Console

For building the console components I used a precompiled version of java: jdk1.7.0_09
The first time I wanted to start the 389-console the message was saying that it could not find main class com.netscape.management.client.console.Console and a backtrace was displayed on the screen. But then I changed the path to point to the right java package like this:
export PATH=/windows/SG_GoFlex_W2/Prjc/jdk1.7.0_09/bin:$PATH
and then I had no backtrace displayed, only the message above. I believe it can not load the console main class this time but I can not figure out how to solve this. I also set export JAVA_HOME=/windows/SG_GoFlex_W2/Prjc/jdk1.7.0_09/ but that was not solving my problem.

Searcing for "com.netscape.management.client.console.Console" in install location:
linux-6ytl:/usr/local/pkgs/389_ds_components/idm-console-framework-1.1.7/release/jars # grep -n -r "com.netscape.management.client.console.Console" *
Binary file idm-console-base-1.1.7.jar matches
Binary file idm-console-mcc-1.1.7.jar matches
linux-6ytl:/usr/local/pkgs/389_ds_components/idm-console-framework-1.1.7/release/jars #

Same result is for searching in /usr/share/java.
I must say that in /usr/share/java I performed:
linux-6ytl:/usr/share/java # ln -s 389-console-1.1.7_en.jar 389-console.jar
before installing 389-console. Making symbolic link
linux-6ytl:/usr/share/java # ln -s 389-console-1.1.7.jar 389-console.jar
was giving another not found exception (Exception in thread "main" java.lang.NoClassDefFoundError: com/netscape/management/nmclf/SuiLookAndFeel
) that I could get rid of it by linking against _en.jar version.

Can you give me a suggestion for solving this error?

Thank you,
Steve.

I found the problem. Just had to add path to Console.class file to 389-console script.

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/530

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.