I often run into the problem when I create an installer for my program that I miss out some files it depend on.
On Windows:
I often miss out some DLL's that are installed on my system. I usually test my installation by just moving the executable in a folder alone to see which DLL's it cry for. But it will use the DLL's it find on my system32 folder anyway - those DLL's maybe there in other users' system, maybe not.
Other way I found that I open the EXE in a hex editor and search for the pattern '.DLL'. But dll's can depend on other dlls too.
Is there a (preferably free) tool that can tell me what DLL's my program need? So I won't miss out anything.
On Linux:
Linuxes have a nice package management system. Making an installer in those systems means making a package for them. I can find out what .so (shared object) files my programs need. But how can I determine which package contains that .SO file so I can add that package as dependency when packaging?
On Windows, what you're looking for is a tool called Dependency Walker, which tells you what DLLs an EXE (or another DLL) depends on.
On Linux, see Dependency resolution in Linux
Related
I have a project (a PowerShell module) that relies upon a NuGet package, whose assemblies are loaded into my module via the Add-Type cmdlet. I would like to install this package via NuGet instead of manually copying it into the correct folder. This would save me from committing it's binaries to source control. Also: when thinking about CI/CD, I'd hate to have them in my repo.
I know I can curate a packages.config file and use nuget install instead. But this command installs the package together with it's dependencies into a separate folder and therefore the framework will (runtime) not find the required dependencies.
I know I could also provide a script that performs the nuget install and then copies the required .dll files into a single folder. But I would have to deal with the fact that the package might have different versions for different target frameworks and I'd need to handle the compatibility. Or maybe the package has other additional required files that I know nothing about.
So here my question: there has got to be a simpler way to do this? Something less ... circuitous and cumbersome?
When I create a Fortran project by Eclipse,
it includes bin and src directories.
The automatically created Makefile has a rule that compiles test.f90 in src and its runnable is written in bin.
I am a pretty new to Fortran.
What if test.f90 is supposed to be just an object which is required to compile an executable file, where should the object file, say test.o, be put? and when test.f90 has a module inside, where should the module test.mod be output? mod at the same level as src and bin. or share, lib?
In that case, when I should separate all intermediate file in several directories, are there any template Makefile?
It depends on what kind of Fortran project you created. If you created a Makefile project, you have full control/responsibility for where files are located. It appears to create a src and bin directory but beyond that, it looks like you can put other files like *.mod and *.o wherever you want. I'm not sure what the convention is for Fortran Makefile projects.
I prefer to avoid using Fortran Makefile projects because I have zero desire to manually sort out dependencies and targets with Makefiles, but that's a personal preference; if you're familiar with make and need the fine control it gives you, this is a reasonable choice. Just starting out with a Fortran Makefile project seems really painful unless you already know make.
A simpler, though less obvious to choose "File | New | Fortran Project | Others" when creating a Fortran project, then select the compiler and what you want to build. An example is "Executable (Gnu Fortran on Linux/*nix)" for building an executable with gfortran on a unix/linux-like system. Build targets include executables, static libraries, and shared libraries, each using gfortran, ifort, and a few other compilers, on Windows, OSX, or linux/Unix.
The src and bin directories are not automatically created but Makefiles are managed by Eclipse. Eclipse will automatically create a directory like Debug or Debug_Intel64 and place executables, *.o, and *.mod files within it. If you make your own src directory, object files will be placed under Debug/src but the executables and module files will be under Debug. This directory name changes if you create a Release build configuration (Debug is the default).
By default, Eclipse puts all new source files in the project root but you can create Fortran source folders and organize your project however you want. The downside of automatic build management is that Eclipse is really only set up to build one thing, so if your project contains multiple executables (e.g. separate unit test, utilities, etc.) you need to manually build with make, CMake, etc.
Eclipse takes some getting used to, but integration with Mercurial is pretty good, and the Photran plugin (part of the Parallel Tools Project) helps with source templates, code analysis & Fortran refactoring tools, and a reasonably decent UI for configuring the compiler (at least for ifort on Linux). Plus it's cross-platform and works with a lot of other languages so it's far from the worst choice, especially if you're using Photran.
If you're not sold on Eclipse, I'd look at some less heavyweight options. Eclipse can be a pain some times and you might find a better IDE for what you're doing. OTOH, Eclipse works fine and the Photran plugin has some really nice features.
For fortran beginners the best IDE is codeblocks
download the binaries with Mingw fortran compiler.
As your requirement it puts all your .mod and .o files to obj folder and executables in bin folder and source files are just used from the directory where they are.
We are migrating over to using packages and NuGet for managing our dependencies on 3rd party components. This works well when referencing packages from within Visual Studio or building on the build server via msbuild.
However there are a number of files that we would like to access in our build scripts and installers. Previously these would be in source control with a well known path, now as the version of the package that we are consuming changes so the path to the package and hence the files is changing.
Is there a simple way I can get the path to a given package? The best solution I currently have is to search for all packages.config files and extract the package version from them.
Examples of the files that we need to access are
The NUnit console executable from the NUnit.Runners package for running unit tests.
License files from various packages that we redistribute with our installer.
Using the packages.config file is a pretty good solution. NuGet itself uses two approaches:
Reading the package information from the packages.config and using that to resolve to the packages path.
Enumerating all the directories in the packages directory.
You could use NuGet.Core to do either of the above if you do not want to write the code yourself. The classes that can be used are the DefaultPackagePathResolver, the PackageReferenceFile and LocalPackageRepository or SharedPackageRepository.
One problem with the second approach is that sometimes NuGet may occasionally leave behind NuGet packages that are not necessarily referenced by a project. In that case looking at the package directories may give you the incorrect information.
The only other approach I can think of might be to read the project files looking for the assembly references. Although that would not work for a solution level package such as NUnit.Runners.
I was working on packaging my software and wondering how does the installation of JRE work. Does it simply copy the binaries on the local system and set the classpath accordingly or any other steps are done by the installer?
For windows the JRE binaries are stored in C:\Program Files\Java\jre7 can I copy this folder into some other machine(with same processor 32bit or 64bit) to make JRE work. If that is so then what are the environment variables that are needed to be set?
can I copy this folder into some other machine(with same processor 32bit or 64bit) to make JRE work
Yes, no problem. Unless you also want to register the .jar extension so that you can double-click them.
In that case check out the ftype and assoc commands. They can do that e.g. from within a batch file or installer.
If that is so then what are the environment variables that are needed to be set?
No need to set any environment variable.
Just make sure you qualify the path to javaw.exe (or java.exe) correctly when starting your application (e.g. through a batch file).
You can put the whole JRE in a sub directory and just reference java.exe based on the sub directory. This is done quite frequently by other products.
You don't need to set any Environmental variables.
Update
If this is a commercial application that is not a JRE toolkit (i.e. something like Maven or Ant) do not rely on the global Environmental variables JAVA_HOME, PATH or CLASSPATH to be set. If you want to create a batch file that when ran, automatically sets that in the context of your application, that'll work fine. But do not rely on them to be set in the System.
All it will take is for someone to change these to use some version of 1.7, or 1.8 beta, or really any sub-version of the JRE to break your application and then you'll get Customer Support calls about your application breaking, when really what they did was change their JAVA_HOME to something absurd because they misread the Ant documentation.
If you are providing a toolset that works in conjunction with the JDK, such as Ant or Maven, you'll probably want to use whatever JRE/JDK they have installed as that is the point of your tools.
If you don't specify any argument, the JRE installer install the needed binary and executable files, but also creates the needed windows registry entries to configure your JRE installation.
You can also install using the "-static" option (see the JRE installer documentation) in which case doesn't do anything else but copying the files to the specified path.
Then you'll need your environment variables manually. For the command-line, the most common ones are: PATH, JAVA_HOME and CLASSPATH.
The short version is, it depends. But for the most part, the constraints of binary compatibility and library paths are sufficient to get the JRE working in shared environments (as we do in some of our machines at work).
Because Java provides a virtual machine to handle requests, and because it can do so fairly independently of some of the other bells and whistles owned by the system, your intuition about its classpath and binary disposition holds true. However, you may run into problems with libraries that expect a well-formed and system-specific set of paths and libraries, which are afforded in some of the OS packages provided by third-party libraries.
In short: if you have the option to, install Java from its installer, because this will guarantee all classpath details, all libraries, all logging facilities, and all system-specific errata are accounted for, though as Andrew Finnell points out, you'll still need to set the environment variables manually. Only a strict subset of these are required for most needs (see the other answers), but it's the corner cases that are most interesting when bounding this class of problem.
Can I have a Library defined that makes use of JNI in NetBeans?
Seems the library definition only allows Jars or Folders.
How can I assure that the DLL follows the jar file when the app is built?
Assuming you are referring to building a NetBeans Platform App (or module), then you can place the DLL in the "release/modules/lib/" folder. This is per the platform FAQ:
http://wiki.netbeans.org/DevFaqNativeLibraries
Additional information here:
http://bits.netbeans.org/dev/javadoc/org-openide-modules/org/openide/modules/doc-files/api.html#jni
If you are asking more generally, then I think most people package the DLL inside the jar, then extract it to a temp location upon application startup. e.g.
How to make a JAR file that includes DLL files?
If that's not what you're looking for, then you'll need to provide more information as to what you're trying to do.
netbeans won't do it on its own, but since it uses ant behind the scenes there's a workaround.
you should create a subdirectory named jni in your project directory (c:\path\to\mynetbeansproject\jni), put all the .dll, .so and .jnilib files in there (the native stuff), and add the following lines to the build.xml file you find in your project directory, just before the </project> tag:
<target name="-post-compile">
<copy todir="${dist.dir}/lib">
<fileset dir="jni" />
</copy>
</target>
then add the jar file to your project just like you always do. :)
the snippet you inserted in build.xml will make sure that the native libraries follow your jar files in the dist/lib folder when you invoke "Clean and Build" from within netbeans (or ant from the command line); the jvm will look for the .dll (.so, .jnilib) files in the same directory as the .jar that's loading them, so it will work.
note that this won't make your project run from within netbeans, because… I'm not really sure what goes on, but it looks like the library path (LD_LIBRARY_PATH) doesn't include your projects' libraries, and there's no way I know of changing it from within netbeans. just put your native libraries in /Library/Java/Extensions on mac os x, or just stash them in c:\windows\system32 under windows. if you're running a 64 bit windows with a 64 bit jvm, I have no clue; if you're running linux, you probably know where to stash them, but /usr/lib/java might be a good bet.
I tested the following solution while using NetBeans 7.0.1 and it worked, but I don't know if it works in early versions, too.
The solution is easy and works per NetBeans module. So, if you have a suite, don't place its JNI files into suite project, instead, place the JNI files that you want into the module itself. Do:
Find a NetBeans module project that you want (or need, or think) to place your JNI libraries (them with extension .DLL, .so and .jnilib, by eg);
At Projects, right click at the module node, click at Properties menu;
In the Project Properties dialog, click at Libraries and Wrapped JARs. You must add any external library there. I added the RxTX jar library. After add your external libraries, the Netbeans Ant script will copy all files/folders from the directory your_project_dir/release to the right location when you build the solution.
So, place your native libraries at your_project_dir/release/lib. If you want, you can create subdirectories for each target platform that you need, as: your_project_dir/release/lib/amd64, your_project_dir/release/lib/sparc32
To know, more, read:
http://bits.netbeans.org/dev/javadoc/org-openide-modules/org/openide/modules/doc-files/api.html#jni
Regards,
marciowb.info