This post follows the fact that I noticed that some of my 64bit development machines had 32bit binaries installed on them. It should be noted that this is not fatal in any sense of the word, but it is simply not ideal.

Here I will present how you can first identify what your machine’s architecture is, and then I will show how you can b
oth remove existing 32bit binaries, and how you can configure YUM so that it will only ev
er install 64bit software.

This blog post is only relevant if your linux box uses YUM as a package manager.

Identifying your machine’s architecture

In order to find out what your machine’s architecture is you need to execute the following command from your command line:

uname -a

If the result looks something like below, it means you have a 64bit machine, where the x86_64 implies the machine is 64bit.
If it had any of i386, i586, or i686, it would imply that the machine was a 32bit one.

Linux foo.bar.com 2.6.18-92.el5 #1 SMP Tue Jun 10 18:51:06 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux

Remove all 32bit binaries :

yum erase *.i386<br /> yum erase *.i586<br /> yum erase *.i686<br />

Tell YUM to never install 32bit binaries again:

You need to add the below line to your yum.conf file (usually found in /etc/) :

exclude=*.i386 *.i586 *.i686

At this point, all future software install via the YUM package manager will be optimised for your machine’s architecture.

I have had some problems installing software from source on my Max OS X Leopard machine. I should thank Martin Szomszor for his help on getting this working, but after some time faffing we finally got it sorted out.

I found that I was having problems making software on Leopard, which I could build fine on my linux (fedora) machines. The error I was getting was:

ld: duplicate symbol _g_bit_nth_lsf in foo.o and bar.o

I am running Leopard 10.5.3. I was using glib2, installed via Fink, version number: 2.12.0-103. After spending lots of time googling I found the following article to be of the most use, “Wireshark with Macports”, where Anders Brownworth pointed out that the error was due to a “extern inline bug in glib/gutils.h which is easily fixed“.

So to fix this:

• I located gutils.h, which I found here: /sw/include/glib-2.0/glib/gutils.h</li>

  • I then replaced these lines: `#ifdef G_IMPLEMENT_INLINES</p>

# define G_INLINE_FUNC

# undef G_CAN_INLINE

#elif defined (__GNUC__)

# define G_INLINE_FUNC extern inline

#elif defined (G_CAN_INLINE)`</li> * With this: `#ifdef G_IMPLEMENT_INLINES

# define G_INLINE_FUNC

# undef G_CAN_INLINE

#elif defined (__APPLE__)</p>

# define G_INLINE_FUNC static inline`</font> #elif defined (\_\_GNUC\_\_) \# define G\_INLINE\_FUNC extern inline #elif defined (G\_CAN\_INLINE)</code></li> * By adding these two middle lines: #elif defined (__APPLE__)</p> <p># define G_INLINE_FUNC static inline</li> * The start of the fragment of code was at line number _96_ in my **gutils.h** file</ul> Here is a link to my edited and working [gutils.h file](https://mmt.me.uk/blog/files/gutils.h). **Note 1:** I would make sure I get a copy of my original gutils.h file, as this may come in handy **Note 2:** There is a [patch](http://trac.macosforge.org/projects/macports/attachment/ticket/13006/glib2-inline.2.patch?format=raw) which one could apply to make the same changes which I have just described here. This patch follows this [ticket](http://trac.macports.org/ticket/13006). I didn’t know what to do with the patch file, so I ended up editing the file by hand:). I am guessing that is something todo with macports, mmm, nevermind, its working now.

When building from source on Mac OSX, I have regularly come across the problem whereby the compiler complains about _duplicate dylib_s.

duplicate dylib libiconv.2.dylib

This is due to my use of the Fink and Darwin packages to install various bits I need for OSX development.

I recently noticed that many configure scripts cater for the user to select which dylib they would like to include. So I figured that my problem of duplicate iconv’s can be overcome by looking for options like :

--with-iconv=

So look out for similar parameters in configure scripts

./configure --with-iconv=/opt/local/..

So, why do I not just remove all but one instance of iconv? Well, Leopard ships with an old version of iconv, and I require recent versions for my development work.