Support for extracting shared library companion objects #490
Conversation
|
Hi, Wouldn't it be enough to change the method extracting *.dll or *.so from the JAR? I'm not very familiar with the native tools, but my assumption is that if gdb/pdb is extracted in the same directory as dll and has the same name (except the extension), the debugger will pick it automatically? I'm I correct? If this is the case, it should be enough to change this method from static File extractEmbeddedLibraryResource(String name) throws IOException {
// code
}So it extract gdb/pdb files along with the library and put them in the same directory. Just my two cents. |
|
Hi I experimented a bit, and I got a working solution. However its not every flexible as it has the hardcoded pdb and gdb extensions in them. I basically added the static File extractEmbeddedResource(String libraryResource) throws IOException {
InputStream in = getResourceAsStream(libraryResource);
if (in == null) {
File f = new File(libraryResource);
if (!f.exists()) {
f = new File(f.getName());
}
if (f.exists()) {
return f.getCanonicalFile();
} else {
return null;
}
}
int len;
byte[] b = new byte[8196];
String fileName = new File(libraryResource).getName();
File libFile = new File(extractedLibrariesTempDir, fileName);
OutputStream out = new BufferedOutputStream(new FileOutputStream(libFile));
while ((len = in.read(b)) > 0) {
out.write(b, 0, len);
}
out.close();
in.close();
addTemporaryExtractedLibraryFileToDeleteOnExit(libFile);
addTemporaryExtractedLibraryFileToDeleteOnExit(libFile.getParentFile());
return libFile;
}
static File extractEmbeddedLibraryResource(String name) throws IOException {
String firstLibraryResource = null;
List<String> libraryResources = getEmbeddedLibraryResource(name);
if (BridJ.veryVerbose) {
BridJ.info("Library resources for " + name + ": " + libraryResources);
}
for (String libraryResource : libraryResources) {
if (firstLibraryResource == null) {
firstLibraryResource = libraryResource;
}
File libFile = extractEmbeddedResource(libraryResource);
// Check if the resource was successfully extracted
if (libFile != null) {
// Try an extract debug symbols
String basePath = libraryResource.substring(0, libraryResource.lastIndexOf('.'));
extractEmbeddedResource(basePath + ".pdb");
extractEmbeddedResource(basePath + ".gdb");
// Return the extracted shared library
return libFile;
}
}
return null;
}I guess it should be decided if this is good enough, or a more flexible solution is required before I start making a pull request. Perhaps a similar method to |
|
Hi @AODtorusan , @sarxos , Sorry for the delay! Cheers |
|
Hi @ochafik I've only really used the visual studio debug files (as I generally develop in windows), but I generate the gcc symbol file similar to the cmake process here:
I've also converted this issue into a pull request implementing this feature. |
Hi,
It would be nice if BridJ would not only extract the shared libraries, but also there companion files (files on which the library could depend). This would allow shipping/extracting additional debug symbols (pdb or gdb files) in the jar which would then be picked-up automatically by debugging tools.
For example extract both lib/win32/myLibrary.dll and lib/win32/myLibrary.pdb.
I'm willing to take a stab at this feature, but at first glance it would require some large changes in the Platform class. Any ideas or opinions on this?
Simon