RFC: emboss.eclass as replacement for embassy.eclass - Page 2

03-16-2011, 08:36 AM

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dne 16.3.2011 07:48, justin napsal(a):
> On 15/03/11 22:25, TomÃ¡Å¡ ChvÃ¡tal wrote:
>>
>> i am seriously hurt by $(use_enable amd64 64)
>
> Where is the problem? The purpose of the eclass is not to repeat the
> same code 20 times. Why can't this be here?
>
Problem is in amd64, what if we get to 64b mips OR ppc64 or any other
non-32bit arch?

Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2AhJUACgkQHB6c3gNBRYeo8gCgzgj2xDGjaA 9ym2SmIsYmpn2W
bIgAn3GvJ7SjwAGg+V91YZwG4PK+2q/u
=8GNY
-----END PGP SIGNATURE-----

03-16-2011, 04:13 PM

On Wed, 16 Mar 2011 08:02:01 +0100
justin <jlec@gentoo.org> wrote:

> >> HOMEPAGE="http://emboss.sourceforge.net"
> >
> > could do with a trailing "/"

I *like* to see that too...

> I asked myself quite often, if this needed or not. What is the purpose
> of the trailing "/"?

However:

"An HTTP URL takes the form:

http://<host>:<port>/<path>?<searchpart>

"where <host> and <port> are as described in Section 3.1. If :<port>
is omitted, the port defaults to 80. No user name or password is
allowed. <path> is an HTTP selector, and <searchpart> is a query
string. The <path> is optional, as is the <searchpart> and its
preceding "?". If neither <path> nor <searchpart> is present, the "/"
may also be omitted." [1]

[1] <http://www.ietf.org/rfc/rfc1738.txt>, p.8, section 3.3

03-16-2011, 04:59 PM

>>>>> On Wed, 16 Mar 2011, Jeroen Roovers wrote:

> "An HTTP URL takes the form:

> http://<host>:<port>/<path>?<searchpart>

> "where <host> and <port> are as described in Section 3.1. If :<port>
> is omitted, the port defaults to 80. No user name or password is
> allowed. <path> is an HTTP selector, and <searchpart> is a query
> string. The <path> is optional, as is the <searchpart> and its
> preceding "?". If neither <path> nor <searchpart> is present, the "/"
> may also be omitted." [1]

Right, so <http://emboss.sourceforge.net> or even
<http://emboss.sourceforge.net:80> are legal and equivalent to
<http://emboss.sourceforge.net/>.

However, there is also a "normalized form" of URIs, which does include
the trailing slash:

"In general, a URI that uses the generic syntax for authority with
an empty path should be normalized to a path of "/"." [2]

Ulrich

> [1] <http://www.ietf.org/rfc/rfc1738.txt>, p.8, section 3.3
[2] <http://tools.ietf.org/html/rfc3986#section-6.2.3>

03-16-2011, 05:49 PM

On Wednesday, March 16, 2011 03:02:01 justin wrote:
> >> # $(use_with png pngdriver "${EPREFIX}/usr")
> >> # $(use_with pdf hpdf "${EPREFIX}/usr")
> >> # $(use_with mysql mysql "${EPREFIX}/usr/bin/mysql_config")
> >> # $(use_with postgres postgresql "${EPREFIX}/usr/bin/pg_config")
> >
> > do you really need full paths here ? are the configure scripts that
> > screwed up ? ideally libs would be found via .pc files.
>
> It f..ing defaults to / roots if not specified

lame. feel like pestering upstream to be smarter about this ? like use
AC_CHECK_TOOL(mysql_config) ? and for things like libpng, use PKG_CONFIG
macros to find the .pc files ?
-mike

03-16-2011, 05:51 PM

On Wednesday, March 16, 2011 05:36:21 TomÃ¡Å¡ ChvÃ¡tal wrote:
> Dne 16.3.2011 07:48, justin napsal(a):
> > On 15/03/11 22:25, TomÃ¡Å¡ ChvÃ¡tal wrote:
> >> i am seriously hurt by $(use_enable amd64 64)
> >
> > Where is the problem? The purpose of the eclass is not to repeat the
> > same code 20 times. Why can't this be here?
>
> Problem is in amd64, what if we get to 64b mips OR ppc64 or any other
> non-32bit arch?

or using the upcoming x32 ABI with KEYWORDS=amd64 ?

if a package has a configure flag to control "64bitness", it is absolutely
broken. figure out what exactly the "64bitness" means (pointer size ? data
width ? assumptions about size of long ?) and replace it with a proper
configure time check. then the whole 64 configure flag can be thrown away.
-mike

03-16-2011, 06:23 PM

On 16/03/11 18:59, Ulrich Mueller wrote:
>>>>>> On Wed, 16 Mar 2011, Jeroen Roovers wrote:
>
>> "An HTTP URL takes the form:
>
>> http://<host>:<port>/<path>?<searchpart>
>
>> "where <host> and <port> are as described in Section 3.1. If :<port>
>> is omitted, the port defaults to 80. No user name or password is
>> allowed. <path> is an HTTP selector, and <searchpart> is a query
>> string. The <path> is optional, as is the <searchpart> and its
>> preceding "?". If neither <path> nor <searchpart> is present, the "/"
>> may also be omitted." [1]
>
> Right, so <http://emboss.sourceforge.net> or even
> <http://emboss.sourceforge.net:80> are legal and equivalent to
> <http://emboss.sourceforge.net/>.
>
> However, there is also a "normalized form" of URIs, which does include
> the trailing slash:
>
> "In general, a URI that uses the generic syntax for authority with
> an empty path should be normalized to a path of "/"." [2]
>
> Ulrich
>
>
>> [1] <http://www.ietf.org/rfc/rfc1738.txt>, p.8, section 3.3
> [2] <http://tools.ietf.org/html/rfc3986#section-6.2.3>
>

