GCC ident strings

Posted on by
Reply

I just needed to get the GCC version a binary was build with, it’s included in the .comment section and there’re quite a few ways to obtain it:

  • objdump

$ objdump -s -j.comment $BINARY

main.o:     file format elf64-x86-64
Contents of section .comment:
0000 00474343 3a202855 62756e74 7520342e  .GCC: (Ubuntu 4.
0010 332e332d 35756275 6e747534 2920342e  3.3-5ubuntu4) 4.
0020 332e3300                             3.3.

  • strings

$ strings -a $BINARY | grep GCC

GCC: (Ubuntu 4.3.3-5ubuntu4) 4.3.3

  • grep

$ grep -aoE 'GCC:[]a-zA-Z0-9:()., -[]+' $BINARY

GCC: (Ubuntu 4.3.3-5ubuntu4) 4.3.3

The above examples all operate on a single main.o, that’s why there’s so little output.

Stuff that happens for no good reason at all… [0]

Posted on by
Reply

My DS 5.1 on a Solaris 10 installation got quite cranky today, it started with me migrating a NIS+ client to LDAP.

After running the usual ldapclient manual $foo command nothing happened and even less worked. To cancel out a few possible problems I simply deactivated TLS (the LDAP server is on the same machine) and once again nothing worked, so I checked the ACLs and they were quite fine…

After trying a few other combinations with ldapclient the LDAP server was simply gone. Okay, no problem…we can restart it quite easily…or maybe not…libiconv.so.2 was missing. find saying something else obviously, granted /usr/local/lib isn’t such a great path, but is was in the $LD_LIBRARY_PATH that again got completely ignored by the directoryserver. (Confirmed via start-slapd.) Creating a symlink just got rid of the error message, the server still didn’t start…what now…right, lunch. :)

After that I logged in again, tried another directosyserver start (just for kicks) and it worked, however I didn’t change anything in the environment.

So, what now? Cleaning up the $PATH and $LD_LIBRARY_PATH shit someone felt necessary and getting a proper DirectoryServer installed ASAP.

Sun Ray login problem

Posted on by
Reply

Over the last days I encountered the following error on my Sun Ray DTUs after trying to log in via dtlogin:

Workspace Manager: I/O error on display:: :4.0

There were also quite a few other errors in the SUNWut logs (eg. PAM_CONV_ERR), which got me on a wild goose chase at first.

Lastly, I found out that the problem was the $LD_LIBRARY_PATH environment variable that was set via /etc/profile. Despite fixing the problem, I couldn’t find the problematic library yet.

FreeBSD and Xorg 7.4

Posted on by
Reply

The new X Server doesn’t like to play nice with other daemons. Starting X with a running moused pretty much ensures a not working mouse, if you’ve still some mouse input configuration in xorg.conf. So, having a mouse configured via xorg.conf and not using moused works fine, as long as the following Option is set in the ServerFlags section:

Option “AllowEmtpyInput” “false”

Another way for me to get the mouse working was to delete all the input configurations, a started moused and the above option. Unfortunately, you have to configure the input devices via hald, which wasn’t working for me at all.