I get this cryptic message when linking my code on AIX:
ld: 0711-788 SEVERE ERROR: Object /dir/libxx.so, RLD address 0x5106 in section 1:
The fixed-up instruction at address 0x5104 is not a branch.
Its opcode is 14.
If I'm reading the docs correctly, RLD is a relocation entry, but I would definitely appreciate a clarification if I'm incorrect.
A Google search turns up this particular page but it's just a listing of error messages that's possible within ld.
This error was caused by different AIX versions on the machine.
libxx.so was compiled on an AIX machine # 5.3 TL12 SP3.
Our machine doing the linking had AIX # 5.3 TL8 SP4
Once we upgraded our machine doing the linking to the latter technical level, everything was fine.
Thanks again for all the suggestions everyone!
Related
I am trying to build Nmap from source code, and I think I am incorrectly installing/compiling/using OpenSSL, but I'm not sure it is the first time using many of the tools found in the instructions for nmap compilation.
I follow the instructions here: https://nmap.org/book/inst-windows.html#inst-win-source
I follow everything, including the instructions found at https://svn.nmap.org/nmap-mswin32-aux/OpenSSL-upgrade.txt; which is required since the OpenSSL folder that comes with the nmap source distribution does not include some header files from configuring OpenSSL.
I can build every project within the solution up until nsock, in total I get about 3700 errors. For nsock its 435 errors, things like:
"sslctx is not a member of npool"
"ssl_session is not a member of niod"
but also things like "syntex error: missing ; before *"
My directory looks like nmap -> [nmap-7.93, nmap-mswin32-aux]
Pretty sure it has something to do with how I'm installing or building or using OpenSSL, but I follow the instructions https://svn.nmap.org/nmap-mswin32-aux/OpenSSL-upgrade.txt closely and multiple times now.
I'm using MSVC 2022, I have 2019 installed (I'm really not sure which to use, or how to stop perl from using 2022 and use 2019 tools), or if I'm missing something else that is basic.
I did notice perl uses nmake from MSVC2022, and it's mentioned on the nmap site to use 2019. Could this be the problem? How would I get pearl to use MSVC2019 to test it out?
I followed the instructions multiple times, with both openssl sources 1.1.1s and 3.0.7 in MS VS 2019 and 2022. The result is all up 3700 errors about syntax errors and being unable to identify ssl names.
Happy to provide any additional info like perl dump files if anyone can aid me, or the complete list of errors. Any help would be greatly appreciated.
I have some code using an old perl version on a live server and I want to get it working on a new activestate installation on my laptop. I am getting an error message complaining about Win32::NetResource not being there. I have tried to locate it on activestate, but have failed. The current version is 5.34 but the working system that presumably has the module is on 5.26.
Another server with a recent starawberry perl doesn't have the module either - worried that it might not be supported any longer.
I have Postgres version 10 installed running under windows 10 enterprise using the pl/r interface. It has been working nicely up till now. Now I get
ERROR: could not load library "C:/Program Files/PostgreSQL/10/lib/plr.dll": %1 is not a valid Win32 application.
error message. I tried to download and replace the Pl/r files (both the 64bit and the 32 bit versions), stopped/restarted the service, but it did not help. Any suggestions?
I found the cause: Rdotnet needed the 32bit version of R and I changed the path (and forgot all about it). The error message was misleading, because it R had the wrong version, not the plr.dll. (if I copied the 32bit version od the dll it still didn't work). So thanks for trying to help.
I have Installed and worked with MemSQL on Ubuntu 12.04 and CentOS 6. But I am doing a fresh install on CentOs 6.4 (FInal). When running ./check_system script I am getting the following error.
Warning: The number of allowed open file descriptors should be at least 64000. This OS is currently configured with the limit set to 1024. Please visit http://developers.memsql.com/docs/2.5/admin/admin_concepts.html#configuring-the-linux-file-descriptor-limit
./check_system: line 313: 6173 Illegal instruction (core dumped) $SCRIPT_DIR/lib/check_crc32 > /dev/null 2> /dev/null
Warning: SSE4.2 is not supported. Resorting to software CRC32C. MemSQL recovery and log writing performance will be negatively impacted.
I am familiar with the warning and I know how to fix it. its the Illegal instructions error I am trying to understand.
Any help in this regard will be useful.
For the file descriptor warning, you can either read that link, or simply use the rpm or deb package to install - both of these will configure that limit for you.
The warning about SSE4.2 is not a fatal warning - the server will run fine, generally with single-digit percentage slowdown to insert and update queries.
Read, Installation Best Practices HOWTO:
http://docs.memsql.com/latest/setup/best_practices/#increase-file-descriptor-limit
Also try restart svr
Following is the error I am getting when I tried 'git svn rebase':
Byte order is not compatible at ../../lib/Storable.pm (autosplit into ../../lib/auto/Storable/_retrieve.al) line 380, at /usr/lib/perl5/5.10/Memoize/Storable.pm line 21
The version of perl I am running is:
$ perl --version
This is perl, v5.10.1 (*) built for i686-cygwin-thread-multi-64int
(with 12 registered patches, see perl -V for more detail)
When I searched the web for "Byte order is not compatible" and I get numerous hits that shows the Perl doc that says:
What this means is that if you have
data written by Storable 1.x running
on perl 5.6.0 or 5.6.1 configured with
64 bit integers on Unix or Linux then
by default this Storable will refuse
to read it, giving the error Byte
order is not compatible. If you have
such data then you you should set
$Storable::interwork_56_64bit to a
true value to make this Storable read
and write files with the old header.
You should also migrate your data, or
any older perl you are communicating
with, to this current version of
Storable.
What I don't know is, how to set this '$Storable::interwork_56_64bit' to true. Can you please let me know how to do it?
I started getting this error message. I'm using a git repository that lives in a Max OS X partition. I sometimes access it from OS X (64 bit), and sometimes access it from a VM that's running a 32 bit version of Linux. It looks like there's a cache file that is stored in a machine-dependent format.
After doing some digging, I believe you can work around the error by blowing away all of the .db files stored in .git/svn/.caches. This should be a slightly more surgical approach than blowing away the entire svn directory.
This happened to me recently on my Mac. I'm not sure what caused it, but the standard git-svn "fix" of blowing away the metadata and updating worked for me:
% mv .git/svn .git/svn.bak
% git svn fetch
Migrating from a git-svn v1 layout...
Data from a previous version of git-svn exists, but
.git/svn
(required for this version (1.7.1) of git-svn) does not exist.
Done migrating from a git-svn v1 layout
Rebuilding .git/svn/refs/remotes/bg-threads-1.1/.rev_map.a5d90c62-d51d-0410-9f91-bf5351168976 ...
r5758 = 545e176a13e87d44a2750ff5f06959088efc9e5b
...
I suspect one potential cause of this is using a git repository with svn data that's been fetched on one machine and then subsequently archived up and downloaded for use on another machine.
In my case it was fetched on CentOS and then transplanted to an Ubuntu machine - both 64-bit installs but perhaps some little detail of their Perl configuration is different. Or perhaps a package update changed something.