Re: What's cooking in git.git (Nov 2010, #03; Wed, 24)

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

 



On Thu, Nov 25, 2010 at 3:54 PM, Erik Faye-Lund <kusmabite@xxxxxxxxx> wrote:
> On Thu, Nov 25, 2010 at 1:34 PM, Erik Faye-Lund <kusmabite@xxxxxxxxx> wrote:
>> On Thu, Nov 25, 2010 at 1:00 PM, Ævar Arnfjörð Bjarmason
>> <avarab@xxxxxxxxx> wrote:
>>> On Thu, Nov 25, 2010 at 11:35, Erik Faye-Lund <kusmabite@xxxxxxxxx> wrote:
>>>> On Thu, Nov 25, 2010 at 10:45 AM, Ævar Arnfjörð Bjarmason
>>>> <avarab@xxxxxxxxx> wrote:
>>>
>>>>> Is there anything else than that (the builtin.h includes) that you
>>>>> think needs work?
>>>>
>>>> There was an issue where setting NO_GETTEXT wasn't enough to disable
>>>> internationalization. Has this been fixed?
>>>
>>> Do you mean the issue with eval_gettext in git-sh-i18n.sh? I fixed
>>> that issue, but even under NO_GETTEXT=YesPlease we'll still pass
>>> things through git-sh-i18n--envsubst. Since I can't just #define
>>> things out under NO_GETTEXT=Yes like I can in the C code.
>>>
>>> Maybe you mean something different that I'm forgetting. But IIRC that
>>> was the only issue.
>>>
>>
>> I'm talking about this:
>>
>> $ git diff
>> diff --git a/Makefile b/Makefile
>> index 8357106..0a49c2c 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -1124,6 +1124,7 @@ ifeq ($(uname_S),Windows)
>>        NO_STRTOK_R = YesPlease
>>        NO_FNMATCH = YesPlease
>>        NO_MEMMEM = YesPlease
>> +       NO_GETTEXT = YesPlease
>>        # NEEDS_LIBICONV = YesPlease
>>        NO_ICONV = YesPlease
>>        NO_C99_FORMAT = YesPlease
>>
>
> Uhm, my bad. This was in the MINGW-section. Seems this issue has been
> fixed now, thanks.
>

I'm really not thinking straight today: This was in the MSVC-section,
and I tried to build with MinGW. If I move it to the MinGW section,
then it's closer to working:

$ make
    CC alias.o
    CC alloc.o
<...>
    CC gettext.o
gettext.c:3:21: error: libintl.h: No such file or directory
gettext.c:7:22: error: langinfo.h: No such file or directory
gettext.c: In function 'git_setup_gettext':
gettext.c:17: warning: implicit declaration of function 'bindtextdomain'
gettext.c:25: error: 'LC_MESSAGES' undeclared (first use in this function)
gettext.c:25: error: (Each undeclared identifier is reported only once
gettext.c:25: error: for each function it appears in.)
gettext.c:30: warning: implicit declaration of function 'nl_langinfo'
gettext.c:30: error: 'CODESET' undeclared (first use in this function)
gettext.c:30: warning: assignment makes pointer from integer without a cast
gettext.c:32: warning: implicit declaration of function 'bind_textdomain_codeset
'
gettext.c:34: warning: implicit declaration of function 'textdomain'
make: *** [gettext.o] Error 1

So this seems to be the same issue as what Hannes is talking about;
gettext.o being included into LIB_OBJS before we know if it should or
not.

Moving it down to the rest of the NO_GETTEXT-magic fixes the problem for me:


diff --git a/Makefile b/Makefile
index 8357106..a858708 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,5 @@
 # The default target of this Makefile is...
 all::
-
 # Define V=1 to have a more verbose compile.
 #
 # Define SHELL_PATH to a POSIX shell if your /bin/sh is broken.
@@ -628,9 +627,6 @@ LIB_OBJS += entry.o
 LIB_OBJS += environment.o
 LIB_OBJS += exec_cmd.o
 LIB_OBJS += fsck.o
-ifndef NO_GETTEXT
-LIB_OBJS += gettext.o
-endif
 LIB_OBJS += graph.o
 LIB_OBJS += grep.o
 LIB_OBJS += hash.o
@@ -1603,6 +1600,8 @@ endif

 ifdef NO_GETTEXT
        COMPAT_CFLAGS += -DNO_GETTEXT
+else
+       LIB_OBJS += gettext.o
 endif

 ifdef NEEDS_LIBINTL
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]