Porting an SDK Build Environment from a Release Prior to 9.6

Beginning in Junos release 9.6 of the SDK, a number of paths in the build environment changed.

These paths are now set by the SDK installation process, but you must include environment variables to reference them. This topic gives some background on the reason for the changes, and provides a checklist you can follow to modify your environment.

Background: Preventing Address Collisions

In previous releases, SDK packages were mounted in /packages/mnt/package-name/* upon installation, and symlinks were created in /opt/sdk/* or /opt/sbin/*. The decision on whether the files should reside in /opt/sdk or /opt/sbin was up to the owner of the application's manifest. In general, files for RE SDK applications were kept in /opt/sbin, whereas files for Services SDK applications resided in /opt/sdk.

When two different packages A and B, from two different providers, were installed on the same router, the packages were mounted at /packages/mnt/A/* and /packages/mnt/B/*. The symlinks were created in /opt/sbin/*. If both A and B contained an application with the same name (AppC) and the manifest entries said it should be stored in /opt/sbin/*, the two applications with the same name would go to the same location /opt/sbin/AppC, causing a collision.

To address this problem, Release 9.6 creates provider-prefix-specific directories for the symlinks. For example, if package A comes from a provider with provider prefix "companyA" and package B comes from a provider with provider prefix "companyB", the symlinks are now created as follows:

AppC is stored in /opt/sdk/company-A/opt/sbin/AppC rather than /opt/sdk/companyA/AppC because the manifest entry is store=/opt/sbin/AppC. This means that the system prefixes /opt/sdk/provider-prefix to the store= value from the manifest.

The actual mount points are unchanged; only the symlinks have a provider-specific prefix.
The /var/run/ext and /var/log/ext directories also change to /var/run/ext/provider-prefix and /var/log/ext/provider-prefix to avoid file collisions in these directories.

Porting Checklist

Complete the following tasks to modify your build environment for the naming conventions.

These changes in naming conventions apply only to the Routing Engine component of an application; you do not need to modify anything in the environment on the Multiservices PIC.
In the following steps:

Modify the libnames Makefile

Edit sandbox/src/build/mk/libnames.mk as follows:

LIBJNX-ROUTESERVICE-ODL = ${OBJTOP}/lib/odl/xmltags/libjnx-routeservice-odl.a


LIBJNX-ROUTESERVICE-ODL = ${OBJTOP}/lib/odl/xmltags/lib${PROVIDER_PREFIX}-routeservice-odl.a

LIBJNX-ROUTESERVICE-DD = ${OBJTOP}/lib/ddl/feature/lib${PROVIDER_PREFIX}-routeservice-dd.so.1

Copy Additional System Makefiles

Copy the files bsd.libnames.mk, bsd.init.mk, and provider.prefix.mk from the backing sandbox to your sandbox/src/build/mk directory.

Modify the DDL and ODL Makefiles

Edit sandbox/src/lib/odl/input/*.input.mk and sandbox/src/lib/ddl/input/*.input.mk to:

For example, the following diff output shows changes to the jnx-gateway sample application's ODL makefile to migrate it to the 9.6 release. The provider prefix that was hard coded as jnx is replaced by the ${PROVIDER_PREFIX} variable:


retrieving revision 1.1

diff -u -p -r1.1 jnx-gateway-mgmt.input.mk
--- jnx-gateway-mgmt.input.mk   25 Apr 2007 12:05:50 -0000      1.1
+++ jnx-gateway-mgmt.input.mk   2 Mar 2009 23:01:07 -0000

+.include <provider-prefix.mk>
 # the name assigned to the desired features
-INPUT_FEATURES += jnx-gateway-mgmt

 # the definitions for each feature
-jnx-gateway-mgmt_INPUT_FILES = \
+${PROVIDER_PREFIX}-gateway-mgmt_INPUT_FILES = \

Modify the Manifest

Edit the manifest in sandbox/src/release to add the PROVIDER_PREFIX and INSTALLDIR variables. For example, the manifest for the ifinfod example before porting is:

%TOPDIR%/lib/odl/xmltags/libjnx-ifinfo-render.so.1 store=opt/lib/render/libjnx-ifinfo-render.so mode=444
%TOPDIR%/lib/ddl/feature/libjnx-ifinfo-dd.so.1 store=opt/lib/dd/libjnx-ifinfo-dd.so mode=444
%TOPDIR%/sbin/jnx-ifinfod/jnx-ifinfod store=opt/sbin/jnx-ifinfod mode=555 program_id=1
%TOPDIR%/lib/ddl/feature/jnx-ifinfo.dml store=opt/lib/dd/jnx-ifinfo.dml mode=444 no_copy

After porting, the manifest is:

%TOPDIR%/lib/odl/xmltags/lib\%PROVIDER_PREFIX%-ifinfo-render.so.1 store=opt/lib/render/lib\%PROVIDER_PREFIX%-ifinfo-render.so mode=444
%TOPDIR%/lib/ddl/feature/lib\%PROVIDER_PREFIX%-ifinfo-dd.so.1 store=opt/lib/dd/lib\%PROVIDER_PREFIX%-ifinfo-dd.so mode=444
%TOPDIR%/sbin/jnx-ifinfod/jnx-ifinfod store=\%INSTALLDIR%/opt/sbin/jnx-ifinfod mode=555 program_id=1
%TOPDIR%/lib/ddl/feature/jnx-ifinfo.dml store=opt/lib/dd/\%PROVIDER_PREFIX%-ifinfo.dml mode=444 no_copy

Modify the Application Makefile

Add CFLAGS paths in the application makefile for the ODL, sequence, and application output files. The paths use variables that follow the pattern:


For example, the flags are as follows in the makefile for the jnx-ifinfod sample application:

CFLAGS += -DJNX_IFINFOD_ODL_H="<xmltags/${PROVIDER_PREFIX}-ifinfo_odl.h>"
CFLAGS += -DJNX_IFINFOD_OUT_H="<feature/${PROVIDER_PREFIX}-ifinfo_out.h>"
CFLAGS += -DJNX_IFINFOD_SEQUENCE_H="<feature/${PROVIDER_PREFIX}-ifinfo_sequence.h>"

For the jnx-exampled sample application, the same flags look like this:

CFLAGS += -DJNX_EXAMPLED_ODL_H="<xmltags/${PROVIDER_PREFIX}-example_odl.h>"
CFLAGS += -DJNX_EXAMPLED_OUT_H="<feature/${PROVIDER_PREFIX}-example_out.h>"
CFLAGS += -DJNX_EXAMPLED_SEQUENCE_H="<feature/${PROVIDER_PREFIX}-example_sequence.h>"

Modify Application Source Files

Edit all include statements for all *_odl.h, *_out.h, and *.sequence.h to use the variable added in the makefile.

For example, diff output for the for the jnx-ifinfod_config.c file in the jnx-ifinfo sample application is as follows:

-#include <feature/jnx-ifinfo_out.h>
-#include <feature/jnx-ifinfo_sequence.h>

Modify the Daemon Control Table

Modify the daemon's XML file to include the <binary> tag under the <daemon-entry> tag. For example, add the following in the daemon XML for jnx-example:


For more information about this file, see Updating System Tables to Describe Your Application.

Modify Hard-Coded Paths

To port hard-coded paths in your applications (for example, /opt/sbin or /opt/lib), you can use the following functions in libprovider, at sandbox/src/junos/lib/libprovider/h/jnx/provider_info.h in your backing sandbox:

Return to Build and Packaging Procedure
2007-2009 Juniper Networks, Inc. All rights reserved. The information contained herein is confidential information of Juniper Networks, Inc., and may not be used, disclosed, distributed, modified, or copied without the prior written consent of Juniper Networks, Inc. in an express license. This information is subject to change by Juniper Networks, Inc. Juniper Networks, the Juniper Networks logo, and JUNOS are registered trademarks of Juniper Networks, Inc. in the United States and other countries. All other trademarks, service marks, registered trademarks, or registered service marks are the property of their respective owners.
Generated on Sun May 30 20:26:47 2010 for Juniper Networks Partner Solution Development Platform JUNOS SDK 10.2R1 by Doxygen 1.4.5