Closed GoogleCodeExporter closed 8 years ago
Hi,
I have some further information on what the issue seems to be on AIX. AIX uses
the XCOFF binary format instead of ELF. As a result, it looks like the symbols
being referenced by your program are specific to ELF object files. I'm doing
some research right now to find out how to add the necessary symbols to the
auxiliary symbol table. Alternatively, I may try to compile SIAB with some
minor modifications to the symbol names.
Regards,
Mike
Original comment by reinhol...@gmail.com
on 30 Sep 2011 at 12:55
Ok, I've done some further testing. The first piece that I have identified is
that the Makefile does not have a case specified for Power / AIX. I added the
following line in the objcopyflags to the makefile in order to get the objcopy
to create the correct output file.
{{{
rs6000) echo '-O aixcoff-rs6000 -B power -v';; \
}}}
Additionally, the symbols created by the objcopy on AIX seem to be prefixed
with _binary_shellinabox_ instead of _binary_. I have attempted to adjust the
symbol rename parameter from
{{{
-e 's/^/--redefine-sym _binary_/' \
}}}
to
{{{
-e 's/^/--redefine-sym _binary_shellinabox_/' \
}}}
However, when I view the contents of the object files which are the result of
the objcopy command, the symbol names in the COFF symbol table at the end of
the file still have the full object name.
I'm doing additional research to see if I can identify the cause of this.
Regards,
Mike
Original comment by reinhol...@gmail.com
on 30 Sep 2011 at 3:33
Hi,
After some further testing, I found that the changes to the objcopy command
were unnecessary. The object files created by objcopy now have the proper
symbols exported. Unfortunately, I am still running into an issue with the
severe linker error. I believe that this is due to the AIX linker having
tighter symbol table requirements than the GNU linker. I am currently working
with IBM support and the AIX community to see if there is a resolution from
that end. In the meantime, is there anything else that you can do from your end
to assist with the compilation? Alternatively, would it be possibly to create a
build which does not require these resources to be built in to the executable?
This build would have to read in the resource files into the storage allocated
by the program instead of copying from the compiled resources. If you would be
willing to make this version of Shell In a Box, I would be most appreciative.
If you are unable to for any reason, I may try to do so myself (although, this
will probably take longer than if you were to do so) and then submit it back to
you for your review.
Regards,
Mike
Original comment by reinhol...@gmail.com
on 3 Oct 2011 at 1:14
I suspect that this is the same problem we've seen on other platforms. The
autotools have been updated and should fix build problems like this.
Original comment by beewoo...@gmail.com
on 31 Mar 2012 at 10:50
Original issue reported on code.google.com by
reinhol...@gmail.com
on 29 Sep 2011 at 3:28