is UPX able to pack Dylibs? - objective-c

is UPX able to pack Dylibs ? it works very well with Mac Os X application executables, but I cannot make it pack a dylib it throws an UnknownExecutableFormatException exception. Nevertheless I can see a lot of references to dylibs in the mach-o part of upx source code. Any hints ? Thanks a lot.

It was possible on older versions of UPX if the dylib included an init or load command (eg. LC_ROUTINES). The developers withdrew this one version later though due to other unforeseen issues with trying to pack dylibs. So to answer your question, yes it is possible, but only under certain cirumstances, and not recommended.
Changes in 3.05 (27 Apr 2010):
...
* Withdraw support for shared libraries on Darwin (Apple Mac OS X)
because upx does not understand enough about .dylib.
..
Changes in 3.04 (27 Sep 2009):
...
* new formats Dylib/i386 and Dylib/ppc32 support shared libraries
[such as browser plugins] on Darwin (Apple Macintosh). An existing
-init function (LC_ROUTINES command) is required.
...

Related

Library not loaded: #rpath/libtbb.dylib in Prophet / Python

I'm on a Mac X1, Monterey.
I've installed prophet and run into this issue when trying to fit a model.
RuntimeError: Error during optimization: console log output:
dyld[90668]: Library not loaded: #rpath/libtbb.dylib
Referenced from: /Users/{username}/opt/anaconda3/lib/python3.9/site-packages/prophet/stan_model/prophet_model.bin
Reason: tried: '/private/var/folders/cd/dfrqgp4s4ll55cwb7rtgccbw0000gq/T/pip-install-rjpuj450/prophet_d7e4cce10e414c89a572fe3605ae9269/build/lib.macosx-11.1-arm64-cpython-39/prophet/stan_model/cmdstan-2.26.1/stan/lib/stan_math/lib/tbb/libtbb.dylib' (no such file), '/private/var/folders/cd/dfrqgp4s4ll55cwb7rtgccbw0000gq/T/pip-install-rjpuj450/prophet_d7e4cce10e414c89a572fe3605ae9269/build/lib.macosx-11.1-arm64-cpython-39/prophet/stan_model/cmdstan-2.26.1/stan/lib/stan_math/lib/tbb/libtbb.dylib' (no such file), '/usr/local/lib/libtbb.dylib' (no such file), '/usr/lib/libtbb.dylib' (no such file)
I know this has to do with the wrong paths being searched. I can find the dylib in
/Users/{user}/opt/anaconda3/lib/python3.9/site-packages/prophet/stan_model/cmdstan-2.26.1/stan/lib/stan_math/lib/tbb/
But, it seems prophet doesn't know to look there. I'm curious how I can update/fix either the rpath variable or find another solution?
I tried to create a symbolic link with sudo ln -s, but don't have permissions on the laptop.
TIA!
I got it to work on Apple Silicon (M1 Max in my case) by installing older versions of both pystan and prophet:
pip install pystan==2.19.1.1
pip install prophet==1.0
The other important piece of the puzzle is that you should use Python 3.8 to get it working.
Installing older versions of the libraries and using Python 3.8 are both talked about in issue #2002 on Github, but there's not really an explanation of the libtbb.dylib error message.

Migrating Java 1.8 version to Java 17

While building the code getting package sun.security.action is not visible
Package sun.security.action is declared on module java.base, which does not export it to the unnamed module.
What should I do.
Kindly advice, Thanks in advance
Java 8 had no module system - everything is visible or just needs to get imported by archives in jdk (f.e. tools.jar).
Java 9 brought JMS and encapsulated some jdk classes.
In your case, see <JAVA_HOME>/lib/src.zip!/java.base/module-info.class:
exports sun.security.action to
java.desktop,
java.security.jgss,
jdk.crypto.ec,
jdk.incubator.foreign;
Your package isn't public but restricted to some other internal packages/modules.
There was a workaround by adding compiler option --add-exports=java.base/sun.security.action=ALL-UNNAMED at compile time to fix this limitation until version 16.
With version 17 and JEP 403 forget all hope:
It is not a goal to define new standard APIs to replace internal elements for which standard replacements do not yet exist, though such APIs could be suggested in response to this JEP.
Backwards compatibility and important frameworks have lower priority than jdk security - JCP makes strange decisions and works against the community sometimes -.-

Unable to load dynamic library php_sqlsrv_7_nts.dll is not a valid Win32 application

