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 15:26:43 -0800

> I like the current approach you took. ipmi_ prefix. Simple and easy.

In the future, should we just remember to prefix every non-static
function with "ipmi_".

Al

--
Albert Chu
address@hidden
Lawrence Livermore National Laboratory

----- Original Message -----
From: Anand Babu <address@hidden>
Date: Friday, April 2, 2004 2:09 pm
Subject: Re: [Freeipmi-devel] Major symbol exporting problem

> ,----
> | > 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
> `----
> I like the current approach you took. ipmi_ prefix. Simple and easy.
> 
> --
> 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)
> > 
> 
> 
> -- 
> _.|_ 
> (_||_)
> Free as in Freedom <www.gnu.org>
> 





reply via email to

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