Thanks for clarification, justin

03-16-2011, 06:25 PM

On 16/03/11 19:49, Mike Frysinger wrote:
> On Wednesday, March 16, 2011 03:02:01 justin wrote:
>>>> # $(use_with png pngdriver "${EPREFIX}/usr")
>>>> # $(use_with pdf hpdf "${EPREFIX}/usr")
>>>> # $(use_with mysql mysql "${EPREFIX}/usr/bin/mysql_config")
>>>> # $(use_with postgres postgresql "${EPREFIX}/usr/bin/pg_config")
>>>
>>> do you really need full paths here ? are the configure scripts that
>>> screwed up ? ideally libs would be found via .pc files.
>>
>> It f..ing defaults to / roots if not specified
>
> lame. feel like pestering upstream to be smarter about this ? like use
> AC_CHECK_TOOL(mysql_config) ? and for things like libpng, use PKG_CONFIG
> macros to find the .pc files ?
> -mike

I will recheck that and see whether I can convince the build system to
be nice. I have to run eautoreconf anyways.

justin

03-19-2011, 06:33 PM

On 16/03/11 19:51, Mike Frysinger wrote:
> On Wednesday, March 16, 2011 05:36:21 TomÃ¡Å¡ ChvÃ¡tal wrote:
>> Dne 16.3.2011 07:48, justin napsal(a):
>>> On 15/03/11 22:25, TomÃ¡Å¡ ChvÃ¡tal wrote:
>>>> i am seriously hurt by $(use_enable amd64 64)
>>>
>>> Where is the problem? The purpose of the eclass is not to repeat the
>>> same code 20 times. Why can't this be here?
>>
>> Problem is in amd64, what if we get to 64b mips OR ppc64 or any other
>> non-32bit arch?
>
> or using the upcoming x32 ABI with KEYWORDS=amd64 ?
>
> if a package has a configure flag to control "64bitness", it is absolutely
> broken. figure out what exactly the "64bitness" means (pointer size ? data
> width ? assumptions about size of long ?) and replace it with a proper
> configure time check. then the whole 64 configure flag can be thrown away.
> -mike

Hi guys,

I need your help figure out how to handle the situation.

sample code is here: http://tinyurl.com/6ezv9uw

the configure adds -D__amd64__ to C(PP)FLAGS.

To me it should be set this on 64bit. Do I interpret that right?

How can I check for 64bitness during configure?

Thanks for help justin

03-20-2011, 05:39 PM

On Saturday, March 19, 2011 15:33:00 justin wrote:
> I need your help figure out how to handle the situation.
>
> sample code is here: http://tinyurl.com/6ezv9uw

dont do that. tinyurl's die, as do websites. just attach the code. see the
one example func attached.

is this the only way the define is used ? this file has no "64bit" behavior
in it at all, only x86_64 ABI-specific behavior.

the behavior it's looking at though really shouldnt be encoded into
applications. apparently the code relies on whether stdargs generates a fresh
list on the stack (and thus can be modified without modifying the original
arguments), or if it refers directly to the original arguments.

i'd have to look up what POSIX says on the matter, but if they're going to
delving down that far into the ABI, then it sounds like the code is fairly
fragile. but that's upstream's choice to write crap code.

> the configure adds -D__amd64__ to C(PP)FLAGS.
>
> To me it should be set this on 64bit. Do I interpret that right?

no. the compiler already takes care of defining __amd64__ for x86_64 targets,
so there's no need to manually define it.

so if this is the only place where __amd64__ is used, then you should make
sure the configure code never manually appends it.
-mike

03-21-2011, 09:37 AM

During closer investigation I found that it alos changes data width and
similar. probably something which should be checked during configure.

I attached some code as example:

from configure:

AC_ARG_ENABLE(64,
AS_HELP_STRING([--enable-64], [64 bit pointers]))
if test "${enable_64}" = "yes" ; then
AC_MSG_CHECKING(for 64bit compilation support)

dnl Test for Linux 64 bit

if test "`uname`" = "Linux"; then
CPPFLAGS="-DAJ_Linux64 $CPPFLAGS"
fi

exmaple header:

dnl Test for FreeBSD 64 bit
#if !defined(AJ_LinuxLF) && !defined(AJ_SolarisLF) &&
!defined(AJ_IRIXLF) && !defined(AJ_AIXLF) && !defined(AJ_HPUXLF) &&
!defined(AJ_MACOSXLF) && !defined(AJ_FreeBSDLF) && !defined(WIN32)
typedef int ajint;
typedef long ajlong;
typedef unsigned int ajuint;
typedef short ajshort;
typedef unsigned short ajushort;
typedef unsigned long ajulong;
#endif

#ifdef AJ_LinuxLF
#define HAVE64
typedef int ajint;
typedef long long ajlong;
typedef unsigned int ajuint;
typedef short ajshort;
typedef unsigned short ajushort;
typedef unsigned long long ajulong;
#define ftell(a) ftello(a)
#define fseek(a,b,c) fseeko(a,b,c)
#endif