Thought I'd see if there were any sql server drivers for php 7. Another question on Stack Overflow pointed me to these drivers here
So I install php_sqlsrv_7_nts.dll into my ext folder and add the following line to my php.ini:
extension=php_sqlsrv_7_nts.dll
I get this warning on every php script I run:
Warning: PHP Startup: Unable to load dynamic library 'C:\php7\ext\php_sqlsrv_7_nts.dll' - %1 is not a valid Win32 application
I realise this is just a pre-release version and there are many things to iron out still, but I was hoping to at least do some basic things.
What am I doing wrong, or do I need to wait a bit more for a better release.
Some info that might be useful:
PHP Version => 7.0.5
System => Windows NT GB275L-I-T-5654 6.3 build 9600 (Windows 8.1 Professional Edition) i586
Build Date => Mar 30 2016 09:57:56
Compiler => MSVC14 (Visual C++ 2015)
Architecture => x86
Configure Command => cscript /nologo configure.js "--enable-snapshot-build" "--enable-debug-pack" "--disable-zts" "--with-pdo-oci=c:\php-sdk\oracle\x86\instantclient_12_1\sdk,shared" "--with-oci8-12c=c:\php-sdk\oracle\x86\instantclient_12_1\sdk,shared" "--enable-object-out-dir=../obj/" "--enable-com-dotnet=shared" "--with-mcrypt=static" "--without-analyzer" "--with-pgo"
Finally got this solved. Needed to install some more things before it would work, namely:
Microsoft Visual C++ 2015 Redistributable (x86) which you can get from here
The ODBC drivers which you can get from here
It works for me.
1.Download the extension windows 7.0
https://github.com/Microsoft/msphpsql/releases
2.And then according to the system requirement paste it in ext folder.
Note: Paste only the thread safe version (php_pdo_sqlsrv_7_ts.dll , php_sqlsrv_7_ts.dll)
3.And edit the php.ini file add this extension to your php.ini file and restart and check
The extension file from Github MSPHPSQL releases did not work for me and gave me the same predicament with the OP. I went to this Microsoft article which gave me the driver (extension) for MSSQL Server, go ahead and install it on a directory you can easily find, in my case I saved it in my c:\mssql-driver then inside get the extension (DLL) file that fits your OS and PHP version, in my case since I am using PHP 7.2.x and x64 Windows I picked the following file and put it in my PHP extension directory c:\xampp\php\ext:
php_pdo_sqlsrv_72_ts_x64.dll
php_sqlsrv_72_ts_x64.dll
and in my php.ini located in c:\xampp\php\php.ini defined it under the Dynamic Extensions section:
;;;;;;;;;;;;;;;;;;;;;;
; Dynamic Extensions ;
;;;;;;;;;;;;;;;;;;;;;;
...
extension=curl
extension=php_pdo_sqlsrv_72_ts_x64.dll
extension=php_sqlsrv_72_ts_x64.dll
...
delete the "php_" on "php_sqlsrv_7_nts". just write "sqlsrv_7_nts"

Using incr-tcl with version 8.4.19

Is it possible to use incr-tcl when working with tcl version 8.4.19?
Which include packages are required?
Until now we used Active-Tcl version 8.6, which came with incr-tcl built-in. Now we need to support stations that only have version 8.4.19 installed, and I want to know whether there's a technological roadblock or if it's just a matter of installing and referencing additional packages.
It's most certainly possible to have [incr Tcl] working with the Tcl 8.4 series.
bash$ tclsh8.4
% puts [info patchlevel]
8.4.7
% package require Itcl
3.3
% puts $itcl::patchLevel
3.3b1
You might prefer a slightly different version, but that combination works on my system (OSX Leopard).

Understanding a Bugfix for building Valgrind from source

I am trying to build Valgrind from source and ran into the same problem other's have before me. The proposed solutions where all quite hacky, though, which is not the way I like to do things.
I also found something in the Ubuntu bugtracker for the Valgrind package:
Proposed fix:
valgrind (1:3.7.0-0ubuntu2) precise; urgency=low
* Allow glibc 2.15 in the configure checks. (LP: #934127)
- Add 0009-glibc-215.patch, cherry-picked from upstream.
- Add 0010-automake-1.11.2.patch by Gregorio Guidi.
- Use dh-autoreconf instead of autotools-dev.
-- Felix Geyer <email address hidden> Fri, 17 Feb 2012 12:14:44 +0100
This was accepted as fix for the bug, so I figured it might be the real solution.
Yet I can't apply it just like that.
what means cherry-picked from upstream?
Neither searching in google nor in the downloaded source package found these patch files.
Also the last point Use dh-autoreconf instead of autotools-dev is not clear to me.
Can someone translate the solution into a more applicable form?
The easiest way would be to see if you can install the corresponding version through your package manager. If you really need to build it yourself, you will find the mentioned patches e.g. in the [..].debian.tar.gz archive.
If you look into the Ubuntu tracker, you will find:
diff -Nru valgrind-3.7.0/debian/patches/0009-glibc-215.patch valgrind-3.7.0/debian/patches/0009-glibc-215.patch
--- valgrind-3.7.0/debian/patches/0009-glibc-215.patch 1970-01-01 01:00:00.000000000 +0100
+++ valgrind-3.7.0/debian/patches/0009-glibc-215.patch 2012-02-17 12:14:29.000000000 +0100
## -0,0 +1,30 ##
+Description: add support for glibc 2.15
+Origin: upstream, http://sourceforge.net/mailarchive/forum.php?thread_name=20111229082456.D5FE6108870%40jail0086.vps.exonetric.net&forum_name=valgrind-developers
+
+Modified: trunk/configure.in
...
The SourceForge URL above tells you that this patch was committed in r.12323 to the Valgrind repo.
(The last remark about the autotools is specific to the Debian package building process, and has most likely nothing to do with your problem.)