freeipmi-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Freeipmi-devel] Major symbol exporting problem


From: Albert Chu
Subject: Re: [Freeipmi-devel] Major symbol exporting problem
Date: Fri, 02 Apr 2004 13:25:22 -0800

> What library is the one that conflicts?  Just libiberty or another?

libprocps.  

> In fact I think this is The Right Way (TM)

This issue came up due to the random luck that these two libraries named
two completely different functions identically.  And unfortunately, they
were implemented in such a way that ipmi functions that required xmalloc
segfaulted.

I think the correct way to do this is to make sure that all symbols that
we don't want exported are simply not exported.  I'm don't know what the
most portable/correct way to do this though.

Al



--
Albert Chu
address@hidden
Lawrence Livermore National Laboratory

----- Original Message -----
From: Ian Zimmerman <address@hidden>
Date: Friday, April 2, 2004 9:19 am
Subject: Re: [Freeipmi-devel] Major symbol exporting problem

> Albert Chu <address@hidden> writes:
> 
> > Hmmm, off the top of my head, I guessing no.  Wrapping the #ifdef 
> around> xmalloc will not stop the symbol from being exported.  But 
> its worth a
> > shot, I'll give it a shot later on today.
> > 
> > There are ways to stop symbols from being exported via the 
> compiler. 
> > But I don't know if we want to do that ... 
> > 
> 
> What library is the one that conflicts?  Just libiberty or another?
> 
> We could put a check into configure.ac like
> 
> LIBS="$LIBS -liberty"
> AC_CHECK_FUNCS(xmalloc)
> 
> this will define LIBOBJS=xmalloc.o if it is not found, then you can
> include it conditionally like
> 
> modules=foo.o bar.o $(LIBOBJS)
> 
> In fact I think this is The Right Way (TM)
> 





reply via email to

[Prev in Thread] Current Thread [Next in Thread]